1 Introduction
In SoftwareDefined Networking (SDN), the control of the whole network is now transferred to the SDN controller which enables a set of network applications to function. It is of a great prominence to be able to analyze these applications for problems prior the actual deployment. Such problems if not fixed might take the whole network down.
A multitude of network analysis frameworks [8, 6, 4, 1, 11] have been devised for analyzing traditional networks, and some of those solutions could possibly be imported into SDN. Network checking tools could be devised on top of such frameworks (e.g., NetPlumber [7]), these tools can read the configurations of network devices then check these configurations for possible networking issues.
We believe that network analysis frameworks can be useful in SDN for the following reasons: (1) SDN applications can be complex, so there is a need to reason about how would they function prior the actual deployment, (2) controllers, in many cases, allow more than one SDN application to run simultaneously. Hence, there is a need to be able to check if those applications would create any conflict, and (3) a whatif analysis for any new rules could be conducted by controllers.
We present SDN Vector Space Analysis (SDNVSA), a framework for modeling SDN control applications. SDNVSA is based on the idea of leveraging the impact which control applications assert on the network information base to reason about the behavior of such applications. The framework models the switching functionalities as affine transformations [13]. While the idea of representing dataplanes as transformations is not novel and was proposed in earlier work [8], our framework specifically targets SDN. To realize such framework, we propose to model the control application as a composite transformation matrix operating on a network information base matrix.
In this paper, we make the following contributions: (1) we propose an analytical framework (SDNVSA) using vector spaces and affine transformations for modeling SDN control application, (2) we present a formulation for such framework which can be used to analyze and reason about SDN control applications, and (3) we discuss a usecase for the proposed framework.
The rest of this paper is organized as follows: In §2, we provide background on the topic and related work. We discuss the need for an SDN framework in §3. The proposed framework is presented in §4. Then, we present our formulation for such framework in §5. The usecase is shown in §6 Finally §7 will be our conclusion and an outline for possible foreseeable work.
2 Related Work
In this section, we survey a number of relevant frameworks which were devised for network analysis. Table 1 includes a summary of these frameworks.
Karsten et al. [6] studied the complexity of the Internet. They found that the current Internet architecture occasionally violates the layered architecture. Thus, it is no longer appropriate to model the network as a graph. So they created an axiomatic framework intended to reason about the forwarding mechanisms in networks and to serve as a basis for verification and formal proofs of correctness of protocols and their implementations. Their formalization is based on highlevel Hoarestyle assertions (Hoarelogic), rather than lowlevel operational semantics. Further, they presented some usecases for their framework including: TCPoverNAT, DNS and Hierarchical Mobile IP. However, their work only considers connectivity, and is oblivious to time and cannot model losses and timeouts.
Kazemian et al. [8] investigated the complexity of current networks. They found that even when individual protocols function correctly, failures can arise from the complex interactions of their aggregate, requiring network administrators to be masters of detail. Thus, they came up with a protocolagnostic framework called “Header Space Analysis” (HSA) based on geometric model for packet classification, with the objective of automatically finding an important class of failures, regardless of the protocols running. They also modeled the network boxes (e.g., switches and routers) as transfer functions that operates on the packet headers. Their formalism allows statically checking network configurations to identify an important class of failures as Reachability Failures, Forwarding Loops and Traffic Isolation and Leakage problems. Moreover, they developed Hassel a tool that realizes HSA and was used to analyze Stanford University’s backbone network. However, their model can only do static analysis of networks to detect forwarding and configuration errors, but in later work [7] they solved that issue by developing NetPlumber.
Kazemian et al. [7] developed NetPlumber after they realized that the network state may change rapidly, and the network must ensure correctness. Policy checkers cannot verify in realtime because of the need to collect state and time information. They also realized that SDN provides an opportunity as it maintains a logically centralized view of the network at the controller. However, the issue of creating a fast compliance checker remains. NetPlumber is based on HSA but unlike HSA, it incrementally checks for compliance of state changes, by maintaining a dependency graph between rules (i.e. a graph of flow tables). The tool was used to detect Loops, BlackHoles and Reachability problems. They evaluated NetPlumber in (1) Google WAN, (2) Stanford Backbone, and (3) Internet2. Finally, NetPlumber (like HSA) relies on reading the state of network devices and therefore cannot model middleboxes with dynamic state, and it requires greater processing time for verifying link updates.
Dhawan et al. [4] were concerned with the security and correct functioning of the entire SDN. They presented SPHINX to detect both known and potentially unknown attacks on network topology and data plane forwarding originating within an SDN. SPHINX leverages the novel abstraction of flow graphs for realtime detection of security threats, enable incremental validation of network updates. SPHINX analyzes specific OpenFlow control messages to learn new network behavior and metadata for both topological and forwarding state. They studied attacks on the network topology such as: ARP poisoning, and fake topology, as well as attacks on dataplane forwarding such as: Controller DoS, Network DoS, TCAM exhaustion, and switching blackholes.
Anderson et al. [1] were concerned with the lack of a semantic foundation to reason precisely about networking code. They studied the network programming languages and found that the design of highlevel languages for programming networks is adhoc, driven by the needs of applications and the capabilities of network hardware than by foundational principles. Thus, they presented NetKAT a new network programming language based on Kleene algebra a solid mathematical foundation and comes equipped with a complete equational theory. NetKAT models the network as an automaton that moves packets from one node to another along the links in its topology and hence makes use of regular expressions and the language of finite automata. As for the usecases, they were concerned with reachability, traffic isolation, access control, and compiler correctness.
Network operators need tools to determine the impact of changes that they make, because bad updates can bring down the entire network. Nelson et al. [11] developed Chimp a tool for static differential analysis of SDN controller programs without the need of formal methods. Chimp can be used to present the semantic or the behavioral difference between any two versions of a program. The tool was demonstrated with a NATing code written in Flowlog. Further, it was tested with a L2 learning switch, roundrobin LB, and ARP cache applications. Chimp relies on Flowlog [12] a declarative language used for writing SDN applications that was developed by the same authors in a previous work. In Flowlog, every rule is equivalent to a firstorder logic formula.
Axiomatic Basis for Communication 
Header Space Analysis 
Real Time Network Policy Checking 
SPHINX 
NetKAT 
Static Diff. Program Analysis for SDN 

