impnet: programming software-deﬁed networks …imp-net has a clear and simply-structured syntax...

ImpNet: Programming Software-Defied Networks UsingImperative Techniques∗

Mohamed A. El-Zawawy1,2,†1College of Computer and Information Sciences

Al Imam Mohammad Ibn Saud Islamic University(IMSIU)Riyadh

Kingdom of Saudi Arabia

2Department of MathematicsFaculty of ScienceCairo University

Giza 12613Egypt

[email protected]

Adel I. AlSalemCollege of Computer and Information Sciences

Al Imam Mohammad Ibn Saud Islamic University(IMSIU)Riyadh

Kingdom of Saudi [email protected]

Abstract: Software and hardware components are basic parts of modern networks. However the software compo-nent is typical sealed and function-oriented. Therefore it is very difficult to modify these components. This badlyaffected networking innovations. Moreover, this resulted in network policies having complex interfaces that arenot user-friendly and hence resulted in huge and complicated flow tables on physical switches of networks. Thisgreatly degrades the network performance in many cases.Software-Defined Networks (SDNs) is a modern architecture of networks to overcome issues mentioned above.The idea of SDN is to add to the network a controller device that manages all the other devices on the networkincluding physical switches of the network. One of the main tasks of the managing process is switch learning;achieved via programming physical switches of the network by adding or removing rules for packet-processingto/from switches, more specifically to/from their flow tables.A high-level imperative network programming language, called ImpNet, is presented in this paper. ImpNet enableswriting efficient, yet simple, and powerful programs to run on the controller to control all other network devicesincluding switches. ImpNet is compositional, simply-structured, expressive, and more importantly imperative. Thesyntax of ImpNet together two types of operational semantics to contracts of ImpNet are presented in the paper.The proposed semantics are of the static and dynamic types. Two modern application programmed using ImpNetare shown in the paper as well. The semantics of the applications are shown in the paper also.

Key–Words: Network programming languages, Controller-switch architecture, Static operational semantics, Dy-namic operational semantics, Syntax, ImpNet, Software-defined networks.

1 IntroductionA network is a group of appliances connectedto exchange data. Among these appliances areswitches forwarding data depending on MAC ad-dresses, routers forwarding data depending on IP ad-dresses, and firewalls taking care of forbidden data.The network appliances are connected using a modelthat efficiently allows forwarding, storing, ignoring,tagging, and providing statistics about data moving inthe network. Some of the network appliances, like

∗This is an extended and revised version of [22].†Corresponding author.

routers [29, 24], are special in their functionality asthey have some control over the network. This enablesrouters to compute and determine routes of data in thenetwork. Of course different networks have differentcharacteristics and abilities.

In 2011, the Open Networking Foundation [43],suggested removing the control owned by differentnetwork appliances and adding, instead, a general-purpose appliance, controller, to program differentnetwork appliances and querying data flowing in thenetwork. The impact of this simple suggestion ishuge; giant networks do not need special-purpose,complex, expensive switches any more. In such net-

WSEAS TRANSACTIONS on COMPUTERS Mohamed A. El-Zawawy, Adel I. AlSalem

E-ISSN: 2224-2872 402 Volume 13, 2014

works, cheap programmable switches can be used andprogrammed to configure and optimize networks viawriting programs [28] running on controllers.

Software-Defined Networks (SDNs) [15] are net-works established using the controller-switch archi-tecture. A precise implementation of this architectureis OpenFlow [7] used to achieve various network-wideapplications such as monitoring data flow, balancingswitch load, network management, controlling appli-ances access, detection of service absence, host mo-bility, and forwarding data center. Therefore SDNscaused the appearance of network programming lan-guages [26, 27, 25, 16].

This paper presents ImpNet, an imperative high-level network programming language. ImpNet ex-presses commands enabling controllers to programother network appliances including switches. Imp-Net has a clear and simply-structured syntax based onclassical concepts of imperative programming that al-low building rich and robust network applications ina natural way. ImpNet can be realized as a general-ization of Frenetic [32] which is a functional networkprogramming language. This is clear by the fact thatthe core of programs written in ImpNet and Freneticis based on a query result in the form of stream ofvalues (packets, switches IDs, etc.). Commands fortreating packets in ImpNet include constructing andinstalling (adding to flow tables of switches) switchrules. ImpNet supports building simple programsto express complex dynamic functionalities like loadbalancing and authentication. ImpNet programs canalso analyze packets and historical traffic patterns.

The current paper presents both syntax and se-mantics of ImpNet. Actually two types of precise op-erational semantics for ImpNet are presented in thispaper; static and semantics. Dynamic semantics1 arevery useful for studying and analyzing programs atrun time. Such semantics have a wide range of appli-cations in case of network programs. This is so as thenetwork programs tend to be event-driven and hencetheir run times are much longer than that of manyother application-programs. Therefore a formal def-initions for run times behaviors (semantics) can eas-ily be employed to achieve runtime verifications forcontroller programs. Moreover two ImpNet programsachieving two important controller applications arealso presented in this paper together with their preciseoperational semantics.

The current paper is an extended and revised ver-sion of [22]. The current paper extends the workof [22] by supporting the theoretical foundations Imp-

1Dynamic semantics can be realized as a perspective on pro-gramming languages semantics that models the increase of datain time.

Net via a dynamic operation semantics for its pro-grams. The dynamic semantics is necessary forachieving many important dynamics verifications fornetwork programs. The extensions are mainly in-cluded in Section 4 and Figures 8 and 9.

MotivationThe motivation of this paper is the lack of a simplesyntax for an imperative network programming lan-guage. Yet, a stronger motivation is that most existingnetwork programming languages are not supportedtheoretically (using static operational semantics, dy-namic operational semantics, type systems, programlogics like Floyd–Hoare logic, etc.).

ContributionsContributions of this paper are the following.

1. A new simply-structured syntax for an impera-tive network programming language; ImpNet.

2. A static operational semantics (in the form ofstates and inference rules) for constructs of Imp-Net.

3. A dynamic operational semantics for constructsof ImpNet.

4. Two detailed examples of programs constructedin ImpNet with their precise operation semantics.

