Concurrent NetKAT with Ports

NetKAT is a powerful model extending Kleene algebra with tests (KAT) to programming networks. It supports the specification and reasoning about software-defined networks via automata-based operational semantics. This paper extends the NetKAT automata model to support concurrency using shared ports for communication and synchronization. We first extend the language of NetKAT protocols with communication actions and a parallel operator and give a closed and an open semantics using NetKAT automata. We show that NetKAT automata with an open semantics can be used as a model of the coordination language Reo via symbolic constraint automata.


INTRODUCTION
The rapid evolution of technology, increasing network traffic, and the need for flexible and scalable computer networks have necessitated a paradigm shift in network management.Traditional network architectures use distributed switches to receive and forward packets, each switch consisting of hardware and dedicated control software.Software Defined Networks (SDNs) provide a centralized approach to network control and management by separating the control plane from the data plane [14].This separation allows for programmability and agility in network configurations, enabling dynamic provisioning of resources, efficient traffic management, and the ability to adapt to changing requirements.
The level of programmability of the software controllers in an SDN to handle traffic flow, routing decisions, and network policies together with the use of protocols such as OpenFlow [22] have generated increasing interest in the academic community to provide a theoretical foundation for understanding the principles, components, and interactions within SDNs.Examples include model-checking to verify controller programs [1,5,6,12], formal models of OpenFlow [11,18], or some specific part of it, such as the topology discovery mechanism [26] or security protocols [9].
Different from other process algebras like CSP [15], a policybased approach is taken by NetKAT [2], a model that emphasizes the policy-driven nature of SDNs.It consists of an extension with variables of Kleene Algebra with Tests tailored to define high-level policy specification and network components and observe the network behavior from the point of view of a packet [19].NetKAT, however, is not stateful and does not allow modeling concurrent policies and multiple packets.In this paper, we present pNetKAT, a conservative extension of NetKAT, allowing multiple concurrent policies to communicate via shared ports.In pNetKAT, ports are treated as shared variables that can be undefined when no communication is possible.We give an operational semantics to pNetKAT using non-deterministic NetKAT automata with a slightly modified acceptance rule that enforces observability only of sequences with successful synchronization steps).Without ports, both syntactically and semantically pNetKAT and NetKAT coincide.
Under the assumption that ports are declared as either input or output, we give another semantics to pNetKAT by refining the acceptance rule of non-deterministic NetKAT automata to allow for the system to interact with the environment along the input and output ports.The new semantics is an extension of the previous one (and thus the new equivalence is stricter, in general).We show that this model can be used as semantics for the coordination language Reo [3].from which we can borrow the join composition operator and define it for NetKAT automata with input and output ports.
Unlike other methods, our pNetKAT extension to a stateful and concurrent NetKAT is conservative as it remains in the semantic realm of language equivalence instead of moving to pomset [24] or bisimulation equivalence [8].The connection with Reo paves the way to a more expressive concurrent NetKAT, with (concurrent, stateful) policies declaring input and output ports (as switches and controllers in SDNs) that can be composed using a join operation (only communication on common ports must synchronize, while policies using undeclared ports in another process can proceed in parallel).
We proceed as follows.In Section 2 we briefly present NetKAT with a focus on the automata model.While the original model is deterministic we present also an equivalent but more compact model based on non-deterministic NetKAT automata (NKA).In Section 3 we extend NetKAT protocols with communication actions and concurrency and define a closed semantics using non-deterministic NetKAT automata with ports (pNKA).We continue in Section 4 by introducing non-deterministic NetKAT automata with input and output ports (ioNKA) and use them to model NetKAT with ports.We then briefly recall Reo and its symbolic constraint automata semantics and show how to compositionally translate them into NetKAT automata.