Problem 
Internet is complex. Layering violation. 
Networks are complex. Failures can arise from complex interactions of individual protocols that function correctly. 
Networks must ensure correctness while their state may change rapidly. Policy checkers cannot verify in realtime because they need to collect state and need time to analyze it. SDNs provide a logically centralized view but remains the need for a fast compliance checker. 
Security and correct functioning of the entire SDN. 
Design of highlevel network programming languages is adhoc, driven by the needs of applications and capabilities of network hardware than by foundational principles. Lack of a semantic foundation to reason about networking code. 
Bad updates can bring down an entire network. 
Objective 
Present formulation of forwarding mechanisms. Basis for verification and formal proofs of correctness of protocols and their implementations. 
Automatically find an important class of failures, regardless of the protocols running. 
Introduces a realtime policy checking tool (NetPlumber). 
Detect both known and potentially unknown attacks on network topology and data plane forwarding originating within an SDN. 
New network programming language 
Network operators therefore need tools to determine the impact of changes. 
Approach 
Formalization based on highlevel Hoarestyle assertions (Hoarelogic), and can be used to: (1) formally analyze network protocols based on structural properties, (2) derive working prototype implementations of these protocols. 
Protocolagnostic framework: HSA based on geometric model for packet classification. HSA allows to statically check network specs and configs to identify failures as Reachability Failures, Forwarding Loops and Traffic Isolation and Leakage problems. 
Based on HSA but incrementally checks for compliance of state changes, by maintaining a dependency graph between rules (a graph of flow tables). 
Analyzes specific OpenFlow control messages to learn new network behavior and metadata for both topological and forwarding state. Uses flow graphs for realtime detection of security threats, enable incremental validation of network updates. 
A new network programming language based on Kleene algebra a solid mathematical foundation and comes equipped a complete equational theory. 
Presented Chimp a tool for static differential analysis of SDN controller programs without the need of formal methods. It presents the semantic or behavioral difference between two versions of a program. 
Usecase 
TCP over NAT DNS Hierarchical Mobile IP 
Reachability Analysis Loop Detection Slice Isolation 
Loops and BlackHoles Reachability Policies 
(1) Attacks on Network Topology: ARP Poisoning and Fake topology. (2) Attacks on Data Plane Forwarding: Controller DoS, Network DoS, TCAM exhaustion and Switch blackhole. 
Reachability Traffic isolation Access control Compiler correctness 
NAT code in Flowlog. Also: L2 Learning Switch, Roundrobin LB, and ARP cache. 
Issues 
Only studies connectivity. Oblivious to time and cannot model losses and timeouts. 
Only static analysis to detect forwarding and configuration errors. Offers no clues as to whether routing is efficient. 
Relies on reading the state of network devices and therefore cannot model middleboxes with dynamic state. Greater processing time for verifying link updates. 
Focus only on Flowlog (firstorder logic). 