OrganizationThe rest of this paper is organized as following. Sec-tion 2 reviews related work. Section 3 presents thesyntax and static operational semantics of ImpNet.The proposed static semantics are operational andhence consists of states and inference rules presentedin Section 3. A dynamic operational semantics ofImpNet programs is introduced in Section 4. Two de-tailed examples of programmes built in ImpNet arepresented in Section 5. This section also explains howthe two examples can be assigned precise static opera-tional semantics using our proposed static operationalsemantics. Section 6 gives directions for future workand Section 7 concludes the paper.

2 Related WorkThis section presents work most related to that pre-sented in the current paper. One of the early at-tempts to develop software-defined networking (SDN)is NOX [14] based on ideas from [13] and 4D [12].On the switch-level, NOX uses explicit and callbacksrules for packet-processing. Examples of applications


E-ISSN: 2224-2872 403 Volume 13, 2014

x ∈ lVar Q ∈ Queries n ∈ Integers

et ∈ Eventrans ::= n | Lift(x, λt.f(t)) | ApplyLft(x, λt.f(t)) | ApplyRit(x, λt.f(t)) |Merge(x1, x2) | MixFst(A, x2, x3) | MixSnd(A, x2, x3) |Filter(x, λ.f(t)) | Once(x) | MakForwRule(x) | MakeRule(x)

S ∈ Stmts ::= x := et | S1;S2 | AddRules(x) | Register | Send(x)

If (x) then S1 else S2 | While (x) do S

D ∈ Defs ::= ϵ | x := Q | DD.

p ∈ Progs ::= D ≫ S.

Figure 1: ImpNet Syntax.

that benefitted from NOX are load balancer [11] andthe work in [9, 10]. Many directions for improv-ing platforms of programming networks include Mae-stro [7] and Onix [8], which uses distribution and par-allelization to provide better performance and scala-bility.

A famous programming language for networks isFrenetic [32, 33] which has two main components.The first component is a collection of operators thatare source-level. The operators aim at establishingand treating streams of network traffic. These op-erators also are built on concepts of functional pro-gramming (FP) and query languages of declarativedatabase. Moreover the operators support a modulardesign, a cost control, a race-free semantics, a single-tier programming, and a declarative design. The sec-ond component of Frenetic is a run-time system. Thissystem facilitates all of the actions of adding and re-moving low-level rules to and from flow tables ofswitches. One advantage of ImpNet, the language pre-sented in this paper, over Frenetic is that ImpNet isimperative. Therefore ImpNet paves the way to theappearance of other types of network programminglanguages such as object-oriented network program-ming langues and context-oriented network program-ming languages.

Other examples to program network componentsthough high-level languages are NDLog and Net-Core [6]. NetCore provides an integrated view of thewhole network. NDLog is designed in an explicitlydistributed fashion.

As an extension of Datalog, NDLog [30, 31] waspresented to determine and code protocols of rout-ing [29], overlay networks, and concepts like hashtables of distributed systems. ImpNet (presented inthis paper), Frenetic, and NDLog can be classified ashigh-level network programming languages. WhileNDLog main focus is overlay networks and routingprotocols, Frenetic (in a functional way) and ImpNet(in an imperative way) focus on implementing packet

processing such as modifying header fields. ThereforeImpNet equips a network programmer with a modularview of the network which is not provided by ND-Log and Frenetic. This is supported by the fact thata program in NDLog is a single query that is calcu-lated on each router of the network. One advatnage ofnetwork programming langauges (ImpNet) is savingrouting energy [41].

Energy Efficient Routing with TransmissionPower Control based Biobjective Path SelectionModel for Mobile Ad-hoc Network

The switch component [39] of networks canbe programmed via many interfaces such as Open-Flow platform. Examples of other platforms includeShangri-La [40] and FPL-3E [42], RouteBricks [37],Click modular router [34], Snortran [35] and Bro [36].The idea in Shangri-La [40] and FPL-3E [42] is toproduce certain hardware for packet-processing fromhigh-level programs that achieves packet-processing.In RouteBricks [37], stock machines are used toimprove performance of program switches. As amodular approach, the platform of Click modularrouter [34], enables programming network compo-nents. This system focuses on software switches inthe form of Linux kernel code. For the sake of in-trusions detection and preserving network security,Snortran [35] and Bro [36] enable coding monitoringstrategies and robust packet-filtering. One advantageof ImpNet, the language presented in this paper, overall the related work is that ImpNet overcomes the dis-advantage of most similar languages of focusing oncontrolling a single device.

There are many possible network applications fordynamics semantics of ImpNet. The K-random searchin peer-to-peer networks using dynamic semantic datareplication [1] can be better verified using dynamicsemantics of the nature proposed in this paper. Thecorrectness of dynamic information retrieval in P2Pnetworks is achieved using dynamics semantics plat-form [2]. Dynamic reconfiguration of networked ser-


E-ISSN: 2224-2872 404 Volume 13, 2014

vices can be carried out using dynamic semantic inthe shape of interoperability framework [3] like thatof this paper. In an attractor network, spreading ac-tivation with latching dynamics can be realized usingautomatic dynamic semantic similar to the one pro-posed in this paper [4].

3 Syntax and Static Operational Se-mantics

This section presents the syntax and static operationalsemantics of ImpNet, a high-level programming lan-guage for SDN networks using the switch-controllerarchitecture. Figure 1 shows the syntax of ImpNet.Figures 2 and 3 present the static operational seman-tics of ImpNet constructs. The proposed semantics isoperational and its states are defined in the followingdefinition.

Definition 1 1. t ∈ Types = {int, Switch IDs,Packet, (Switch IDs, int, bool)}∪{(t1, t2) |t1, t2 ∈ Types}.

2. v ∈ Values = Natural numbers ∪ Switch IDs ∪Packets ∪ Switch IDs × Natural numbers ×Boolean values ∪ {(v1, v2) | v1, v2 ∈ Values}.The expression v : t denotes that the type of thevalue v is t.

3. ev ∈ Events = {(v1, v2, . . . , vn) | ∃t(∀i vi : t)}.