Related work
There are several works extending NetKAT in different directions.For example, [21] introduces network event structures to model constraints on updates and define an extension of NetKAT policies with mutable state to give semantics to stateful SDN controllers.DyNetKAT [8] is a NetKAT extension with concurrency and a stateful state to model SDNs with dynamic configurations.The extended language is a process algebra with constructs for synchronization, sequential composition, and recursion built on top of NetKAT policies.While DyNetKAT allows for multi-packet behavior, the syntax does not allow for the basic NetKAT "dup" action.Also, the focus is on bisimulation rather than our (and NetKAT) language equivalence, which comes equipped with sound and ground-complete axiomatization.
Staying in the realm of Kleene algebra is the line of works followed by [24], where CNetKAT is introduced as a combination of Kleene algebra with tests, concurrent Kleene algebra, and network operators.The semantics is given in terms of pomset languages and is thus based on true concurrency rather than interleaving.
Besides the work we already mentioned, there are other formal models for SDN closely related to NetKAT that involve concurrency.For example, concurrent NetCore [23] extends NetCore with concurrency, while NetKAT is an extension of NetCore with Kleene star.In terms of tools, SDNRacer [10] checks various concurrencyinduced errors in SDNs and precisely captures the asynchronous interaction between controllers and switches.
Constraint automata are the first automata-based model for Reo connectors [4].Since then, various other operational models have emerged (see [17] for an overview).Relevant to our work here is the extension of constraint automata with memory [16] and the more recent work of symbolic constraint automata [12] that focus on an implementable subset, instead of an efficient computation of the composition operator.In this paper, we show how to embed symbolic constraint automata into ioNKA.We follow I/O automata [20] and constraint automata [4] by explicitly declaring at the interface the ports that are used as input and output.Transitions in ioNKA, however, are neither action-based nor imperative, but rather declarative using pre-and post-conditions in the style of NetKAT automata.