3 The Need for Another Framework
Recent work in network analysis mainly handles the case of static analysis of networks in order to find important classes of failures. However, network states are dynamic and can frequently change, making those frameworks unfeasible for realtime analysis.
Some were not developed to be used during application design as they require a functioning network to monitor and analyze (e.g., SPHINX [12]). Those frameworks depend on monitoring the network state, which means that they can only be used after deployment. Others do not take the application logic into their consideration, and hence fail to model dynamic stateful SDN applications, those that their current state depends on previous states such as statefulfirewalls and network address translation (NAT).
Moreover, we believe that one way to reason about SDN applications is through studying the impact they have on the network information base. Therefore, on contrary to HSA [8] which was designed to be protocolagnostic, our model will not consider packets as first class citizens. HSA models packets as points in header space () while ignoring protocolspecific meanings associated with header bits. However, in SDN OpenFlowenabled switches we only need to consider certain fields (listed in Figure 1) in the packet header such as source IP address, MAC address, and port number, and destination IP address, MAC address, and port number. The reason is that OpenFlow [10] only allows matching against or modifying those fields. As with SPHINX [4], the control logic will be split into OpenFlow [10] primitive control messages. Each control message should be studied carefully and represented as a transform that would change the current network state.
4 The SDNVSA Framework
The proposed framework (SDNVSA) assumes that SDN control applications are deterministic applications (i.e., they produce the same output for a certain input). Hence, the framework can leverage the impact (i.e., via the OpenFlow messages they send to the switches) that applications have on the network information base to reason about such applications. In this section, we make some important definitions, and we present the main axioms of the proposed framework which are required in order to model SDN control applications.
4.1 Definitions
Definition 1
Control Application: is a set of instructions running at the controlplane which has the ability to control the switching functionalities of connected dataplanes and collect information from them via messages of a standard protocol (e.g., OpenFlow).
Definition 2
Action: is an instructions associated with a header, installed by the control application and executed by the dataplane when a flow arrives matching that header. In case of OpenFlow, actions are installed by FLOW_MOD messages.
Definition 3
Network Information Base (NIB): is the aggregate of topology and/or state information that allows a control application to function properly.
4.2 Axioms
The following axioms represent a basis for the SDNVSA framework:
Axiom 1
Any OpenFlow message can be modeled as a linear map in some vector space.
Let be the set of all OpenFlow messages, and is some vector space over a field , then:
,
Axiom 2
Any OpenFlow action can be modeled as a linear map in some vector space (ndimensional space).
Let be the set of all OpenFlow actions, and is some vector space over a field , then:
,
4.3 The Model
From the definitions presented in §4.1 and the Axioms 1 and 2 proposed in §4.2, we can deduce the following corollaries:
Corollary 1
A control application can be modeled as a composite transformation matrix that operates on a network information base matrix.
(1) 
Corollary 2 (The Congruence Principle)
Any two control applications are congruent in a certain vector space ifandonlyif their composite transformation matrices in that vector space are equal.
5 The Formulation
In this section, we present a formulation for the SDNVSA framework, other formulations might also exist. Depending on the control applications, the NIB might include more network information (i.e., applicationspecific or nonOpenFlow) other than just the flow tables. However, in this paper we only formulate flows tables. More specifically, we define space , a vector space over a Galois field [9] of two elements (GF(2)) (for simplicity) where control messages can be represented as linear maps as postulated by Axiom 1. Then, we formulate space as postulated by Axiom 2.
5.1 Assumptions
For simplicity, we make the following assumptions:

OpenFlow counters can be: (1) pertable, (2) perflow, (3) perport, and (4) perqueue counters. However, in this formulation, we only consider perflow counters (we assume a single perflow counter).

We assume that a switch can have a single flowtable. Hence, a switch can be seen equivalent to a flow table.

We are not considering queues and Quality of Service (QoS) in this formulation.