4. Actions= {sendcontroller, sendall, sendout,change(h,v) }.

5. r ∈ Rules = Patterns × Acts.

6. rl ∈ RlLst = {[r1, r2, . . . , rn] | ri ∈ Rules}.

7. ir ∈ Intial-rule-assignment = SwchIds × Rules.

8. σ ∈ SwchSts = Flow-tables = SwchIds →RlLst.

9. γ ∈ VarSts = Var → Events ∪ RlLst.

10. s ∈ States = SwchSts × VarSts × RlLst.

A program in ImpNet is a sequence of queries fol-lowed by a statement. The result of each query is anevent which is a finite sequence of values. The eventconcept is also used in Frenetic. However an event inFrenetic is an infinite sequence of values. A value isan integer, a switch ID, a packet, a triple of a switchID, an integer, and a Boolean value, or a pair of twovalues. Each value has a type of the set Types. In thispaper, we focus on the details of statements as this is

the most interesting part in a network programminglanguage.

The query part of a network language is there toenable reading the status of the network. Typically,queries contain commands for

• dividing packets via grouping according to val-ues of header fields,

• splitting packets according to arrival time or val-ues of header fields,

• filtering packets in the network according to agiven pattern,

• minimizing the volume of returned values, and

• summarizing results using size or number ofpackets.

Possible actions taken by a certain switch on acertain packet are sendcontroller, sendall, sendout, orchange(h,v). The action sendcontroller sends a packetto the controller to process it. The action sendall sendsthe packet to all other switches. The action sendoutsends the packet out of the switch through a certainport. The action change(h,v) modifies the header fieldh of the packet to the new value v.

A rule in our static operational semantics is a pairof pattern and action where pattern is a form that con-cretely describes a set of packets and action is theaction to be taken on elements of this set of pack-ets. Rules are stored in tables (called flow tables) ofswitches. Intial-rule-assignment represents an initialassignment of rules to flow tables of switches.

A state in the proposed static operational seman-tics is a triple (σ, γ, ir). In this triple γ captures thecurrent state of the program variables and hence is amap from the set of variables to the set of events andrule lists. This is so because in ImpNet variables maycontain events or rule lists. The symbol σ capturesthe current state of flow tables of switches and henceis a map from Switche IDs to rule lists. Finally, ir isan initial assignment of rules assigned to switches buthave not been registered yet (have not been added toγ yet).

There are five type of statements in ImpNet. Theassignment statement x := ef assigns the result ofan event transformer (et) to the variable x. The state-ment AddRules(x) adds the switch rules stored in xto the reservoir of initially assigned rules. These arerules that are assigned to switches but are not addedto flow tables yet. The statement Register makes theinitial assignments permeant by adding them to flowtables of switches. The statement Send(x) sends spe-cific packets to be treated in a certain way at certainswitches. To keep a record of of actions taken on


E-ISSN: 2224-2872 405 Volume 13, 2014

vi : t γ(x) = (v1, v2, . . . , vn)(Lifts)

Lift(x, λt.f(t)) : γ → (f(v1), f(v2), . . . , f(vn))

γ(x1) = (v1, v2, . . . , vn) γ(x2) = (w1, w2, . . . , wn)(Merges)

Merge(x1, x2) : γ → ((v1, w1), (v2, w2), . . . , (vn, wn))

γ(x) = (v1, v2, . . . , vn) A = {i | f(vi) = true}(Filters)

Filter(x, λ.f(t)) : γ → (. . . , vi, . . . | i ∈ A)

vi : t γ(x) = ((v1, v′1), (v2, v

′2), . . . , (vn, v

′n))

(Apps1)

ApplyLft(x, λt.f(t)) : γ → ((f(v1), v′1), (f(v2), v

′2), . . . , (f(vn), v

′n))

v′i : t γ(x) = ((v1, v′1), (v2, v

′2), . . . , (vn, v

′n))

(Apps2)

ApplyRit(x, λt.f(t)) : γ → ((v1, f(v′1)), (v2, f(v

′2)), . . . , (vn, f(v

′n)))

type(x) ∈ Types(Onces)

Once(x) : γ → (x, x, . . . , x︸︷︷︸n times

)

γ(x1) = (v11 , v12 , . . . , v

1n) γ(x2) = (v21 , v

22 , . . . , v

2n) A1 = A ∪ {v11} ∀i > 1.Ai = Ai−1 ∪ {v1i }

(Mixs1)

MixFst(A, x1, x2) : γ → ((A1, v21), (A2, v

22), . . . , (An, v

2n))

γ(x1) = (v11 , v12 , . . . , v

1n) γ(x2) = (v21 , v

22 , . . . , v

2n) A1 = A ∪ {v21} ∀i > 1.Ai = Ai−1 ∪ {v2i }

(Mixs2)

MixSnd(A, x1, x2) : γ → ((v11 , A1), (v12 , A2), . . . , (v

1n, An))

γ(x) = ((v11 , v21 , v

31), (v

12 , v

22 , v

32), . . . , (v

1n, v

2n, v

3n))

(MFRs)MakForwRule(x) : γ → [(v11 , (v

31 , sendout(v

21))), (v

12 , (v

32 , sendout(v

22))), . . . , (v

1n, (v

3n, sendout(v

2n)))]

γ(x) = ((v11 , a1, v21), (v

12 , a2, v

22), . . . , (v

1n, an, v

2n))

(MkRls)MakeRule(x) : γ → [(v11 , a1(v

12)), (v

21 , a2(v

22)), . . . , (v

in, an(v

n2 ))]

Figure 2: Operational Semantics for Event Functions of ImpNet

et : γ → u(Assgns)

x := et : (σ, γ, ir) → (σ, γ[x 7→ u], ir)

S1 : (σ, γ, ir) → (σ′′, γ′′, ir′′) S2 : (σ′′, γ′′, ir′′) → (σ′, γ′, ir′)(seqs)

S1;S2 : (σ, γ, ir) → (σ′, γ′, ir′)

γ(x) ∈ Intial-rule-assignment(Addrls)

AddRules(x) : (σ, γ, ir) → (σ, γ, ir ∪ γ(x))