NETKAT
In this section, we briefly introduce NetKAT [2], a language for specifying the flow of a packet through a network, and give its semantics in terms of finite automata and languages.
We assume fixed a finite set of fields , say of size , and a finite set of values Val.A packet  is a record of fields, that is, a function from  to Val that we represent by Tests for the value stored in a field form the basic building block for the set of predicates () defined by the following grammar: The set of all predicates (modulo the usual equations) forms a Boolean algebra, where + is interpreted as the disjunction, • as the conjunction, and ¬ as negation.Further, 1 is the truth predicate, and 0 denotes false.The set  of atoms ,  of the Boolean algebra () corresponds to the set of valuations, that is complete conjunctions of basic tests  =  ranging over all fields in .For simplicity, and with a convenient abuse of notation, we denote an atom as a record allowing us to switch between packets and atoms.The behavior of a packet through the network is specified by policies Here  is a predicate in (),  ←  is the assignment of the value  to the field  of a packet,  +  is the nondeterministic choice between the policies  and ,  •  specify the sequential composition of two policies, and  * the iterative execution of a policy .The predicate 0 denotes failure and 1 is skip.As usual, we will often not write "•" in policies.When applied to predicates, "+" and "•" act as disjunctions and conjunctions, respectively.The behavior of a packet  through the network is specified by a string in ( • ) •  * , denoting a sequence of conditions satisfied by the packet  before and after being forwarded from one switch to another in the network.Syntactically, the forwarding is specified by the action , which is thus the only observable action of a policy.The semantics of a policy is then given by the set of all possible behaviors of a packet under that policy.Since this is a regular subset of ( • ) •  * , following [13], we use an automaton to describe it.Definition 2.1.A deterministic NetKAT automaton (dNKA) is a tuple (, , , ,  0 ) where •  is a finite set of states, •  is a finite set of fields, •  :  ×  ×  →  is a transition map, •  :  ×  ×  → 2 is an observation map, and Here  is the set of atoms of (), and 2 is the two-element Boolean set.
Differently from an ordinary automaton, a dNKA uses pre-and post-conditions as labels to specify the execution of an action in a computation.Here  (, , ) =  ′ denotes a transition from state  to a state  ′ executed by an action satisfying the pre-condition  and resulting in a post-condition .Further, the observation map  (, , ) = 1 if and only if an action in state  satisfies the pre-condition , results in the post-condition , and successfully terminates a computation.
Figure 1 shows a dNKA.There are four states but only { 0 ,  1 ,  2 } are accepting computations that end in the pair of atoms labeling the respective vertical down arrows.The state  0 is the initial state, as marked by an incoming arrow without a source.As usual, labeled arrows between two states represent the transition map.Here we assume only three atoms: , , and .
The language accepted by a dNKA is a subset of strings in ( • ) •  * and is defined with the help of the following auxiliary acceptance predicate: •  (, ) =  (, , ), where  ∈ , ,  ∈ , and  ∈  + .The language   () is defined as the set of all strings accepted by .
The language of the automaton in Figure 1 is {, ,  }.In fact, for example,  ( For a more compact representation of the operational semantics of NetKAT, we use non-deterministic NetKAT automata as introduced in [25]. Definition 2.3.A non-deterministic NetKAT automaton (NKA) is a tuple (, , Δ, Ξ,  0 ), where •  is a finite set of states; •  is a finite set of fields; • Δ :  ×  ×  → P () is a transition relation; • Ξ:  ×  ×  → 2 is an observation map, and As before, here  is the set of atoms of ().
For example, the sub-automaton defined by restricting the one in Figure 1 to the three states  0 ,  1 and  2 is an NKA.
Every dNKA can be easily seen as an NKA with a functional transition relation.Conversely, given an NKA, we can construct a dNKA that is language equivalent.Theorem 2.5.For every NKA  there exists a dNKA  such that   () =   ( ).
The result is similar to the powerset construction for ordinary finite automata.In fact, given a NKA  = (, , Δ, Ξ,  0 ) we can define a dNKA  = (P (), , , , { 0 }) with Then, for all  ⊆ , ,  ∈ , and  ∈  * we can prove that  (, •) if and only if there exists  ∈  such that NDAcc(, • ).Note that the above language equivalence does not hold if Δ and Ξ would take as input general Boolean predicates instead of atoms.
In Table 1 we give the operational semantics of NetKAT policies in terms of an NKA.States of the automaton are policies themselves, that we consider modulo associativity, idempotency, and commutativity of the "+" operation to guarantee local finiteness.Basically, a state represents (an equivalence class of) what still needs to be executed.
We have two types of rules: those specifying transitions (on the left-hand side of Table 1), and those for observations, specifying the accepting states (on the right-hand side).Intuitively, the behavior of a policy is to guide a given packet into a network.This is described by the assignment of values to the fields to record, for example, where the packet is, where it has to go, and other information.Policies filter out executions via predicates.The basic transition step of a policy is given only by the execution of a  action.Predicate evaluations and field assignments are evaluated locally in the current state.A policy execution may terminate in an accepting state (as specified on the right-hand side of Table 1) or may diverge in an infinite computation (via the transition rules of  * ) and not be observed.Note that since we consider states modulo associativity, commutativity, and idempotency of the "+" operation, there is no need for symmetric rules for the "+" for both the transition and the observation relation.
For a given policy , in [13] a dNKA  () is constructed using syntactic derivatives.Similarly, Let  () denote the NKA constructed using the rules in Table 1, with as initial state (the equivalence class of) .We then have the automata  () and  () accept the same language [25].

NETKAT WITH PORTS
Next, we extend NetKAT protocols with a parallel operator and allow policies to communicate via ports.A port  is a shared variable between two processes that can be updated with a value  by an output operation ! and can be destructively read by an input operation ? which stores the communicated value into a field  .Unlike a variable, however, a port may be undefined, here denoted by the symbol ⊥ that we assume is not a value in Val.Intuitively, a port  is undefined, i.e.  = ⊥, if it can be used by an output operation.Dually, input on a port  can only take place if  is not undefined, i.e. ¬( = ⊥) that, as usual, we denote by  ≠ ⊥.In other words, we see an output ! as the atomic execution of the guarded command  = ⊥ •  ← , whereas an input ? can be seen as the atomic execution of the guarded command Here we use the assignment  ←  of a variable to a field, which is just an abbreviation for the protocol Σ  ∈Val ( =  •  ← ) because   is assumed to be finite.Communication of two parallel protocols via a port  in an undefined state is then the atomic execution of an output command on  followed by an input on , resulting in the command which, because is executed atomically, can be thought of as equivalent to Formally, we assume a finite set of variables Var partitioned in a set of fields  and a set of ports Prt.As for NetKAT, fields are ranged over by  , while ports are ranged by .All variables can store values from Val but only ports can be undefined, which we denote with ⊥ ∉ Val.The set of predicates (Var) extends those of NetKAT by allowing basic tests on all variables, including ports, as defined by the grammar where,  ∈ ,  ∈ Prt, and  ∈ Val.We use  =  as a shorthand for the test Σ  ∈Val  =  •  = .This is well defined because the set Val is finite.The behavior of a packet in pNetKAT through a network subject to several communicating parallel policies is specified by the following grammar that extends the one of NetKAT with communication actions and a parallel operator: As discussed above, here ? is an input action that is executed only when the port  has a value available that is assigned immediately to the field  .The output action ! is executed if the port  is not busy (there is no value) and makes available the value  at the port.Note that only fields can be assigned directly by policies, whereas ports can change values only through successful communications.
Policies can be executed in parallel via the operator "||".Parallel policies executing an input, respectively an output, action on the same port synchronize.
The operational semantics of pNetKAT is given in terms of NKA as presented in Definition 2.3.The only addition to the rules given in Table 1 is the transition and observation map for input and output actions and for the parallel composition of policies.The extra rules are presented next.
Input and output actions are, like , primitive actions that have a transition step and do not terminate for any observable pairs of atoms: The conditions in the premises of the two rules express the precondition and postcondition of the input and output, respectively, as we already discussed.Here  [/] ( [/ ]) is the atom assigning a port  to  (a field  to , respectively) and all other variables are as in .
The transition relation of the parallel composition  1 || 2 of two policies  1 and  2 is described by three types of rules, namely: synchronization, interleaving, and termination.When they occur in parallel, an input and an output action on the same ports synchronize: , whereas for all other variables  ∈ Var different from ,  1 () =  2 () =  () and  1 () =  2 () =  ().The above condition says that the pair ( 1 ,  1 ) describes the output of the value  on a port , that is received and assigned to field  by the input action specified by ( 2 ,  2 ).For all other variables, the preconditions and the postconditions of all transitions involved do not change.
If the transition of a policy does not have a visible effect on the state of a port, then when in parallel with any other policy it can proceed in an interleaving fashion: where  () =  () for all port  ∈ Prt.Note that, the above symmetric rules in combination with the synchronization rules imply that there cannot be multiparty synchronization.
Similar to the shuffle of languages, if a policy  1 terminates when in parallel with another policy  2 , then  2 can continue alone from the postcondition observed at the termination of  1 : Generally, the parallel composition of two policies does not terminate immediately, as it may involve input and output actions.However, if no communication action is involved, then it terminates observing the pair (, ) if both policies do the same.Note that this means inconsistent policies cannot terminate successfully, as they both act atomically on the same packet.
As in the previous section, we denote by  () the NKA constructed using the rules in Table 1 and the above ones for the parallel composition, with as states equivalence classes of policies modulo commutativity and associativity of both "+" and "||", and idempotency of only "+", and with as initial state (the equivalence class of) .To enforce synchronization, we impose that ports are undefined at all times in every accepted string (a condition satisfied by the synchronization step but not by the postcondition of an open output and a precondition of an open input).We thus refine the acceptance predicate for NKA with ports (thus, pNetKAT) as follows: Because of the symmetry in the rules of the parallel composition, we have that "||" is a commutative and associative operator.It is not idempotent in general, except for policies with no occurrences of , input, or output actions.For example || =  •  and Clearly, if there are no ports in Var (i.e.Var = ) then they do not appear in atoms in .In this case, the definition of PAcc coincides with the usual definition NDAcc of accepted strings for an NKA.Note that because ports are undefined in every atom occurring in a string accepted by PAcc ports can be removed (or added) to an NKA without changing its language equivalence.Using the Kleene theorem for NetKAT [13], we can relate (non-compositionally) pNetKAT with NetKAT: Theorem 3.2.For every pNetKAT policy  there is a NetKAT policy  such   ( ()) is equal to   ( ()) after removing the ports from every atom.This implies that for every process in pNetKAT we can find an 'equivalent' process in NetKAT, basically by compiling parallel processes into interleaved ones if no open communication is involved and transforming synchronizations into assignments.In other words, the semantics of pNetKAT is a closed semantics not allowing any external communication after the system is defined.In the next section, we define an open semantics that allows for the synchronization of several ports at the same time.
We conclude this section with an example adapted from [8] and sketched in Figure 2. Two switches  and  have 3 ports each: 1, 2, 3 and 1, 2, 3, respectively.Their behavior depends on their current flow table and it is described by the following set of policies: where  is a field of a packet that records the last passed port.The switches are linked through ports 3 and 3: Under the flow tables  1 and  1 , for example, a packet that arrives at port 1 of switch  is forwarded to port 3.The latter is linked to port 3 of switch  , which forwards the packet to port 1.Note the role of the  action to record that a packet moves from one switch to another.Each switch is linked with a controller via the ports  and . is the controller of switch  and  of switch  .The two controllers are concurrently acting on their switch by updating their flow tables.The task of the two controllers is to guarantee that incoming packets at port 1 arrive at port 1 and incoming packets at port 2 arrive at port 2.No mixing of flow is allowed.To avoid race conditions, the controllers have to synchronize and guarantee a proper order of execution of their concurrent behaviors: Here  and  are the ports connecting the controllers to their controlled switches.When sending the flow message 0, 1, or 2, the flow table will be updated accordingly.The two controllers use port  to synchronize each other and pass the information about which flow table they have updated.While waiting for the update of the flow table of switch  , the switch  first drops all incoming packets, and only after  is updated then  accept packets from the correct port.
The behavior of the entire network is given by where •   +  + ?1 + ?2Initially, both switches start with empty flow tables that are updated when a controller sends a flow message to its switch via the port  or , respectively.

NETKAT AUTOMATA WITH I/O PORTS
In the previous section, we used NKA for giving a closed semantics of our concurrent policy language pNetKAT using the acceptance predicate PAcc that takes into account ports.Next, we consider NetKAT automata for open concurrent systems and use them as a model of pNetKAT.
To begin with, we partition the set of ports Prt into input ports IPrt and output ports OPrt.Together with the disjoint set of fields  they form a finite set of variables Var.Input ports are ranged over by  and output ports by .As before, all variables can store values from Val but only input and output ports can be undefined, which we denote with ⊥ ∉ Val.Intuitively, an input port  of a connector is enabled if it contains a value different from ⊥ so that this value is ready to be taken by the connector when synchronizing on  with the environment that puts the value in it.Dually, an output port  of a connector is undefined (i.e.,  = ⊥) when the port  is ready to receive a value from the connector and synchronizes with the environment when it will read from .
We use input and output ports to define a novel operational behavior of NKA by an acceptance predicate that, differently from , does not enforce synchronization and leaves the system open to communication instead of closing it in the style of [7].Definition 4.1.Let  be the set of atoms of the Boolean predicates (Var), where Var = IPrt ∪ OPrt ∪ .For an NKA  = (, Val, Δ, ,  0 ) with atoms  involving input and output ports, we say that a string  ∈ ( × ) + is accepted by  if and only if the predicate IOAcc( 0 , ) holds, where IOAcc is defined inductively as follows: • IOAcc(, (, )) ⇐⇒ Ξ(, , ), • IOAcc(, (, )) ⇐⇒ ∃ ′ ∈ Δ(, , ) .IOAcc( ′ , ) and  ▷ ℎ (), where  ∈ , ,  ∈ ,  ∈ ( × ) + .The language   ( ) is defined as the set of all strings in ( × ) + accepted by  .We refer to NKA with IOAcc predicates as ioNKA A pair (, ) in a string accepted above represents the pre/post condition of an action executed by a component.In between two pairs, the environment can communicate with the components and change the values at its ports.We formalize this using the ▷ predicates.In fact, for every string in ( × ) + , we define ℎ ((, )) = , and for every two atoms  and  we say that the predicate  ▷  holds if and only if: a. local variables cannot be modified by the environment, i.e.,  ( ) =  ( ) for every field  ∈ ; b. the environment can put a value to an input port only if the port is not already enabled, i.e. either  () =  () or  () = ⊥; c. the environment can take a value from an output port only if there is one, i.e., either  () =  () or  () = ⊥.Here we see  as the postcondition of an action, and  as the precondition of the next action both to be executed by the component, or, dually, they are the pre-and postcondition of actions executed by the environment.The conditions on the second and third items above allow the environment to communicate with a component only through input ports that are not enabled and output ports that contain values.As such the semantics of a component caters to all possible interactions with the environment and is open.The above reflects the fact that an input port must be enabled in the precondition and is available for communication after the value has been taken, and dually for an output port.
In the absence of input and output ports, the condition on the first item ensures that for any two consecutive pairs ( 1 ,  1 )( 2 ,  2 ) occurring in an accepted string, the postcondition  1 is equal to the precondition  2 .In this case, we can transform a strings  ∈ ( × ) + into essentially equal strings in  () ∈ ( • ) •  * as follows: The transformation  unifies the subsequent postcondition and precondition because they are equal.The inverse  −1 of  maps strings in ( • ) •  * into strings in ( × ) + by equating subsequent postcondition and precondition: Here  ∈  + and ,  are atoms in (  ), with Var = IPrt ∪ OPrt ∪ Fld.In other words, the predicate IOAcc is a conservative extension of   in the context of NetKAT automata when there are no ports.However, if we assume Prt = IPrt ∪ Oprt and Var = Prt ∪ Fld so that atoms in (  ) are of the correct type for both predicates PAcc and IOAcc, we then have the following result.Theorem 4.3.Let Var = Prt ∪ Fld and Prt = IPrt ∪ Oprt and (, Var, Δ, Ξ,  0 ) be a NKA.For every string  ∈ ( • ) •  * where  is the set of atoms of (Var) and  ∈  if the predicate PAcc(, ) holds then also IOAcc(,  −1 ()) holds.
As a consequence of the above, we have that if two policies of pNetKAT are language equivalent with respect to the IOAcc then they are also language equivalent with respect to PAcc.The converse is in general not true, meaning that the equivalence generated by pNKA is coarser than that of ioNKA.

Reo and symbolic constraint automata
Next, we show that NetKAT automata can be used to express the semantics of the coordination language Reo [3] too.Reo is a formalism that allows for the specification and composition of complex concurrent systems by focusing on the communication and synchronization of components.At its core are ports, which serve as connector endpoints for data transfer and synchronization, enabling the exchange of information between components.Connectors impose data and synchronization constraints on the data flow, and when all constraints are satisfied the data moves from input ports to output ports.Dual ports sharing the same name are connected forming complex circuits and linking the several components of a system.
In this paper, we use symbolic constraint automata as a semantic model of Reo connectors [12].In symbolic constraint automata, transitions are labeled by guarded actions.Transitions may only be taken if enabled, a property expressed by a predicate on the current local state and the current values present at the input ports.In this case, an action is executed that may change the value of the local state and output ports.
For simplicity, we abstract from a concrete syntax for predicates and actions, and we denote by  ( x, ȳ) =  ( x) → ȳ . .= ( x), a guarded action, with  ( x) a predicate on a finite list (without repetition) x of variables in IPrt ∪ , and ( x) an actions that given x as input modify the variables in ȳ, a finite list (without repetition) of variables in OPrt ∪ .The guard  is evaluated only when each input port in x receives a value from the environment (thus not equal to ⊥).If the guard holds and all output ports in ȳ are ready to communicate (i.e. they are all ⊥) then the action  is executed using the values at the input ports and the current value of the fields in x.The result is assigned to the variables in ȳ.Since output ports are only used to communicate a value to the environment, we assume no occurrence of them on the guard and as input of the action.Dually, since input ports receive values only from the environment, we assume no occurrence of them on the left-hand side of the assignment.We denote by GAct (, ,  ) the set of all guarded action over a set  ⊆ IPrt,  ⊆ OPrt, and  ⊆ .
We use symbolic constraint automata as introduced in [12] with additional accepting states.In symbolic constraint automata, a transition denotes the possibility of executing a guarded action.However, for the actual execution of the guarded action to take place, the guard of the action must hold upon evaluation in the current assignment of variables to values.In Figure 3, we show three symbolic constraint automata.The one on the left corresponds to the synchronous channel in Reo as the data received at the input port  is synchronously passed to the output .The symbolic constraint automaton in the middle describes Reo's Fifo 1 channel: it assigns to the field  the value taken from  if it is in the empty state 0, and puts to the port  the value from  if it is in the full state 1.Finally, the rightmost automaton corresponds to a Filter channel in Reo.If the predicate  holds when a value is available at an input port , then the connector behaves like a synchronous connector and passes the input value to the output port .Otherwise, ¬ holds on the value of  and the value is taken from  and lost, meaning that the component waiting for synchronization on port  is released.

From SCA to ioNKA
Given a guarded action  ( x, ȳ) =  ( x) → ȳ . .= ( x) and atoms ,  assigning values to all variables (and possibly ⊥ to some input or output ports) we denote by  () the evaluation of  ( x) where all occurrences of (free) variables  ∈ x are substituted with  () ∈ Val.Similarly, we denote by () the list of values obtained by evaluating  when all variables  ∈ x get value  () ∈ Val.Finally, we say that the Hoare triple { } {} holds if •  is executable under , that is  () ≠ ⊥ for all input ports  ∈ x and  () = ⊥ for all output port  ∈ ȳ. •  is a precondition of  enabling its guard, that is  ≤  (); and •  is a postcondition of  changing only the variables in ȳ and consuming the value from all input ports in x, that is  [()/ ȳ, ⊥/ ī] ≤  where  [v/ ȳ, ⊥/ ī] is the atom mapping variables in ȳ to the respective values in v, enabling input ports in  to receive values, and remaining unchanged otherwise.
Pre and postconditions of a guarded action are used to construct an ioNKA from a symbolic constraint automaton Here  and  are atoms in (  ).
Consider, for example, the symbolic constraint automaton in Figure 3 Correctness of the translation from symbolic constraint automata to NKA with respect to the following notion of bisimulation is immediate by construction.However, this bisimulation relation will become more interesting when proving the correctness of the parallel composition of two automata.Transitions with guarded actions must be matched by transitions with all pre and postconditions of those actions, and vice-versa, every pair of pre and postconditions must be related to at least one guarded action.Note that if two states  and  ′ of an ioNKA are language equivalent with respect to IOAcc, and a state  of an SCA is bisimilar to  then  is bisimilar to  ′ too, where bisimilarity is the largest bisimulation between an SCA and an ioNKA.

Composing ioNKA
We conclude this section with a very brief presentation of a composition operator between NetKAT automata with input and output ports inspired by the one used in Reo [4].The idea is that the two automata synchronize via all (and only) the shared ports that are input for one automaton and output port for another.To avoid broadcasting, shared ports become local fields.No other synchronization is allowed, as all fields are only visible within the scope of an automaton.The composition is defined only if no causality problem can arise when the input and output ports of two automata are synchronized in the same step.
) be two non-deterministic NetKAT automata with   =   ∪   ∪   for  = 1, 2 such that  1 and  2 are disjoint sets of fields in .Assume that for every pair of ( 1 ,  1 ) and ( 2 ,  2 ) and state  1 and  2 such that either Δ 1 ( 1 ,  1 ,  1 ) ≠ ∅ and Δ 2 ( 2 ,  2 ,  2 ) ≠ ∅ or both Ξ 1 ( 1 ,  1 ,  1 ) and Ξ 2 ( 2 ,  2 ,  2 ) holds, the two automata synchronize only on the input ports used by one and output ports used by the other, but not on both input and output ports at the same time, that is In this case, the composition  1 ⊲⊳  2 is defined as the ioNKA (,  Δ, Ξ,  0 ) where: The above operation is a congruence with respect to language equivalence as defined in Definition 4.1 and is correct with respect to the parallel operator for symbolic constraint automata as given in [12] in the sense that if there is a bisimulation relation between two symbolic constraint automata and two ioNKA then we can find a bisimulation between their respective parallel composition.
As an example, we show the composition of two SCA constraints automata, one representing a FIFO buffer of size taking values from the input port , buffering in the field  1 and outputting the buffered value at the port , and the other similar but with input port  output port  and starting with a full buffer  2 instead of the empty  1 .
The two symbolic constraint automata are described at the top of Figure 4, while their composition is the SCA depicted at the bottom.We concentrate on the synchronization of the transition execution of the action  1 . .=  with that executing the action  . .=  2 .They are implemented in the ioNKA in Figure 5, where Here  1 is the data received as input by the first connector and  2 the one output by the second connector, while  2 and  1 are values (possibly bottom) already present at the output and input port of 1 2 , where  becomes a local field.Note that if we create a loop and let the port  =  in the second SCA then we have a problem of causality and the composition cannot take place.The problem could be solved by inserting e.g., a (synchronous) connector between  and .
We leave it as future work the extension of the syntax of pNetKAT with an explicit declaration of input and output ports for each policy, that can be combined with the join operation ⊲⊳ as defined above.

CONCLUSION AND FUTURE WORK
We extended NetKAT with concurrency and communication via shared ports.We followed two semantics lines using non-deterministic constraints automata: one observing successful synchronization only, and another allowing interaction with the environment.In both cases, communication by ports played an important role, and the second one can be used as a compositional model of the Reo coordination language too.
We focussed on the operational semantics and compositionality.A possible next step is the study of axiomatizations of our two extensions.From a more practical point of view, we could use our work on model checking Reo with SPIN [12] to obtain a model checker for concurrent NetKAT.An orthogonal extension is to combine concurrency with stacks to model VLANs [25].

Figure 2 :
Figure 2: A SDN with two switches and two controllers For example, if a component executes an action ending in a postcondition [ = 1,  = ⊥,  = 3] then the environment could assign a value to the input port  so that at the next step the component would start with a precondition [ = 1,  = 2,  = 3].Alternatively, the environment could take the value from the output port  and put a value in the input variable  resulting in the next step component precondition [ = 1,  = 2,  = ⊥].However, the environment could never change the value of the field  as it is local to the component.The set of input and output ports used by a pair (, ) is defined by  (, ) = { ∈ IPrt |  () ≠  () = ⊥} and  (, ) = { ∈ OPrt |  () ≠  () = ⊥} .