We assume the network topology to be static i.e., no switches can be removed or added.
5.2 Flow Tables Space (space)
Let be the set of all flow tables. A flow table can be modeled as a set of tuples (i.e.,orderedpairs) of rules () and counters () (see Figure 1). Therefore, we define as:
(2) 
Let . Let be two operations (vector addition and scalar multiplication, respectively) such that , and , . We define the vector addition using basic set theory as follows:
(3)  
(4) 
We define the scalar multiplication as follows:
(5)  
(6) 
Moreover, for every flow table with a number () of flow rules (), we can define another flow table with an equal number () of flow rules, such that every flow rule () in has an additive inverse () in .
Since, the following conditions are satisfied [14]:
(7)  
(8)  
(9)  
(10)  
(11)  
(12)  
(13)  
(14) 
Therefore, space is a vector space over a Galois field of two elements.
5.3 Flow Rules Space (space)
Let be the set of all flow rules. A flow rule can be modeled as a vector (tuple) of: (1) a header (to match against) where is the number of OpenFlow header fields, (2) an output port , (3) a timetolive (we assume one type of TTL), and (4) a set of actions (a composite transformation matrix).
(15) 
In HSA [8], the space is protocolagnostic. Hence, it views a packet header as a sequence of ones and zeros in an dimensional space () ( is the header length in bits). We model ^{1}^{1}1In this paper, we are not going to prove that the space satisfies the conditions of a vector space, as the vector spaces of the individual components comprising a flow rule are wellknown. a header in a similar way, but we only consider the case of OpenFlow. In particular, we represent a header as a tuple of the OpenFlow’s fixedlength header fields (see Figure 1):
(16) 
An action is a function in the flow header , hence it can be modeled as follows:
(17) 
Finally, for every flow rule with a set of actions , we can define another flow rule with the same flow header and the same output port , such that has a set of actions . Let
be the identity matrix, then:
(18) 
We call the additive inverse of .
(19) 
5.4 Example: FLOW_MOD
In OpenFlow, a FLOW_MOD message can be used to add, modify, or delete a flow rule from a flow table. In case of add or modify commands, an action list needs to be specified. The following actions are supported by OpenFlow:
5.4.1 Forward
An OFPAT_OUTPUT action is responsible for outputting any matched flow to a specific switch port i.e., forwarding. A forward action () can be modeled as a translation of the output port () by as follows:
(20) 
5.4.2 Drop
In OpenFlow, a packet belonging to a matched flow is dropped when the flow rule has an empty action list. Therefore, a flow dropping action () can be modeled as a zeroscaling transformation as follows:
(21) 
5.4.3 ModifyField
In OpenFlow, certain header fields () can be modified (see Figure 1) by a modifyfield action. Hence, a modifyfield action () can be modeled as a translation of the flow header by as follows:
(22) 
6 Usecases
6.1 SDN Service Chaining
With the increasing popularity of SDN as an enabler technology for Network Function Virtualization (NFV) in the Cloud, network service providers tend to implement their middleboxed network services as Virtualized Network Functions (VNF) [2]. Such services include but are not limited to loadbalancers, firewalls and Intrusion Detection Systems (IDS) [5]. The process of chaining those services is known as service chaining.
Oftentimes, network service providers  for many reasons  tend to steer different flows across different sets of middleboxes (i.e., services) [15]. Recent research is concerned with the issues of steering packets through different middleboxes [3]. Moreover, in some cases, the order at which the flows steer the network services matters. For example, in the simple case of two services (show in Figure 2): a loadbalancer and an IDS, it is often more appropriate to steer incoming flows through the IDS first then the loadbalancer in order to reduce the latency (the NIB used in this paper does not countin latencies) or prevent any malicious flows from reaching the loadbalanced servers. In such case, we believe that the proposed framework can be used to reason about flow steering in SDNenabled network services.
As network services are also control applications, then based on Corollary 1 (see §4.3) of the proposed framework, they can be modeled individually as composite transformation matrices. Additionally, we can simply deduce the following Corollary:
Corollary 3
Any chain of services can be modeled as a composite transformation matrix of its set of services that operates on a network information base matrix in some vector space.
We can also deduce from Corollary 2 (see §4.3) “The Congruence Principle” that any two chains of services are congruent in a certain vector space ifandonlyif their composite transformation matrices in that vector space are equal.
Moreover, based on the fact that matrix multiplication is noncommutative, different orders of same services can yield different composite transformation matrices. However, as translation is isomorphic in space , order does not matter in any service chain that only contains translations.
For example, assume the following two service chains (shown in Figure 2): (1) IDS LB (shown in blue in Figure 2), and (2) LB IDS (shown in red in Figure 2). Let be a forwarding action, be a drop action, and be a composite action of modify then forward actions. Let be a function which given a certain header , returns the total number of flows having the same source field as . And let
be the anomaly detection threshold.
(23) 
Let be a function that given a certain server’s IP address , returns the total number of flows currently handled by that server.
(24) 
In the first case (IDS LB), the control transformation matrices ( and ) would be:
(25) 
(26) 
(27) 
Where is the loadbalancer’s port. , and are the first and second server’s ports, respectively.
In the second case (LB IDS), the control transformation matrices ( and ) would be:
(28) 
(29) 
(30) 
(31) 
Where is the IDS’s port. is the port of server with an IP address .
(32) 
6.2 Discussion on UsesCases
In this paper, we only presented the usecase of analyzing flow steering in network service chains. However, the proposed framework could be used for other usescases. For example, we believe that the SDNVSA framework can be used in the detection of forwarding loops. A forward loop is created when a packet (with an unchanged header) returns to a port it previously visited [8]. Using SDNVSA, a forwarding loop could be detected by analyzing the composite transformation matrix. In particular, by scanning the flow tables and looking for flow rules that have additive inverses (see §5.3).
7 Conclusion and Future Work
In this paper, we proposed SDNVSA, a framework that uses affine transformations and vector spaces to model SDN control applications. Then, we presented a formulation for the framework that can be used in the analysis of SDN control applications. Finally, we showed a usescase for the SDNVSA framework. In the future, we plan to explore more usecases for such framework. Nonetheless, we plan to explore other formulations for the SDNVSA framework using different vector spaces which can support more complex OpenFlow functionalities as QoS.
Acknowledgment
The second author acknowledges support from the Natural Sciences and Engineering Research Council of Canada (NSERC) through the NSERC Discovery Grant program. The authors would like to thank Jason Jaskolka for his invaluable remarks on an earlier draft of the paper.
References
 [1] C. J. Anderson, N. Foster, A. Guha, J.B. Jeannin, D. Kozen, C. Schlesinger, and D. Walker. Netkat: Semantic foundations for networks. ACM SIGPLAN Notices, 49(1):113–126, 2014.
 [2] M. F. Bari, S. R. Chowdhury, R. Ahmed, and R. Boutaba. On orchestrating virtual network functions. In Network and Service Management (CNSM), 2015 11th International Conference on, pages 50–56. IEEE, 2015.
 [3] J. C. Chukwu and A. Matrawy. One pass packet steering (opps) for stateless policy chains in multisubscriber sdn. In 2017 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), May 2017.
 [4] M. Dhawan, R. Poddar, K. Mahajan, and V. Mann. Sphinx: Detecting security attacks in softwaredefined networks. In Proceedings of the 2015 Network and Distributed System Security (NDSS) Symposium, 2015.
 [5] D. A. Joseph, A. Tavakoli, and I. Stoica. A policyaware switching layer for data centers. In ACM SIGCOMM Computer Communication Review, volume 38, pages 51–62. ACM, 2008.
 [6] M. Karsten, S. Keshav, S. Prasad, and M. Beg. An axiomatic basis for communication. In ACM SIGCOMM Computer Communication Review, volume 37, pages 217–228. ACM, 2007.
 [7] P. Kazemian, M. Chan, H. Zeng, G. Varghese, N. McKeown, and S. Whyte. Real time network policy checking using header space analysis. In NSDI, pages 99–111, 2013.
 [8] P. Kazemian, G. Varghese, and N. McKeown. Header space analysis: Static checking for networks. In NSDI, pages 113–126, 2012.
 [9] R. Lidl and H. Niederreiter. Finite fields, volume 20. Cambridge university press, 1997.
 [10] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner. Openflow: enabling innovation in campus networks. ACM SIGCOMM Computer Communication Review, 38(2):69–74, 2008.
 [11] T. Nelson, A. D. Ferguson, and S. Krishnamurthi. Static differential program analysis for softwaredefined networks. In FM 2015: Formal Methods, pages 395–413. Springer, 2015.
 [12] T. Nelson, A. D. Ferguson, M. J. Scheer, and S. Krishnamurthi. Tierless programming and reasoning for softwaredefined networks. NSDI, Apr, 2014.
 [13] E. W. Weisstein. Affine transformation. 2017. http://mathworld.wolfram.com/AffineTransformation.html.
 [14] E. W. Weisstein. Vector space. 2017. http://mathworld.wolfram.com/VectorSpace.html.
 [15] Y. Zhang, N. Beheshti, L. Beliveau, G. Lefebvre, R. Manghirmalani, R. Mishra, R. Patneyt, M. Shirazipour, R. Subrahmaniam, C. Truchan, et al. Steering: A softwaredefined networking for inline service chaining. In Network Protocols (ICNP), 2013 21st IEEE International Conference on, pages 1–10. IEEE, 2013.
Comments
There are no comments yet.