(Regs)Register : (σ, γ, ir) → (σ ∪ ir, γ, ∅)

γ(x) = ((v11 , v21 , v

31), (v

12 , v

22 , v

32), . . . , (v

1n, v

2n, v

3n)) ∀i.(vi2, vi3) ∈ history(vi1)

(Sends)Send(x) : (σ, γ, ir) → (σ, γ, ir)

Figure 3: Operational Semantics for Statements of ImpNet

Figure 4: Static Operational Semantics for ImpNet.


E-ISSN: 2224-2872 406 Volume 13, 2014

packets on different switches we assume a map calledhistory from the set of switche IDs to the set of listsof pairs of packets and taken actions. This map isused in the Rule (Sends). Static operational seman-tics of these statements are given in Figure 3. Judg-ments of inference rules in this figure have the formS : (σ, γ, ir) → (σ′, γ′, ir′). This judgement reads asfollowing. If the execution of S in the state (σ, γ, ir)ends then the execution reaches the state (σ′, γ′, ir′).

Inference rules in Figure 3 use that in Figure 2to get the semantics of the other important constructof ImpNet which is event transformers (et). Judge-ments of Figure 2 have the form et : γ → umeaning that the semantics of the transformer et inthe variable state γ is u. The event transformerLift(x, λt.f(t)) applies the map λt.f(t) to values ofthe event in x (Rule (Lifts)). The event transformerFilter(x, λ.f(t)) filters the event in x using the mapλt.f(t) (Rule (Filters)). From a given set of actionsA and two events x1 and x2 the event transformersMixFst(A, x1, x2) and MixSnd(A, x1, x2) create listsof rules (Rules (Mixs1) and (Mixs2)).

4 Dynamic SemanticsThis section presents a dynamic semantics forconstructs of ImpNet using Rewriting LogicSemantics [5]. An important concept topresent the semantics is that of rewrite theories(∏

ImpNet, EImpNet, RImpNet). This concept usesan extended version of the langauge syntax

∏ImpNet,

a group of equations, EImpNet, built on∏

ImpNet,and set of rules, RImpNet, for

∏ImpNet constructs.

Via a set of rearrangements, EImpNet is necessary toprepare the environment for applying the rules andhence EImpNet expresses no computational seman-tics. However RImpNet is the semantics componentmodeling in an irreversible way the computations.All in all, the semantics uses rewrite theories todefine ImpNet. This semantics is built on equationallogic [44] and hence it is allowed for terms to replaceequal terms in any context. This adds to the power ofthe semantics. The idea is that equations are meant tobe applied until arriving at a term matching the l.h.s.of one of the rules. This rule can then be used to doan irreversible transformation to the term. This typeof semantics is typically efficiently executable.

The proposed semantics uses a modular frame-work named C. In this framework rules use onlynecessary configuration items. Hence configurationchanges, e.g. adding stacks, do not imply mod-ifying existing rules. Sequences, maps, and bagsare necessary concepts to definitions of the C lan-

guage. This paper uses the classical interception ofthese concepts as data-structures of the equationaltype. Sequences, maps, and bags are denoted bySq ↪→

e , Mp ↪→e , and Bg ↪→

e , respectively, where ↪→is a binary operator and e is the unit element. There-fore in our proposed dynamic semantics an environ-ment (a state) is a finite bag of pairs. The domain of afunction can easily be expressed as a bag of items.

Definition 2 gives a formal presentation of states(configurations) of the proposed dynamic semantics.

Definition 2 • Cs = C | Sq ↪→. [C].

• σ ∈ SwchSts = Mp ,. [SwchIds,RlLst].

• h ∈ History = Mp ,. [SwchIds, [Packets,Acts]].

• γ ∈ VarSts = Mp ,. [Var,Events ∪ RlLst].

• confitm ∈ Configurations items =< C >Cs

| < σ >SwchSts | < γ >VarSts |< rl >RlLst | < h >History.

• conf ∈ Configurations =< Bg. [confitm] >.

The abstract syntax of ImpNet, history maps,maps, sequences, and bags are used as configurationconstructors. The configuration of ImpNet includefive components:

• < C >Cs including the computations,

• < σ >SwchSts capturing flow tables of thephysical switch of the concerned network,

• < γ >VarSts holding the mapping for the pro-gram variables including event variables,

• < rl >RlLst including the list of rules to be reg-istered, and finally

• < h >History capturing the history of packetstreatment of the network.

Algebraic structures in definitions of configura-tions achieve the context-sensitivity in C definitions.The sequentialization operator ↪→ in the dynamic se-mantics also contributes to the context-sensitivity.

Figure 5 presents the complete C definitions ofImpNet. Typically C definitions include a single syn-tactic category C. This category is intended to be aminimal infrastructure for terms definitions; not to bea parsing or type-checking tool. Typically in such se-mantics, sorts are equivalent to syntactic categoriesand operations are equivalent to productions. Hencealgebraic signatures somehow coincide with context-free notations. In the model C, Boolean values aretreated using special integer values.


E-ISSN: 2224-2872 407 Volume 13, 2014

x ∈ lVar Q ∈ Queries n ∈ Integers

C ∈ Core ::= x | n | C1 op C2 | [] | Q | C − λt.f(t) | (C, λt.f(t)) |(λt.f(t), C) | (C1, C2) | (A,C1, C2) | (C1, A,C2) |(C, f, λ.f(t)) | O(C) | F (C) | M(C) | C1 := C2 |C; | A(C) | R | S(C) | C1C2If (C1) C2 |If (C1) C2 C3 | While (C1) C2 | C1 ≫ C2

Figure 5: Core of ImpNet in C.

C − λt.f(t) = Lift(C, λt.f(t)) (C, λt.f(t)) = ApplyLft(C, λt.f(t))(λt.f(t), C) = ApplyRit(C, λt.f(t)) (C1, C2) = Merge(C1, C2)(A,C1, C2) = MixFst(A,C1, C2) (C1, A, C2) = MixSnd(A,C1, C2)(C, f, λ.f(t)) = Filter(C, λ.f(t)) O(C) = Once(C)F (C) = MakForwRule(C) M(C) = MakeRule(C)A(C) = AddRules(C) R(C) = Register(C)S(C) = Send(C) If (C1) C2 = If (C1) then C2

If (C1) C2 C3 = If (C1) then C2 else C3 While (C1) C2 = While (C1) do C2

Figure 6: Desugaring of Core Constructs of Figure 5.

C1 op C2 = (C1 ↪→ ⋄ op C2) n op C2 = (C2 ↪→ n op ⋄)(C1 := C2) = (C2 ↪→ C1 := ⋄) C; = (C ↪→ ⋄; )If (C1) C2 C3 = (C1 ↪→ If (⋄) C2 C3)

Figure 7: Computational Structural Equations of Dynamic Semantics.

Figure 8: Dynamic Operational Semantics for ImpNet.

The concepts of well-structured and well-evaluated computations are necessary for recognizingstart and final configurations of the dynamic seman-tics. Using equational reasoning of ImpNets dynamicsemantics of this section, an ImpNet computation C iswell-structured if it amounts to a well-structured eventtransformers or list of statements in ImpNet. A com-putation is well-evaluated if it amounts to a value v ∈Values or to the unit computation ”.”.

Figures 8 and 9 present all components of dy-namic semantics of ImpNet. Mostly, elements of thesefigures are self-describing. Wherever possible, it ispreferred to desugar constructs of our derived lan-guage.

There are some special configurations of the dy-namic semantics presented in this section. For awell-structures computation C, the configuration <<C >Cs , < . >SwchSts, < . >VarSts, < . >RlLst,< . >History > is the start configuration. For a ”,” ora value computation C, the configuration << C >Cs

, < σ >SwchSts, < γ >VarSts, < rl >RlLst,< h >History > is a final configuration.

The expression C1 ↪→ C2 denotes processingC1 before processing C2. Therefore C2 is some-how a frozen (from development) computation untilit is its turn. The technique of the evaluation of the

langue ImpNet is meant to be captured by the compu-tation equations. For example, the conditional state-ment schedules calculating the condition first whilethe branches are frozen. The most intricate rules ofFigure 9 are that of event transformers. This is soas most of these rules assume constrains on mulipleevent variables.

5 Controller ProgramsThis section presents several examples of programsconstructed using the syntax of ImpNet (Figure 1).The first example constructs rules based on informa-tion stored in the variable x and then installs the es-tablished rules to flow tables of switches stored in z.This program has the following statements.

y = MakeRule(x);

z = Lift(z, λt.(t, y));

AddRules(z);

Register;

The first statement of the program makes a rulefor each value of the event stored in x. Then the sec-ond statement assigns these rules to switch IDs in the


E-ISSN: 2224-2872 408 Volume 13, 2014

[] = .C1C2 = C1 ↪→ C2

C1 op C2 =⇒ C1 opintC2

If (C1) C2 C3 =⇒ C2, where C1 ̸= 0If (C1) C2 C3 =⇒ C3, where C1 = 0Left:< x− λt.f(t) ↪→ C >Cs < x 7→ (v1, v2, . . . , vn), γ >VarSts=⇒< (f(v1), f(v2), . . . , f(vn)) ↪→ C >Cs < x 7→ (v1, v2, . . . , vn), γ >VarStsApplyLft:< (x, λt.f(t)) ↪→ C >Cs < x 7→ ((v1, w1), (v2, w2), . . . , (vn, wn)), γ >VarSts=⇒< ((f(v1), w1), (f(v2), w2), . . . , (f(vn), wn)) ↪→ C >Cs

< x1 7→ (v1, v2, . . . , vn), x2 7→ (w1, w2, . . . , wn), γ >VarStsApplyRit:< (λt.f(t), x) ↪→ C >Cs < x 7→ ((v1, w1), (v2, w2), . . . , (vn, wn)), γ >VarSts=⇒< ((v1, f(w1)), (v2, f(w2)), . . . , (vn, f(wn))) ↪→ C >Cs

< x1 7→ (v1, v2, . . . , vn), x2 7→ (w1, w2, . . . , wn), γ >VarStsMerge:< (x1, x2) ↪→ C >Cs < x1 7→ (v1, v2, . . . , vn), x2 7→ (w1, w2, . . . , wn), γ >VarSts=⇒< ((v1, w1), (v2, w2), . . . , (vn, wn)) ↪→ C >Cs

< x1 7→ (v1, v2, . . . , vn), x2 7→ (w1, w2, . . . , wn), γ >VarStsMixFst:< (A, x1, x2) ↪→ C >Cs < x1 7→ (v1, v2, . . . , vn), x2 7→ (w1, w2, . . . , wn), γ >VarSts=⇒< ((A1, w1), . . . , (An, wn)) = ((A ∪ {v1}, w1), (A1 ∪ {v2}, w2), . . . , (An−1 ∪ {vn}, wn))↪→ C >Cs < x1 7→ (v1, v2, . . . , vn), x2 7→ (w1, w2, . . . , wn), γ >VarStsMixSnd:< (x1, A, x2) ↪→ C >Cs < x1 7→ (v1, v2, . . . , vn), x2 7→ (w1, w2, . . . , wn), γ >VarSts=⇒< ((v1, A1), . . . , (vn, An)) = ((v1, A ∪ {w1}), (v2, A1 ∪ {w2}), . . . , (vn, An−1 ∪ {wn}))↪→ C >Cs < x1 7→ (v1, v2, . . . , vn), x2 7→ (w1, w2, . . . , wn), γ >VarStsFilter:< (C, f, λ.f(t)) ↪→ C >Cs < x 7→ (v1, v2, . . . , vn), γ >VarSts=⇒< (. . . , vi, . . . | f(vi) = ture) ↪→ C >Cs < x 7→ (v1, v2, . . . , vn), γ >VarStsOnce:< O(x) ↪→ C >Cs < x 7→ v, γ >VarSts=⇒ < (v1, . . . , vn) ↪→ C >Cs < x 7→ v, γ >VarStsMakForwRule:< F (C) ↪→ C >Cs < x 7→ ((v11 , v

21 , v

31), (v

12 , v

22 , v

32), . . . , (v

1n, v

2n, v

3n)), γ >VarSts=⇒

< [(v11 , (v31 , sendout(v

21))), (v

12 , (v

32 , sendout(v

22))), . . . , (v

1n, (v

3n, sendout(v

2n)))]

↪→ C >Cs < x 7→ ((v11 , v21 , v

31), (v

12 , v

22 , v

32), . . . , (v

1n, v

2n, v

3n)), γ >VarSts

MakeRule:< M(C) ↪→ C >Cs < x 7→ ((v11 , a1, v

21), (v

12 , a2, v

22), . . . , (v

1n, an, v

2n)), γ >VarSts=⇒

< [[(v11 , a1(v12)), (v

21 , a2(v

22)), . . . , (v

in, an(v

n2 ))]]

↪→ C >Cs < x 7→ ((v11 , v21 , v

31), (v

12 , v

22 , v

32), . . . , (v

1n, v

2n, v

3n)), γ >VarSts

Assignment:< x := v ↪→ C >Cs < γ >VarSts=⇒ < C >Cs < γ[x 7→ v] >VarStsAddRules:< A(x) ↪→ C >Cs < x 7→ [rl, . . . , rln], γ >VarSts < rl >RlLst =⇒< C >Cs < x 7→ [rl, . . . , rln], γ >VarSts< [rl, . . . , rln] ∪ rl >RlLstRegister:< R ↪→ C >Cs < rl >RlLst < σ >SwchSts =⇒ < C >Cs < [] >RlLst < rl ∪ σ >SwchStsSend:< S(C) ↪→ C >Cs < x 7→ ((v11 , v

21 , v

31), (v

12 , v

22 , v

32), . . . , (v

1n, v

2n, v

3n)), γ >VarSts < h >History

=⇒ < C >Cs < x 7→ ((v11 , v21 , v

31), (v

12 , v

22 , v

32), . . . , (v

1n, v

2n, v

3n)), γ >VarSts

< vi1 7→ {(vi2, vi3), h >History< While (C1) C2 ↪→ C >Cs =⇒ < If (C1) [C2While (C1) C2 ↪→ C] >Cs

Figure 9: Equations and Rules of Dynamic Semantics.


E-ISSN: 2224-2872 409 Volume 13, 2014

(∅, {z 7→ {id1, id2}, x 7→ {((srcport(80), sendall, ), (inport(1), sendcontroller, ))}, [])y = MakeRule(x);(∅, {z 7→ {id1, id2}, x 7→ {((srcport(80), sendall, ), (inport(1), sendcontroller, ))},y 7→ {(srcport(80), [sendall]), (inport(1), [sendcontroller])}}, ∅)z = Lift(z, λt.(t, y));(∅, {z 7→ {(id1, γ(y)), (id2, γ(y))},x 7→ {((srcport(80), sendall, ), (inport(1), sendcontroller, ))},y 7→ {(srcport(80), [sendall]), (inport(1), [sendcontroller])}}, ∅)AddRules(z);(∅, {z 7→ {(id1, γ(y)), (id2, γ(y))},x 7→ {((srcport(80), sendall, ), (inport(1), sendcontroller, ))},y 7→ {(srcport(80), [sendall]), (inport(1), [sendcontroller])}}, {(id1, γ(y)), (id2, γ(y))})Register;({(id1, γ(y)), (id2, γ(y))}, {z 7→ {(id1, γ(y)), (id2, γ(y))},x 7→ {((srcport(80), sendall, ), (inport(1), sendcontroller, ))},y 7→ {(srcport(80), [sendall]), (inport(1), [sendcontroller])}}, ∅)

Figure 10: Program 1.

(∅, {z 7→ {id1, id2}}, [])y = SourceIps;(∅, {z 7→ {id1, id2},y 7→ {(ip1, pk1), (ip2, pk2)}}, ∅)y = ApplyLft(y, λt.(t, port(t)));(∅, {z 7→ {id1, id2},y 7→ {(pr1, pk1), (pr2, pk2)}}, ∅)y = Lift(y, λt.(t, switch(t, z));(∅, {z 7→ {id1, id2},y 7→ {(id1, pr1, pk1), (id2, pr2, pk2)}}, ∅)y = MakForwRule(y);(∅, {z 7→ {id1, id2},y 7→ {(id1, (pk1, sendout(pr1)), (id2, (pk2, sendout(pr2)))}}, ∅)AddRules(y);(∅, {z 7→ {id1, id2},y 7→ {(id1, (pk1, sendout(pr1)), (id2, (pk2, sendout(pr2)))}},{(id1, (pk1, sendout(pr1)), (id2, (pk2, sendout(pr2)))})Register;({(id1, (pk1, sendout(pr1)), (id2, (pk2, sendout(pr2)))}, {z 7→ {id1, id2},y 7→ {(id1, (pk1, sendout(pr1)), (id2, (pk2, sendout(pr2)))}}, ∅)

Figure 11: Program 2.

Figure 12: Static Operational Semantics for Two Control programs in ImpNet.


E-ISSN: 2224-2872 410 Volume 13, 2014

event stored in z. The third statement stores the ruleassignment of z in ir as an initial rule assignment.The last statement of the program adds the establishedrules to the flow tables of switches. Figure 10 showsthe static operational semantics of this program usingthe semantics of the previous section.

The second example constructs forwarding rulesbased on source IPs of arriving packets and then in-stalls the established rules to flow tables of switch IDsstored in z. This program has the following state-ments.

y = SourceIps;

y = ApplyLft(y, λt.(t, port(t)));

y = Lift(y, λt.(t, switch(t, z));

y = MakForwRule(y);

AddRules(y);

Register;

The first statement of the program assumes afunction SourceIps that returns source IPs of arrivingpackets and stores them in the form of an event in y.The second statement transfers event of y into eventof pairs of IPs and port numbers through which pack-ets will be forwarded. The third statement augmentsvalues of event in y with switch IDs from the eventstored in z. The fourth statement makes a forwardrule for each value of the event stored in y. Then thefifth statement stores the rule assignment of y in ir asan initial rule assignment. The last statement of theprogram adds the established rules to the flow tablesof switches. Figure 11 shows the static operationalsemantics of this program using the semantics of theprevious section.

Using a sequence of prohibited IPs (stored in thevariable a), the third example constructs firewall rules.Firewall rules are established by first applying Ap-plyRit that applies a map to get the concerned portnumbers. Then the map Lift is used twice in a rowto add switch IDs to items in b and to determine thatthe action of rules being established is prohibition. Fi-nally the program installs the established rules to flowtables of switch IDs stored in c. This program has thefollowing statements.

a = ProhibtedIps;

b = ApplyRit(a, λt.(t, port(t)));

b = Lift(b, λt.(t, switch(t, c));

b = Lift(b, λt.(t, prohibt(t, c));

b = MakRule(b);

AddRules(b);

Register;

A fourth example, that switches between actionsof forwarding and dropping depending on source IPs,can constructed as a combination of the second andthird examples above.

The examples shown above demonstrate the im-portance and robustness of the programming modeldeveloped for software-defined networks in this pa-per. For example the third example above implementsa very important concept (Firewalling) of networks ina very compact and accurate way.

6 Future WorkThere are many interesting directions for future work.One such direction is to develop methods for staticanalysis of network programming languages. Ob-viously associating these analyses with correctnessproofs, in the spirit of [18, 19, 20, 21], will havemany network applications. Developing denotationalsemantics [17] for network programs is a very inter-esting direction for future research. This will increasethe trust level of these programs. Another direction forfuture work is to develop type systems to detect event-errors in the sense of the work in [23]. Implement-ing the problems of indoor mobile target localization(for wireless sensor networks) [38] and that of CSPssearch strategies [45] (for control network program-mings) using ImpNet are among interesting directionsof future work.

7 ConclusionSoftware-Defined Network (SDN) is a recent architec-ture of networks in which a controller device is used toprogram other network devices (specially switches).This is done via a sequence of installing and unin-stalling of rules to memories of these devices.

In this paper, we presented a high-level impera-tive network programming language, called ImpNet,to facilitate the job of controller. ImpNet producesefficient, yet simple, and powerful programs. Imp-Net has the advantages of simplicity, expressivity,propositionally, and more importantly being impera-tive. The paper also introduced two concrete oper-ational semantics to meanings of ImpNet constructs.One of the proposed semantics is static and the otheris dynamic. Detailed examples of using ImpNet andthe operational semantics were also illustrated in thispaper.

The proposed language can be used to pro-gram many network applications like switch load-balancing. The proposed language can also be real-ized as a new framework for network-programming


E-ISSN: 2224-2872 411 Volume 13, 2014

that enables applying static and dynamic analysistechniques to network programs.

References:

[1] X. Cao, M. Klusch. Dynamic Semantic DataReplication for K-Random Search in Peer-to-Peer Networks. NCA, 2012, p. 20–27.

[2] A. Eftychiou, B. Vrusias, N. Antonopoulos.A dynamically semantic platform for efficientinformation retrieval in P2P networks. IJGUC3(4), 2012, pp. 271–283.

[3] A. Kamoun, S. Tazi, K.l Drira. FADYRCOS,a semantic interoperability framework for col-laborative model-based dynamic reconfigurationof networked services. Computers in Industry(CII), 63(8),2012, pp. 756–765.

[4] I. Lerner, S. Bentin, O. Shriki. Spreading Activa-tion in an Attractor Network With Latching Dy-namics: Automatic Semantic Priming Revisited.Cognitive Science (COGSCI), 36(8), 2012, pp.1339–1382 .

[5] T. Serbanuta, G. Rosu, and J. Meseguer. Arewriting logic approach to operational seman-tics. Inf. Comput., 2009, pp.305–340.

[6] B. Loo, J. Hellerstein, I. Stoica, and R. Ramakr-ishnan. Declarative routing: Extensible rout-ing with declarative queries. SIGCOMM, 2005,pp.289-300.

[7] Z. Cai, A. Cox, and T. Ng. Maestro. A systemfor scalable OpenFlow control. Technical ReportTR10-08, Rice University, Dec 2010.

[8] T. Koponen, M. Casado, N. Gude, J. Stribling,L. Poutievski, M. Zhu, R. Ramanathan, Y. Iwata,H. Inoue, T. Hama, and S. Shenker. Onix: A dis-tributed control platform for large-scale produc-tion networks. OSDI, Oct 2010.

[9] N. Handigol, S. Seetharaman, M. Flajslik, N.McKeown, and R. Johari. Plug-n-Serve. Load-balancing web traffic using OpenFlow. Demo atACM SIGCOMM, Aug 2009.

[10] B. Heller, S. Seetharaman, P. Mahadevan, Y. Yi-akoumis, P. Sharma, S. Banerjee, and N. McK-eown. ElasticTree: Saving energy in data centernetworks. NSDI, Apr 2010.

[11] R. Wang, D. Butnariu, and J. Rexford.OpenFlow-based server load balancing gonewild. Hot-ICE, Mar 2011.

[12] A. Greenberg, G. Hjalmtysson, D. Maltz, A.Myers, J. Rexford, G. Xie, H. Yan, J. Zhan, andH. Zhang. A clean slate 4D approach to networkcontrol and management. SIGCOMM CCR 35,October 2005, pp.41-54.

[13] M. Casado, M. Freedman, J. Pettit, J. Luo, N.Gude, N. McKeown, and S. Shenker. Rethinkingenterprise network control. Trans. on Network-ing. 17(4), Aug 2009.

[14] N. Gude, T. Koponen, J. Pettit, B. Pfaff, M.Casado, N. McKeown, and S. Shenker. NOX:Towards an operating system for networks. SIG-COMM CCR 38(3), 2008.

[15] N. Foster, A. Guha, M. Reitblatt, A. Story,M. Freedman, N. Katta, C. Monsanto, J. Reich,J. Rexford, C. Schlesinger, D. Walker, R. Harri-son. Languages for software-defined networks.IEEE Communications Magazine 51(2), 2013,pp. 128–134.

[16] T. Bain, P. Campbell, J. Karlsson. Modelinggrowth and dynamics of neural networks viamessage passing in Erlang: neural models have anatural home in message passing functional pro-gramming languages. Erlang Workshop, 2011,pp. 94-97.

[17] M. A. El-Zawawy. Semantic spaces in Priest-ley form. PhD thesis, University of Birmingham,UK, 2007.

[18] M. El-Zawawy. Probabilistic pointer analysisfor multithreaded programs. ScienceAsia 37(4),2011, pp. 344-354.

[19] M. El-Zawawy. Detection of Probabilistic Dan-gling References in Multi-core Programs UsingProof-Supported Tools. ICCSA 2013, pp. 516–530.

[20] M. El-Zawawy. Frequent Statement and De-reference Elimination for Distributed Programs.ICCSA, 2013, pp. 82–97.

[21] M. El-Zawawy. Flow sensitive-insensitivepointer analysis based memory safety formultithreaded programs. In: Murgante, B.,Gervasi, O., Iglesias, A., Taniar, D., Apduhan,B.O. (eds.) ICCSA, Part V. LNCS, vol. 6786,Springer, Heidelberg (2011), pp. 355-369.

[22] Mohamed A. El-Zawawy and Adel I. AlSalem.ImNet: An Imperative Network ProgrammingLanguage. In: Proceedings of The 14th Interna-tional Conference on Applied Computer Science– Constantin Buzatu (Ed): ACS 2014, ModernComputer Applications in Science and Educa-tion, pp. 149–156.

[23] M. A. El-Zawawy, N. Daoud. New error-recovery techniques for faulty-calls of functions.Computer and Information Science, 5(3),2012.

[24] T. Suzuki, K. Pinte, T. Cutsem, W. De Meuter, A.Yonezawa. Programming language support forrouting in pervasive networks. PerCom Work-shops, 2011, pp. 226–232.


E-ISSN: 2224-2872 412 Volume 13, 2014

[25] A. Elsts, L. Selavo. A user-centric approachto wireless sensor network programming lan-guages. SESENA 2012, pp. 29–30.

[26] C. Monsanto, N. Foster, R. Harrison, D. Walker.A compiler and run-time system for networkprogramming languages. POPL 2012, pp. 217–230.

[27] S. Hong, Y. Joung. Meso: an object-orientedprogramming language for building strongly-typed internet-based network applications. SAC2013, pp.1579–1586.

[28] J. Rexford. Programming languages for pro-grammable networks. POPL 2012, pp. 215–216.

[29] H. Arneson, C. Langbort. A linear program-ming approach to routing control in networksof constrained linear positive systems. Automat-ica 48(5), 2012, pp. 800-807.

[30] B. Loo, T. Condie, J. Hellerstein, P. Maniatis,T. Roscoe, and I. Stoica. Implementing declara-tive overlays. SIGOPS 39(5), 2005, pp 75-90.

[31] B. Loo, J. Hellerstein, I. Stoica, and R. Ramakr-ishnan. Declarative routing: Extensible routingwith declarative queries. SIGCOMM, 2005, pp.289-300.

[32] N. Foster, R. Harrison, M. Meola, M. Freed-man, J. Rexford, and D. Walker. Frenetic: Ahigh-level langauge for OpenFlow networks.PRESTO, Nov 2010.

[33] N. Foster,R. Harrison, M. Freedman, C. Mon-santo, J. Rexford, A. Story, and D. Walker. Fre-netic: A Network Programming Language.the16th ACM SIGPLAN international conferenceon Functional programming,2011 pp. 279–291.

[34] E. Kohler, R. Morris, B. Chen, J. Jannotti, andM. Kaashoek. The Click modular router. ACMTransactions on Computer Systems 18(3), Aug2000, pp 263-297.

[35] S. Egorov and G. Savchuk. SNORTRAN: AnOptimizing Compiler for Snort Rules. FidelisSecurity Systems, 2002.

[36] V. Paxson. Bro: A system for detecting net-work intruders in realtime. Computer Net-works 31(2324), Dec 1999, pp. 2435-2463.

[37] M. Dobrescu, N. Egi, K. Argyraki, B. Chun,K. Fall, G. Iannaccone, A. Knies, M. Manesh,and S. Ratnasamy. RouteBricks: Exploiting par-allelism to scale software routers. SOSP, Oct2009.

[38] P. Gao, W. Shi, H. Li, W. Zhou. Indoor Mo-bile Target Localization Based on Path-planningand Prediction in Wireless Sensor Networks.WSEAS Transactions on Computers 12(3), 2013,pp. 116–127.

[39] N. McKeown, T. Anderson, H. Balakrishnan,G. Parulkar, L. Peterson, J. Rexford, S. Shenker,and J. Turner. Openflow: Enabling innovation incampus networks. SIGCOMM CCR 38(2), 2008,pp. 69-74.

[40] M. Chen, X. Li, R. Lian, J. Lin, L. Liu, T. Liu,and R. Ju. Shangri-la: Achieving high per-formance from compiled network applicationswhile enabling ease of programming. PLDI, Jun2005, pp 224-236.

[41] V. Bhanumathi, R. Dhanasekaran. Energy Effi-cient Routing with Transmission Power Controlbased Biobjective Path Selection Model for Mo-bile Ad-hoc Network. WSEAS Transactions onComputers 11(11), 2012, pp. 407–417.

[42] M. Cristea, C. Zissulescu, E. Deprettere, andH. Bos. FPL-3E: Towards language support forreconfigurable packet processing. SAMOS, Jul2005, pp 201-212.

[43] The Open Networking Foundation, Mar 2011.See http:// www.opennetworkingfoundation.org/

[44] J. Harding. Decidability of the Equational The-ory of the Continuous Geometry CG(F). J.Philosophical Logic 42(3), 2013, pp. 461–465.

[45] E. Golemanova. Declarative Implementations ofSearch Strategies for Solving CSPs in ControlNetwork Programmings. WSEAS Transactionson Computers 12(4), 2013, pp. 174–183.


E-ISSN: 2224-2872 413 Volume 13, 2014

impnet: programming software-deﬁed networks …imp-net has a clear and simply-structured syntax...

Documents