c• Copyright by Ateeth Kumar Thirukkovulur 2015

All Rights Reserved

NOVEL INFRASTRUCTURE QUANTIFICATION FOR UTILITY

OF VIRTUALIZED NETWORK DEBUGGING USING

OPENFLOW AS VISUALIZATION OF PACKETS AND

SOFTWARE DEFINED NETWORKING

A Thesis

Presented to

the Faculty of the Department of Electrical and Computer Engineering

University of Houston

In Partial Fulfillment

of the Requirements for the Degree

Master of Science

in Electrical Engineering

by

Ateeth Kumar Thirukkovulur

May 2015

NOVEL INFRASTRUCTURE QUANTIFICATION FOR UTILITY

OF VIRTUALIZED NETWORK DEBUGGING USING

OPENFLOW AS VISUALIZATION OF PACKETS AND

SOFTWARE DEFINED NETWORKING

Ateeth Kumar Thirukkovulur

Approved:

Chair of the CommitteeDr. Zhu Han, Associate ProfessorElectrical and Computer Engineering

Committee Members:

Dr. Deniz Gurkan, Associate ProfessorEngineering Technology

Dr. John C. Wolfe, ProfessorElectrical and Computer Engineering

Dr. Suresh K. Khator, Associate DeanCullen College of Engineering

Dr. Badri Roysam, Professor and ChairElectrical and Computer Engineering

Acknowledgments

I am very grateful to my thesis supervisors, Dr. Zhu Han and Dr. Deniz Gurkan,

for their guidance, encouragement, patience, and support during the course of this

work. I have encountered many di�culties, but your help made this thesis possible.

I would like to thank Dr. John Wolfe for being my thesis committee member

and providing valuable suggestions. I would like to thank my other friends in the

University of Houston for all their support, entertainment, and caring.

My special thank goes to my parents Mr. Venu Gopal Swamy, Mrs. Hemalatha

and my sister. They are the most important persons in my life. To them I dedicate

this thesis.

v

NOVEL INFRASTRUCTURE QUANTIFICATION FOR UTILITY

OF VIRTUALIZED NETWORK DEBUGGING USING

OPENFLOW AS VISUALIZATION OF PACKETS AND

SOFTWARE DEFINED NETWORKING

An Abstract

of a

Thesis

Presented to

the Faculty of the Department of Electrical and Computer Engineering

University of Houston

In Partial Fulfillment

of the Requirements for the Degree

Master of Science

in Electrical Engineering

by

Ateeth Kumar Thirukkovulur

May 2015

Abstract

Network debugging is time and resource consuming due to limited access and

monitoring mechanisms. Such mechanisms may involve polling and/or active notifica-

tion methods, where a failed network device may obscure the flow of poll responses in

the network. We developed a network debugging mechanism facilitating the virtual-

ization of a monitoring system through implementation of an extension to Wireshark,

while leveraging the software-defined network principles of control and data plane sep-

aration. We provide translation mechanism though wireshark entries for filtering and

zooming into flows of interest on specific ports with a global view of the network

using OpenFlow protocol as the filtering switch for span tra�c. Furthermore, we also

created a utility of deployment function for a network debugging scheme to evaluate

the usability of locations and numbers of flow-separation based analysis nodes. We

applied our evaluation method on a typical enterprise network such as University of

Houston. Our utility function can provide a usability and e�ectiveness metric for

such debugging features around the network to better realize visualization of most

relevant tra�c.

vii

Table of ContentsAcknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Thesis Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.1 Usage of Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.2 Network analysis through flow separation . . . . . . . . . . . . 6

1.4.3 Controller development . . . . . . . . . . . . . . . . . . . . . . 7

1.4.4 Network policies and flow visibility . . . . . . . . . . . . . . . 7

1.4.5 Enterprise network debugging . . . . . . . . . . . . . . . . . . 8

2 OpenFlow, Networking Concepts and Tools . . . . . . . . . . . . . . 11

2.1 OpenFlow Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Tra�c Generation Tools . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4 A Tra�c Analysis Tool - sFlow . . . . . . . . . . . . . . . . . . . . . 16

2.4.1 The sFlow Sampling Process and Algorithm . . . . . . . . . . 17

3 Preliminary Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 Label Space Filtering through OpenFlow . . . . . . . . . . . . . . . . 19

3.2 E�ectiveness of the translator tool . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Baseline on a Popular Tool: Wireshark . . . . . . . . . . . . . 21

viii

3.2.2 Can a translator span the entire label space? . . . . . . . . . . 21

3.2.3 Usage Considerations . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.4 Deployment Platform . . . . . . . . . . . . . . . . . . . . . . . 22

3.3 Preliminary Data Sources: Tra�c Statistics from University of Houston 23

4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1 Translator tool implementation in Enterprise Level Deployment . . . 25

4.2 Calculating Utility of Deployment(UDF) . . . . . . . . . . . . . . . . 28

5 Results and Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1 Proof of Concept to show working of the translator tool . . . . . . . . 33

5.2 Results of UDF for SPAN Deployment . . . . . . . . . . . . . . . . . 35

6 Conclusion and Future Work . . . . . . . . . . . . . . . . . . . . . . . 41

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Appendix A. Pica P3290 48 x 1 GbE . . . . . . . . . . . . . . . . . . . . 49

Appendix B. Tra�c Statistics for links between Core Switches and

Services at the University of Houston . . . . . . . . . . . . . . . . . . 51

Appendix C. OpenFlow Specification . . . . . . . . . . . . . . . . . . . . 58

ix

List of Figures

Figure 1.1 Aggregation network devices with the hierarchy of access switches,

departments, and buildings at the University of Houston produc-

tion network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Figure 1.2 Aggregation points will be equipped with the SDN overlay network

devices to enable enhanced network debugging in addition to other

SDN paradigm capabilities. . . . . . . . . . . . . . . . . . . . . . 4

Figure 1.3 Principles of flow separation through network programming will

be applied at the aggregation points with SDN network devices as

illustrated here. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Figure 2.1 SDN separates control plane from forwarding elements where south-

bound protocol may be OpenFlow and various northbound appli-

cations may have a logically centralized view of the network. . . . 12

Figure 2.2 Flowchart showing packet flow through OpenFlow switch and con-

troller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Figure 2.3 Figure illustrating architecture of Wireshark. . . . . . . . . . . . . 15

Figure 2.4 Description of sFlow agent and collector process. . . . . . . . . . 17

Figure 2.5 Code illustrating the sFlow Sampling Algorithm. . . . . . . . . . 18

Figure 3.1 Working of the translator tool for debugging OpenFlow switches. 19

Figure 3.2 Timing interaction diagram of the translator tool. . . . . . . . . . 20

Figure 3.3 UH Campus topology considered for calculation of UDF with traf-

fic statistics indicated on the links between core switches and out-

bound services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

x

Figure 4.1 Implementation of Translator tool in a network enterprise illustrat-

ing how span tra�c is used alongwith SDN capability to monitor

and zoom into flows of interest. . . . . . . . . . . . . . . . . . . . 25

Figure 4.2 Label Space Filtering Tool, a modified wireshark with capability

to set the OpenFlow controller IP and filter entry for translation

corresponding to OpenFlow rules on switches. . . . . . . . . . . . 27

Figure 4.3 Filter entry for translation to zoom into flows of interest. . . . . . 27

Figure 4.4 (a)(top) Spanning limited switches does not give 100% visibility to

zoom into a flow. (b)(below) Spanning all switches is optimal in

the sense that 100% control to zoom into every flow at every point. 29

Figure 4.5 An example of a topology to find the utility of deployment. . . . . 30

Figure 5.1 Emulation of sample aggregation topology for demonstrating zoom-

ing into flows of interest for network debugging. . . . . . . . . . . 33

Figure 5.2 Dotted line shows sum of tra�c from each of the VMs 172.16.5.20,

172.16.5.1 and 172.16.5.2. At T=30s a filter entry translated to

flow rule set on the aggregation switch (dp4) resulting in blocking

tra�c from VM1. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Figure 5.3 Sample campus flow pairs of interest and a given deployment. . . 35

Figure 5.4 Maximum achievable UDF for the case considered above spanning

only two intersection switches as shown in Fig 5.3. Achieved at 73%. 36

Figure 5.5 University of Houston CORE / BGP Router Weathermap (Source:

http://monitor.hpcc.uh.edu). . . . . . . . . . . . . . . . . . . . . 36

Figure 5.6 Flowset from Vespesian to UHV/SDC has the highest utility of

28.4 and is justified as flows have to pass through Caesar which is

spanned. Value is slightly less than the Caesar diagram because

Vespesian being a core switch is not spanned in our case. . . . . . 38

xi

Figure 5.7 Flow activity is the highest for links on caesar to SETG and UHV/SDC.

Since caesar is the core switch for consideration, and also since it is

spanned, the value for UDF is 33.53, the hightest among all graphs. 38

Figure 5.8 Caesar which is spanned, does not come in between flow activity

from core Cornelia to either Zayo, Flavia or OPT-E-MAN. There-

fore utility for these cases are Zero and are justified. . . . . . . . . 39

Figure 5.9 Flavia has connectivity to other switches and services directly with-

out passing though Caesar. Therefore utility for only flowsets to

Caesar, SETG and UHV/SDC are indicated whereas others remain

zero. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Figure 5.10 Utilities for Gracchus to SETG and UHV/SDC are the highest

among other individual flowsets in this figure, being 16.04 and 17.06

respectively. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Figure 5.11 Suebi has the least utility for SETG and UHV/SDC because tra�c

has to travel the most switches which reduces the e�ectiveness of

network debugging since all switches are not spanned. . . . . . . . 40

Figure A.1 Product Reference Guide for Pica P-3290 Switch . . . . . . . . . 50

Figure C.1 OpenFlow 1.0 Flow Entry List . . . . . . . . . . . . . . . . . . . . 59

Figure C.2 Match Field Details . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Figure C.3 Field-modify Actions . . . . . . . . . . . . . . . . . . . . . . . . . 61

xii

List of Tables

Table 2.1 Di�erent Tra�c Generation Tools and Platforms. . . . . . . . . . . 14

Table 4.1 Header fields and flow mapping of filter entries. . . . . . . . . . . . 28

Table 5.1 Tra�c flow statistcis of yearly average inbound flow for UH Core

and BGP Routers. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

xiii

Chapter 1

Introduction

1.1 Background

On enterprise campus networks such as the University of Houston, it becomes

increasingly di�cult to handle monitoring of specific flows of interest when upgrad-

ing connectivity to 100 Gbps. Furthermore, the upgrade in the production network

brings the capability to program flow handling on the fly through southbound proto-

cols such as the OpenFlow with the Software-Defined Networking (SDN) paradigm.

In this respect, while University of Houston is building an SDN overlay, network trou-

bleshooting capabilities can also be enhanced through such programming capabilities

based on the principles of flow separation. We propose to realize such troubleshoot-

ing through a network debugging interface developed on the open source interface

listening tool, Wireshark. Also, Utility Deployment Function (UDF) is created to

measure the extent at which a network engineer may gain visibility to the flows of

interest for a given specific deployment scenario of a number of flow analysis nodes

and their locations on the network. The deployment choices then can be evaluated

with a return on investment consideration on percentage of tra�c to be analyzed and

the specific types of flows to be visible against the cost of deployment for such nodes.

Network debugging is a time consuming network management activity due to

manual labor and physical connectivity requirements resulting in limited monitoring

mechanisms [1] classified based on link-oriented, energy related, packet handling,

timing or state change. Especially, enterprise networks with aggregation points [2]

where di�erent services and departmental tra�c is combined as trunks, monitoring

and troubleshooting on a particular flow is challenging with no means to have in-depth

1

visibility with fine granularity. Although such aggregated tra�c can be combined at

a span port, the analysis network nodes can become too costly to deploy prolifically.

An intelligent and targeted deployment strategy coupled with a robust flow filtering

mechanism per network engineers’ usage is needed to gain the most utility out of such

a network function with optimized return on investment. In this respect, this thesis

presents our network debugging tool based on flow filtering and separation analysis

in addition to a proposed utility of deployment function. In addition, the application

of the utility function on a typical enterprise university campus network is included

with an emulation experiment conducted on the GENI [3] (Global Environment for

Network Innovation).

1.2 Motivation

This thesis builds on top of the campus-wide network upgrade enabled by the 100

Gbps connectivity to the Internet2 while creating an SDN overlay through OpenFlow-

capable networking devices. The proposed methods will utilize the SDN infrastructure

to deliver this tool to the University of Houston network engineers.

Fig 1.1 illustrates the University of Houston’s aggregation-based network design

and how programmable points will be leveraged to separate flows through virtual

tap decision points with SDN network devices. In this respect, while University of

Houston is building an SDN overlay as shown in Fig 1.2, network troubleshooting

capabilities represented in Fig 1.3 can also be enhanced through such programming

capabilities based on flow separation detailed in this thesis.

1.3 Thesis Contribution

This thesis achieved a functional definition for the utility of deployment of net-

work debugging nodes on an enterprise setting. Furthermore, the thesis resulted in

2

Figure 1.1: Aggregation network devices with the hierarchy of access switches, depart-ments, and buildings at the University of Houston production network.

implementation of an network feature based on OpenFlow protocol matching struc-

tures to filter and zoom into flows of interest using span tra�c. Using work from

this thesis, the University of Houston can implement monitoring and handling while

upgrading their production network to 100Gbps.

Although security considerations are sole proprietary for University of Houston,

much of the data used for research has to be deemed safe for public access and

contribute a great deal to the direction of research. Above all campus production data

fed to this tool will be pre-filtered and will be granted access to encourage research in

this specific area while implementing network debugging. Since production network

feed is of high security importance, the scope of this thesis has been restricted to

proof of concept based on similar replica.

Currently, it is not possible to actively zoom into tra�c without disturbing

network tra�c flow. Therefore, we used the concept of SDN to passively monitor

network flow (span) and actively control analysis network using e�ective network

debugging methods (translator tool used for label space filtering with OpenFlow).

3

Figure 1.2: Aggregation points will be equipped with the SDN overlay network devicesto enable enhanced network debugging in addition to other SDN paradigmcapabilities.

Figure 1.3: Principles of flow separation through network programming will be applied atthe aggregation points with SDN network devices as illustrated here.

Comprehensive interface monitoring was achieved for flow based network de-

bugging and troubleshooting on GENI Network testbed as well as Pica P3290 on

a fully enabled OpenFlow switch. Filter entry of any label segment for OpenFlow

protocol has been designed and implemented in the translator tool for SDN network

debbugging of analysis production network.

The utility of deployment function quantifies the feasibility for placement of

spans in the network for debugging specific flows. The Utility of Deployment Function

(UDF) is used to calculate the utility on a given network topology to determine the

e�ectiveness of using translator tool that converts to OpenFlow protocol from the

filter entries. An enterprise network topology that is being used at the University

4

of Houston is taken to derive the utility for a given deployment based on network

tra�c statistics and possibility of placing a span at one of the core network switch,

namely Caesar. This is found, given a specific deployment scenario of a number of flow

analysis nodes and their locations on a typical campus network taken as an example

enterprise setting. Furthermore, the utility function helps determine the return on

investment for such middle boxes on the network.

The remainder of this thesis is structured as follows. In Chapter 2, we present

various technologies used to develop and validate this thesis work. Chapter 3 presents

an approach to how the tool is developed for network debugging and all preliminary

work for this thesis. In Chapter 4, we present how to determine and calculate the Util-

ity of Deployment Function (UDF). Lastly, Chapter 5 discusses the proof of concept

and resulting measurements of UDF for specific deployment case studies.

1.4 Literature Review

1.4.1 Usage of Middleboxes

In the recent past there have been numerous research investigations on features

provided in enterprise networks by routing tra�c through middleboxes. Middle-

boxes [4] generally represent firewalls, content filters, intrusion detection systems,

NAT, caches, load balancers, accelerators [5]. One such development is StEERING

[6] which is based on software defined networking (SDN) and OpenFlow protocol,

providing inline services and forwarding through a centralized configuration to steer

flows selectively. Basically, it is a scalable framework for dynamically routing traf-

fic through any sequence of middleboxes using SDN allowing network operators to

monetize their middlebox deployment in new ways. Given the forecasts of tra�c

growth and reduction of average revenue per user, network operators must address

the problem of reducing costs with deployment of middleboxes [7, 8].

5

1.4.2 Network analysis through flow separation

A recent deployment in enterprise networks by Big Switch Networks is the Big

Tap Monitoring FabricTM[9]. It is a cluster of SDN-enabled Big Tap Controllers, a

pair of virtual machines or hardware appliances that enable centralized configuration,

monitoring and troubleshooting in a simplified manner. Big Tap enables one to tap

into the overall tra�c and consecutively, deliver it to a set of troubleshooting and/or

monitoring tools. However, it requires expensive bare-metal nodes to run and the

filter layer is not as comprehensive as the Wireshark.

The campus network of our study is designed in a hierarchical manner which is

a common practice of campus and enterprise networks [10]. It provides a modular

topology of building blocks that allow the network to evolve easily. A hierarchical

design avoids the need for a fully-meshed network in which all network nodes are

interconnected. The building block components are the access layer, the distribution

layer, and the core (backbone) layer. Hierarchical network models are usually derived

in an iterative way by replicating the initial cluster of the network according to a

certain rule.

For instance, consider an initial network of x fully interconnected nodes (N = x).

As a next step, create (x≠1) replicas of this cluster and connect the peripheral nodes

of each replica to the central node of the original cluster. This step can be repeated

indefinitely, thereby for any k steps the number of nodes in the system can be derived

by

N = x

k+1. (1.1)

There is another approach in industry for tapping into OpenFlow switches using

the ONF SampleTap [11] application, which is a simple OpenFlow application on

OpenDaylight Controller [12]. This serves educational goals and is a portable tapping

application developed by Open Networking Foundation. It has the ability to place

6

match criteria on the incoming tap port, add port-chains for transformation (e.g.,

truncation, decryption) and multiple capture devices. We utilize a mechanism similar

to ONF OpenFlow tapping but with wireshark to tap and capture tra�c from any

OpenFlow switch on the enterprise network. Also, ONF tapping was specifically

written to work with only the OpenDaylight controller application but the use of our

tapping mechanism can be applied to work with multiple OpenFlow controllers in the

industry to interact with the switches.

In [13], a study has been conducted to provide a mathematically accurate mech-

anism to describe sequential property of a network flow using temporal extension to

the Wireshark display filter. It extends Wireshark’s network analysis power.

1.4.3 Controller development

We also conducted a literature study on the choice of a controller, FloodLight.

Most important reasons for choosing this controller are summarized below.

1. Works with physical- and virtual- switches that speak the OpenFlow protocol.

2. Minimal dependencies.

3. Handle mixed OpenFlow and non-OpenFlow networks.

4. Has the ability to design northbound API’s.

5. Module loading system that make it simple to extend and enhance.

6. Its powerful http web UI that is accessible anywhere.

7. REST based interface.

1.4.4 Network policies and flow visibility

Our literature study covers another important aspect of networks which is real

time policy checking using header space analysis (HSA) [14]. The most important

7

problem of managing networks is that several entities can modify the forwarding rules-

adding manual configuration, distributed protocols (e.g., OSPF, spanning tree, BGP)

write entries into forwarding tables and so on. Researchers in Stanford presented an

application called NetPlumber [15] using HSA which sits in line with the control plane,

and observes state changes (e.g., OpenFlow messages) between the control plane and

the switches. They use this application to detect simple invariant violations such as

loops and reachability failures. Although HSA can pinpoint the specific entry in the

forwarding table that causes a problem, it does not tell us how or why those entries

were inserted or how they will be evolved as the switch receives future messages. Using

the proposed method, we will be having complete visibility of the state changes in a

network with the ability to modify forwarding entries in real-time.

There have been e�orts to define a single network-wide fine-grain policy sup-

porting both wired and wireless hosts in campus networks and enterprises [16]. They

use a centralized controller that manages the admittance and routing of flows but

there has not been such transformation for fully operational software networks in

university campuses till date. Also, there are control domains that are used to set

certain conditions and assign appropriate packet forwarding actions corresponding to

each condition. One such control domain is Procera network control framework [17].

1.4.5 Enterprise network debugging

Our approach to Enterprise network debugging also rules out the use of Dis-

tributive Collaborative monitoring [18] or per flow monitoring by installing filters in

switches to perform debugging/monitoring activities. Suppose in DCM, the number

of flows monitored by switch exceeds a threshold number, there is a high probability

to miss a flow [19] because of lack of memory space in those cases. Accommodating

these large number of flow rules is not a viable solution [20] since TCAM is costly

and power hungry. Also such installation, updating and reconstruction in enterprise

8

is costly as it a�ects production network and does not guarantee security enforcing

high-level security policies [21].

Network applications can use high level interface to monitor network status

without being concerned about the low level details. In order to keep the switch

design simple, this statistics collection mechanism is implemented as a pull- based

service, i.e. network applications and in turn the controller has to periodically query

the switches about flow statistics. [22] uses PayLess, an adaptive statistics collection

algorithm that delivers highly accurate information in real-time without incurring

significant network overhead.

To accommodate increase in tra�c demands, the amount of link resources will

likely not be a problem in the future Internet, the management of these resources will

become more important [23].

Also from the debugging perspective, identifying applications to the level of

protocol by matching the port numbers is a di�cult task. Many applications do not

have IANA registered ports [24, 25].For instance, BitTorrent can also make use of

random ports, complicating their identification by default communication ports.

To measure the extent of visibility of flows using data measurements from enter-

prise networks, except for sFlow, NetFlow [26] and JFlow [27] are both proprietary

solutions and incur a large up-front licensing and setup cost to be deployed in a net-

work. sFlow is less expensive to deploy, but it is not widely adopted by the vendors.

From this Literature survey, it can be concluded that several approaches are

possible for debugging in an enterprise network. The flow selectivity approach used

by Midddleboxes require the use of several additional hardware that needs to be

deployed in a network, consuming more resources. Our approach uses span tra�c

instead, thereby giving a centralized visibility and giving a deeper selectivity of tra�c

flow. There are some approaches like Big Tap monitoring that use SDN to analyze a

network but, such mechanisms are not as comprehensive as Wireshark. Installation

9

of filters in a production network instead of using span tra�c seems costly as it might

not accommodate a large number of flows rules and also does not guarantee enforcing

security policy. Approaches studied in this survey fail in some way or another and

our approach seems more complete, comprehensive and flexible.

10

Chapter 2

OpenFlow, Networking Concepts and Tools

2.1 OpenFlow Protocol

The OpenFlow protocol provides the means to configure the behavior and the

actions of a network with open/programmable interfaces [28] to the network ele-

ments instead of the traditional vendor-specific/proprietary command line interface

(CLI), network management (simple network management protocol, SNMP), and

other polling protocols as outlined in the OpenFlow Specification [29]. OpenFlow

provides mechanisms to define flows that will abide by policies on automatic path

selection with some characteristics such as bandwidth, latency, reducing the number

of hops and reducing the required energy that needs tra�c to reach its destination.

OpenFlow protocol and SDN paradigm has been deployed on the Google’s wide area

network that connects the data centers worldwide [30].

In a legacy switch, fast packet forwarding [31] (data path) and the high level

routing decisions (control path) occur on the same device. Fig 2.1 shows how SDN

separates these two domains physically and creates a logically centralized view and

management of the network. Data-path stays on the switch whereas high level routing

decisions are managed by an OpenFlow controller. The switch and the controller may

communicate via the OpenFlow protocol. We have used this concept to keep the data

plane intact via the switches deployed on campus, controlling them using a centralized

controller which talks to our modified tool.

On receiving a packet-in message the switch performs the operations as shown

in Fig 2.2 detailed below. Initially the switch checks its flow table to see if there is

a rule to indicate what action is performed else the switch sends the packet-in to the

11

Figure 2.1: SDN separates control plane from forwarding elements where southbound pro-tocol may be OpenFlow and various northbound applications may have alogically centralized view of the network.

controller and waits for a response. Basically, the first packet of incoming tra�c for a

rule that has not been set on the switch is analysed by the controller. The controller

analyzes the packet headers to obtain source and destination information. Then the

controller inserts necessary rules in the switch so that the switch can route the packet

to its destination. OpenFlow uses the concept of flows to identify network tra�c

based on pre-defined match rules that can be statically or dynamically programmed

by the SDN control software. We use the concept of statically pushing flows to the

controller with our developed translator tool after monitoring the network.

12

Figure 2.2: Flowchart showing packet flow through OpenFlow switch and controller.

13

2.2 Tra�c Generation Tools

Table 2.1: Di�erent Tra�c Generation Tools and Platforms.

TOOL DESCRIPTION

Ostinato [32] Ostinato is an open-source, cross-platform network packet crafter/tra�c gen-

erator and analyzer with a friendly GUI. It crafts and sends packets of several

streams with di�erent protocols at di�erent rates.

Tmix [33] Tmix is a tra�c generator for ns-2 that reads a packet header trace, derives

a source-level characterization of each TCP connection, and then emulates in

ns-2 the application that created the TCP connections in the trace.

Rude Crude [34] Rude/crude are two programs that can generate and collect UDP tra�c.

RUDE (Real-time UDP Data Emitter) is a small and flexible program that

generates tra�c to the network, which can be received.

Network tra�c

generator [35]

Network tra�c generator generates massive amounts of tra�c of certain type

to test network devices such as routers and firewalls.

NetSpec [36] NetSpec provides a fairly generic framework that can be used by a user to

control multiple processes across multiple hosts from a central point of control

for doing network testing.

Netperf [37] Netperf is a benchmark that can be use to measure various aspect of net-

working performance. The primary foci are unidirectional data transfer and

request/response performance using either TCP or UDP and the Berkeley

Sockets interface.

Iperf [38] Iperf is a tool for measuring maximum TCP and UDP bandwidth perfor-

mance. Iperf allows the user to tune various parameters and UDP character-

istics and it reports bandwidth, delay jitter, datagram loss.

UniLoG [39] UniLoG is a flexible tool to generate realistic and representative server and

network loads, in terms of access requests to Web servers and creation of

typical Web tra�c.

Mace Mace is an environment for recreating a wide range of malicious packet tra�c

in a laboratory testbed.

LiTGen [40] LiTGen is on open-loop packet-level tra�c generator, which statistically mod-

els IP tra�c (resulting from Web requests) on a per user and application basis.

2.3 Wireshark

Wireshark [41] is a network tra�c analyzer, or "sni�er", for Unix and Unix-like

operating systems. A network analyzer captures and dislays the data in network

packets. It uses GTK+, a graphical user interface library, and libpcap, a packet

14

capture and filtering library.

Sources for wireshark are obtained from

g i t c l one https : // code . wireshark . org / review / wireshark .

Fig 2.3 illustrates the architecture of wireshark, in which we modify the

display filter component for the implementation of our translator tool.

Figure 2.3: Figure illustrating architecture of Wireshark.

Wireshark can be used to troubleshoot network problems, debug network

protocol and search and filter packets based on any specified criteria. Although

15

Wireshark is an analysis tool, it does not help identify or warn any intrusion in the

network. Also it cannot alter the flow of packets within the network but can only

view the tra�c activity in any network. Wireshark uses colors to identify the types

of tra�c with in the network. By default, green is TCP tra�c, dark blue is DNS

tra�c, light blue is UDP tra�c, and black identifies TCP packets with problems.

Wireshark uses two di�erent types of filters. The Capture filter is used to

select the data to be recorded in the logs. The Display filter is used to search for

information from the captured logs.

Since it is an open source software, we modify the program to enable one

such functionality above, specifically, alter the flow of packets using Northbound API

support to set flow rules onto a network switch using OpenFlow.

Required Libraries and Packages to build Wireshark are:

GTK+ and GLib

The libpcap packet capture library

Perl

Python

Sed

Flex

Bison

2.4 A Tra�c Analysis Tool - sFlow

sFlow operation can be roughly divided between two entities, namely agent

and collector. The sFlow agents export sampled data to a centralized collector using

sFlow datagrams. Every observed packet by the sFlow agent undergoes two stages:

filtering and sampling. The sampling algorithm implemented by InMon [42, 43] is

described below in Section 2.4.1 later.

The export process of sampled packets in sFlow is shown in Fig 2.4. When

16

a packet arrives on an interface, the Network Device makes a filtering decision to

determine whether the packet should be dropped. Then it proceeds to the sampling

stage. An sFlow agent also uses Counter Sampling to e�ciently, periodically export

counters associated with data sources.

Figure 2.4: Description of sFlow agent and collector process.

2.4.1 The sFlow Sampling Process and Algorithm

Figure 2.5 shows the pseudo-code of the sFlow sampling algorithm. It is a

rather straightforward algorithm in which the decision of sampling a packet is based

on a randomly generated counter such that in average 1-in-N packets are sampled.

On line 7 the counter s is assigned with a random value from the function on line

2. The counter s tells the algorithm how many packets to skip before sampling one.

This is done by progressively decrementing s for every received packet (line 9), until

it becomes zero, which means that the current packet must be sampled and a new

random counter assigned to s (lines 10 and 12). Typically, the random number gen-

erator yields uniformly distributed numbers and is seeded with the system’s current

time (line 6).

17

Figure 2.5: Code illustrating the sFlow Sampling Algorithm.

18

Chapter 3

Preliminary Work

3.1 Label Space Filtering through OpenFlow

Comprehensive interface monitoring in enterprise networks can enable flow-

based network debugging and troubleshooting in an SDN environment using a trans-

lator tool we developed based on wireshark.

Figure 3.1: Working of the translator tool for debugging OpenFlow switches.

Fig 3.1 illustrates how our translator tool uses its display filter to commu-

nicate with an openflow controller such as floodlight to program SDN capable pre-

classifier boxes monitoring a production network. Similarly, capturing of interfaces

can also occur on wireshark for all interfaces on an enterprise network to debug fur-

ther using a pre-classifier. However this a�ects tra�c on a classifier and does not in

any way a�ect production tra�c.

Consider a network flow f defined by

f = P1, P2, P3....Pn, (3.1)

where Pi is a packet.

Let fl be a filter entry for any label segment that the network engineer uses to

19

zoom in to a flow, for translation to occur. This would lead to filtering those packets

in a network interface for that particular label space which is

f ∆ f(i, Pi)| = fl. (3.2)

When fl is applied or true, meaning the network engineer zooms into a flow

using a label space, a flow-mod function f(m) is issued by the controller and is applied

to the pre-classifier SDN box. This way we can zoom into the flow without a�ecting

the production(legacy) network.

Figure 3.2: Timing interaction diagram of the translator tool.

Fig 3.2 shows a software timing interaction diagram between the translator

tool, an openflow controller and the switch used to monitor and zoom into a flow such

as a pre-classifier. Translator tool monitors the network at programmable interfaces

on a pre-classifier to have visibility over a wide area on campus network which is

a perfect example of an enterprise network. Whenever a network engineer likes to

troubleshoot a network after determining anomaly, he/she issues a filter entry which

communicates with an openflow controller programming these openflow switch inter-

faces to zoom into a flow of interest. This provides a change in network flow and the

capability to program switches in real-time as opposed to the time consuming process

20

to debug and troubleshoot a network manually. The controller then issues flow-mod

messages to these switch ports on a pre-classifier based on the parameters given in

the filter entry which corresponds to flow rules in the flow table.

3.2 E�ectiveness of the translator tool

3.2.1 Baseline on a Popular Tool: Wireshark

Wireshark has the most powerful display filters in the industry which can

almost equal the parameters in the utility function to debug a network. Most educa-

tional institutions, students and industrial organizations use wireshark and therefore

the familiarity with using it as our translator tool is an added benefit. We base our

application on top of wireshark for its extensive familiarity of display filters. The

role of wireshark as our translator tool is to serve its purpose of deep inspection of

hundreds of protocols as well as serving our purpose of implementing northbound [44]

applications that talk to openflow protocol and configuring SDN capable pre-classifier

boxes connected to the production network. Another important factor which utility

function depends on is the familiarity of the translator tool.

3.2.2 Can a translator span the entire label space?

The translator tool is only e�ective if it spans the entire networking label-

space to meet all the user’s troubleshooting needs. It must cover LAN and network

troubleshooting which includes MAC, VLAN, ARP, ICMP, DNS, DHCP and so on.

Industry and enterprise network are keen about bandwidth usage which the tool covers

including IP, TCP and Web. This tool also covers filtering of subnets. When realizing

programmable networks using openflow for debugging, the version of openflow must

be considered to account for IPv6 tra�c in a network. Since flow-mod syntax for each

openflow versions are unique, our application tool extends code based on di�erent

openflow versions [45].

21

There is a necessity to set up bidirectional flows when translating filter entry

to openflow rules. For bi-directional flows on an N-switch path, OpenFlow generates

2N flow-entry installation packets, and at least one initial packet in each direction

is diverted first to and then from the controller therefore adding up to 2N + 4 extra

packets.

3.2.3 Usage Considerations

One important factor to establish the e�ectiveness of a translator tool is

to measure the delay to filter entries corresponding to openflow rules in an openflow

switch. Also while zooming into a particular flow for analysis or security identification,

will this translator tool be useful in matching on the flow to zoom into it at realtime or

will it cause a delay? Since an openflow controller performs installation of flow rules

into the openflow switch, we must choose controllers based on particular openflow

switch and their need in an enterprise network. The controller’s capability to listen to

the translator tool and perform flow modification gives the delay for filter translation

to occur, and is a measure of the e�ectiveness of network debugging.

3.2.4 Deployment Platform

Existing controller platforms o�er a northbound API that forces program-

mers to reason manually, in unstructured ways, about low-level dependencies between

di�erent parts of their code. In such situations, the controller programmer needs to

know the details of the underlying switch. Basically we must determine how much

open is the northbound interaction between the controller and an openflow switch.

OpenFlow defines a standard interface to network devices that controllers can use

for uniform configuration but, it has not yet become a perfect standard that ANY

controller can program ANY switch. Northbound API’s can be written by program-

mers using popular programming languages like Java, Python, or Ruby. However for

22

measuring the utility function based on controller independence, we must analyze the

risk [46] of controllers based on their openness of northbound API’s using validation

testing. We have based our tool on interaction with an openflow controller using

REST APIs [47]. However in future to achieve a 100% utility function in terms of

controller independence, there must be a unique language for the openflow controllers

to interact with northbound APIs better than REST APIs.

3.3 Preliminary Data Sources: Tra�c Statistics from University of Hous-

ton

After establishing the considerations and discussion for a network debugging

scheme in the previous sections, we must calculate the need for such a scheme giving

a useful parameter for its e�ectiveness.

There are 6 UH Core switches namely,

Vespesian

Caesar

Gracchus

Flavia

Cornelia

Suebi

SETG is the regional network for University of Houston - Main. Zayo and

OPT-E-MAN are services for these core switches. Plemliminary data for tra�c statis-

tics between the links of the core switches and its topology is illustrated in Fig 3.3

below. Using these statistics we calculated a realistic Utility of Deployment(UDF)

for the University of Houston campus network later discussed in Section 5.

(Refer to Appendix B for Tra�c Statistics)

23

Figure 3.3: UH Campus topology considered for calculation of UDF with tra�c statisticsindicated on the links between core switches and outbound services.

24

Chapter 4

Implementation

4.1 Translator tool implementation in Enterprise Level Deployment

Network debugging is achieved on a separated analysis of the network mon-

itoring only through span tra�c. Fig 4.1 gives a view of how production tra�c is

spanned onto an SDN capable box to perform network debugging and zooming into

flows. The filter entries on Wireshark are translated into OpenFlow flow rules to

enable programming [15] of the network to feed relevant flows into Wireshark inter-

face monitoring. Such flow rules enable the network engineers to zoom into tra�c at

any required level on any switch sitting at a remote location. To measure the extent

at which a network engineer may gain visibility to the flows of interest for a given

specific deployment scenario of a number of flow analysis nodes and their locations

on the network, calculating UDF is shown in the next section.

Figure 4.1: Implementation of Translator tool in a network enterprise illustrating howspan tra�c is used alongwith SDN capability to monitor and zoom into flowsof interest.

25

The SDN capable box for our study involves the Pica Pronto 3290 Switch

with specifications below (More in Appendix A).

48 x 10/100/1000BASE-T RJ45 port base unit, with four 10 GbE SFP+

uplinks for cost-effective 1 GbE server aggregation.

The opensource controller for our study is Floodlight. It can be run on Linux

platforms using the lines below:

$ g i t c l one g i t : // github . com/ f l o o d l i g h t / f l o o d l i g h t . g i t

$ cd f l o o d l i g h t

$ g i t checkout s t a b l e

$ ant ;

$ sudo mkdir / var / l i b / f l o o d l i g h t

$ sudo chmod 777 / var / l i b / f l o o d l i g h t

$ java ≠j a r t a r g e t / f l o o d l i g h t . j a r

The Label Space Filter Translator Tool is implemented as from Chapter 3

which is modified Wireshark with the capability to add an SDN controller to push the

flow-mod messages. The switch to be controlled is already precoded in the software

with a specific dpid number assigned to the switch. For our specific case, we used

the dpid of Pica8’s P3290 switch which is a pure OpenFlow switch. This switch

monitors the span of production tra�c. The tool developed is shown in Fig 4.2 with

the capability to add the SDN controller’s IP Address to communicate using RESTful

APIs.

After giving the correct controller IP of the controller monitoring the debug-

ging network, an example filter entry as shown in Fig 4.3 tells us how to debug source

flows from IP: 172.16.5.0. This filter entry sets a flow-table entry in the SDN switch.

The results can be seen in flow-mod message displayed in the console output ’curl’

below.

26

Figure 4.2: Label Space Filtering Tool, a modified wireshark with capability to set theOpenFlow controller IP and filter entry for translation corresponding to Open-Flow rules on switches.

Figure 4.3: Filter entry for translation to zoom into flows of interest.

The filter entry above corresponds to the following flow-mod to be pushed

to the SDN capable box:

c u r l ≠d ’{ " switch " : " 0 0 : 0 0 : b6 : 5 3 : 1 1 : 8 d : e8 : 4 0 " , "name " : " f low " ,

" cook i e " : " 0 " , " p r i o r i t y " : " 1 " , " ether≠type " : " 2 0 4 8 " , " src≠ip " :

" 1 7 2 . 1 6 . 1 5 . 0 " , " dst≠ip " : " 1 2 9 . 0 . 0 . 1 " , " a c t i on s " : " output=a l l " ,

" a c t i v e " : " t rue "} ’

http : / / 1 2 7 . 0 . 0 . 1 : 8 0 8 0 /wm/ s t a t i c f l o w e n t r y p u s h e r / j son

The switch being controlled using the RESTful API is the Pica Pronto P3290

with a "dpid" 00:00:b6:53:11:8d:e8:40.

Table 4.1 shows the flow-mod filter entries and the corresponding header field

27

mappings that can be entered into the wireshark display filter.

Table 4.1: Header fields and flow mapping of filter entries.

Header Field Flow-mod En-

try

Wireshark Filter Description

Ingress Port "ingress-port" OpenFlow.in_port Switch port on which the

packet is received.

Ether Type "ether-type" openflow.eth_src Can be hexadecimal (with

leading 0x) or decimal

VLAN Id "vlan-id" openflow.dl_vlan 10-bit VLAN ID

IP source "src-ip" openflow.set_nw_src xx.xx.xx.xx

IP destination "dst-ip" openflow.set_nw_ds xx.xx.xx.xx

Source MAC "src-mac" openflow.set_dl_src xx:xx:xx:xx:xx:xx

Destination

MAC

"dst-mac" openflow.set_dl_ds xx:xx:xx:xx:xx:xx

Source Port "src-port" openflow.set_tp_src Can be hexadecimal (with

leading 0x) or decimal

Destination

Port

"dst-port" openflow.set_tp_dst Can be hexadecimal (with

leading 0x) or decimal

IP protocol "nw-proto" openflow.set_nw_tos Protocol name or decimal

Actions all, controller,

local, port

number

openflow.actions Output

4.2 Calculating Utility of Deployment(UDF)

We have established a translator tool in Chapter 3 that translates filter en-

tries into openflow protocol to perform network debugging for our flows of interest

in an enterprise network and also showed its working in the previous section. Now

that we have established that, we would like to calculate a utility based on a given

deployment of span ports in a network and the flows of interest to debug.

In a scenario where production switches are monitored through span to an

28

SDN Capable box, termed as pre-classifier, it is a necessity to base the utility function

on number of interfaces that can be reached on a network to zoom into a flow. For

instance, the network engineer may want to filter a particular IP and route tra�c

based on the destination IP address, while monitoring tra�c by source address. 100%

utility can be possible to zoom into a flow if all switches in an enterprise network have

span to a pre-classifier. This applies to a scenario when either of legacy or openflow

switches in a production network have span running into the pre-classifier.

Figure 4.4: (a)(top) Spanning limited switches does not give 100% visibility to zoom intoa flow. (b)(below) Spanning all switches is optimal in the sense that 100%control to zoom into every flow at every point.

Fig 4.4(a) represents a scenario where only the aggregation switch is mon-

itored on a pre-classifier. Fig 4.4(b) has span running from all switches to the pre-

classifier. Even when only one aggregation switch is spanned, we still do not have

visibility to say from which switch the flow is passing. Therefore in Fig 4.4(b), we

can say that utility function is 100% e�ective considering the case of limitation of

interfaces.

We define the utility of a specific deployment based on the network engineer’s

need for the following functionalities:

29

Figure 4.5: An example of a topology to find the utility of deployment.

1. Zoom into any one flow of interest at a switch span anywhere in the network

2. Trace the path of flows of interest in the network over as many hops that it

traverses

Consider an example enterprise topology in Fig 4.5. Nodes i,j,k,l are hosts.

Boxes A, E and C represent Access, Edge and Core switches respectively.Two source

and destination flow pairs of interest are introduced. Let us assume they are (i, k)

and (j, l). Also, flow of interest (i, j) traverses switches A1 æ E1 æ E3 æ C1 æ C3.

Similarly, flow of interest (j, l) traverses switches A3 æ E2 æ E4 æ C1 æ C3 æ E5.

Now, let us suppose (i, j) contributes to 40% of tra�c for flows in the total network

that traverses the given path and similarly (j, l) contribute 20% of total flows in the

network. This percentage is denoted by tf . So, tf at E3 or C1 would correspond

to 40% because all tra�c from node i to j is going through that switch. If suppose,

some tra�c let us say 8% from node i deviates to access switch A2, it would mean

that tf(A2)=8% and so tf(E3)=32% in that case.

30

For the scenario explained above, we calculate the utility of deployment for

the first instance. Utility µ for a switch S in this case is given by

µ =ÿ

pairs

tf(S).g(S), (4.1)

where g(S) is 0 if the flow does not pass through the switch and 1 if it does.

Utility for switch E1 is µE1 = 40% ◊ 1 = 40%. Utility for switch A3 is

µA3 = 20% ◊ 1 = 20%. Similarly, utility for switch C1 is q(i,k),(j,l) tf(S).g(S) =

40% ◊ 1 + 20% ◊ 1 = 60%.

For the second instance, to calculate the utility based on the number of hops

visible to network debugging for a flow, we define D, a distance hop ratio. D is the

ratio of the number of hops covered by span switches for debug to the total number

of hops that a flow takes.

In the case of flow pair (i, j) when interfaces C1 and C3 are spanned

Dij = D(A1, E1, E3, C1, C3) = 25 .

Therefore we define the utility Ê for the second instance as

ÊS1,S2...Sn =ÿ

pairs

tf(S).Dpair(S1, S2...Sn). (4.2)

Let us suppose that C1 and C3 are the interfaces spanned so that network

debugging to zoom into a flow is applicable at those switches, then the utility Ê is

calculated by

Ê(C1,C3) =ÿ

(i,k),(j,l)tf(S).Dpair(C1, C3)

= 40% ◊ 25 + 20% ◊ 2

6

= 22.67%.

31

A utility set can be derived in general for flows of interest and the hops that

the flow takes. Based on this utility set, we can determine the maximum occurrences

of interfaces/switches in the whole set to say that spanning at these interfaces is the

most useful for debugging. More so, we do not need a pre-defined topology or network

diagram to establish where to place the spans. The utility set for our flows of interest

in the above case is given by

{ (i, k); D(A1, E1, E3, C1, C3)

(j, l); D(A3, E2, E4, C1, C3, E5) }.

Based on this set, since the most occurring nodes are C1 and C3, the most

probable switches to span are C1 and C3 without knowing a predefined topology.

32

Chapter 5

Results and Tests

5.1 Proof of Concept to show working of the translator tool

This section shows the proof of concept for label space filtering through

OpenFlow using the translator tool.

GENI [3] (Global Environment for Network Innovations) provides a virtual

laboratory for networking by reserving compute nodes connected by Layer 2 networks

in topologies all throughout United States. More importantly it allows us to program

the switches in the core of your network and experiment with novel network layer

protocols or with novel IP-routing algorithms.

Figure 5.1: Emulation of sample aggregation topology for demonstrating zooming intoflows of interest for network debugging.

Fig 5.1 shows the emulation of an aggregation topology we try to achieve

on an enterprise network created using compute resources from GENI. We program

the switches to work as OpenVirtual switches(OVS), all of which are connected to an

OpenFlow controller Floodlight [48], which in turn communicates with our translator

33

Figure 5.2: Dotted line shows sum of tra�c from each of the VMs 172.16.5.20, 172.16.5.1and 172.16.5.2. At T=30s a filter entry translated to flow rule set on theaggregation switch (dp4) resulting in blocking tra�c from VM1.

tool. These switches are reserved either as a virtual machine or as a physical raw

machine depending on our requirement. We have allocated di�erent locations for our

switches to further increase the complexity of our experiment. Each virtual machine

represents a tra�c generator, tuned to send tra�c from/to specified IP ranges and

TCP ports. We used iPerf to create UDP data streams for measurement of throughput

and for tra�c aggregation to be viewed on the monitoring site.

In Fig 5.2, we observe that a filter entry: "src-ip" : "172.16.5.20",

"dst-ip" : "172.16.5.1", "actions" : "output=NULL" has dropped packets

from the source IP mentioned in the display filter which is tra�c from site VM1. The

output represented by dotted lines in the figure is the sum of tra�c flows from sites

VM1, VM2 and VM3 respectively. Since the translator tool issues a drop command,

flows from VM1 are blocked. All of this monitoring and zooming into a flow happens

in a classifier switch (not shown in this figure) which is spanning all interfaces of

switches which is Pica P3290. None of the production tra�c is a�ected by this

method.

34

5.2 Results of UDF for SPAN Deployment

Figure 5.3: Sample campus flow pairs of interest and a given deployment.

Fig 5.3 shows a sample campus deployment consisting of 12 nodes with a

span intersection of 2 nodes being used to calculate UDF. The results of Utility of

Deployment for the flow pairs of interest (both pairs i, k and j, l) with tra�c ranging

from 0 to 100% is shown in Fig 5.4 below. The maximum achievable UDF in this

case is 73%.

Fig 5.5 is a representation of the UH Core Deployed Switches with a tra�c

load intensity. For this University of Houston case study, we attempt at a realistic

UDF for future deployment e�orts of a network debugging overlay on campus. On

Fig 5.5 are core UH switches out of which the flow activity measurements from the

preliminary work are recorded in Table 5.1. This table is used to calculate the UDF

of individual flow set from Access and Edge switches connected to these core switches

for every possible case. All these calculations being made assumes that Caesar is the

core switch being spanned to implement the network debugging scenario.

35

Figure 5.4: Maximum achievable UDF for the case considered above spanning only twointersection switches as shown in Fig 5.3. Achieved at 73%.

Figure 5.5: University of Houston CORE / BGP Router Weathermap (Source:http://monitor.hpcc.uh.edu).

36

Table 5.1: Tra�c flow statistcis of yearly average inbound flow for UH Core and BGPRouters.

UH Core / BGP Routers Inbound Tra�c (in

Gbps) - Yearly Av-

erage

Percentage of Flow

Tra�c (%)

Vespasian ¡ Caesar (UH CORE) 0.966 19.3

Caesar ¡ Cornelia (UH CORE) 0.59385 11.86

Gracchus ¡ Caesar (UH CORE) 0.02503 0.5

Gracchus ¡ Vespasian (UH CORE) 0.14403 2.87

Flavia ¡ Graccnus (UH CORE) 0.14294 2.85

Flavia ¡ Cornelia (UH CORE) 0.17863 3.57

Flavia ¡ Vespesian (UH CORE) 0.31055 6.2

Cornelia ¡ Suebi (UH CORE) 0.00003056 0.0006

Caesar ¡ SETG (Outbound) 1.36 27.1726

SETG ¡ UHV/SDC (Outbound) 0.02708 0.54

Cornelia ¡ OPT-E-MAN (Outbound) 0.02942 0.58

Cornelia ¡ Zayo (Outbound) 0.35884 7.16

The first eight rows of the table shows the tra�c activity between the core

aggregation switches on campus. Outbound links represent resources used by the main

campus like Internet (from regional network with SETG), or from services like ATT

(OPT-E-MAN is a switched Ethernet service administered and managed by ATT, that

connects LANs within the same metropolitan area with flexible bandwidth options

from 5 Mbps to 1 Gbps). Since, the highest tra�c activity is between Caesar to SETG,

results later explain that when Caesar is the span tra�c to deploy network debugging,

highest utilities for individual flowsets are achieved to SETG and UHV/SDC. Also,

considering individual flowsets, all utilities have values for flows that pass though

Caesar. It is important to note that for the scope of this thesis, we have assumed

that Caesar is the span tra�c where network debugging is implemented.

37

For each of the six core switches on campus, Fig 5.6 - Fig 5.11 shows the

utility for individual flow sets from one core to other core switches and services.

Figure 5.6: Flowset from Vespesian to UHV/SDC has the highest utility of 28.4 and isjustified as flows have to pass through Caesar which is spanned. Value isslightly less than the Caesar diagram because Vespesian being a core switchis not spanned in our case.

Figure 5.7: Flow activity is the highest for links on caesar to SETG and UHV/SDC. Sincecaesar is the core switch for consideration, and also since it is spanned, thevalue for UDF is 33.53, the hightest among all graphs.

38

Figure 5.8: Caesar which is spanned, does not come in between flow activity from coreCornelia to either Zayo, Flavia or OPT-E-MAN. Therefore utility for thesecases are Zero and are justified.

Figure 5.9: Flavia has connectivity to other switches and services directly without pass-ing though Caesar. Therefore utility for only flowsets to Caesar, SETG andUHV/SDC are indicated whereas others remain zero.

39

Figure 5.10: Utilities for Gracchus to SETG and UHV/SDC are the highest among otherindividual flowsets in this figure, being 16.04 and 17.06 respectively.

Figure 5.11: Suebi has the least utility for SETG and UHV/SDC because tra�c has totravel the most switches which reduces the e�ectiveness of network debuggingsince all switches are not spanned.

40

Chapter 6

Conclusion and Future Work

This thesis implemented a network analysis tool and investigated utility metrics

of the tool while helping in debugging of a production network on a separate analysis wing

using SDN OpenFlow principles. We have created a tool that translates filter entries to

openflow rules on an SDN capable box in the analysis wing which is monitoring a production

network. Thus we are able to zoom into flows of interest based on the label space criteria

given by a network engineer. Results for proof of concept have been established using both

a laboratory testbed like GENI as well as pure openflow switch like Pica 8.

Furthermore, we also present a way to calculate the utility given a deployment of

span ports and the flows of interest to help in debugging. We have also shown the results

of UDF for a given deployment involving two flow pairs and given span of two switches

for a twelve node network. It is achieved at a maximum of 73.33% for this specific case.

Finally, we also found a realistic UDF for the University of Houston Campus Network to

deploy network debugging capability. The results were found useful because they showed

that utility for flows going to UHV/SDC have the highest number. This is justified because

maximum flow activity is between the Caesar ¡ SETG link and also any tra�c going to

UHV/SDC has to pass through caesar from any of the core switches. Since, caesar is the

span for our analysis, the results are justified.

This thesis presents a way of calculating utility of deployment focusing on place-

ment of span ports to implement network debugging. This is to be deployed at the Univer-

sity of Houston campus network to help flow identification and general network monitoring.

In this thesis, we present a framework for accurate estimation of regions for deployment

with the highest return on investment. Once such locations are identified according to the

interest of flows by the university IT department, the wireshark interface will provide the

interface to the monitoring system on the campus network. OpenFlow match fields are

41

used in packet filter entries within the existing Wireshark interface. So, in essence, once

deployed, the wireshark interface will provide filter entries such as enterprise address ranges,

VLAN ids, and other protocol parameters. Once such entries are provided for debugging by

the network engineers, the flows are displayed on wireshark screen for a better visualization

of the ongoing activity on the network. The filter entries program the OpenFlow capable

boxes so the wireshark screen can display those specific flows only rather than the possible

40 Gbps line.

Future Work: This thesis assumes that the calculations for the utility of deploy-

ment are based on the distance between each node in a topology as 1 unit. However, realistic

network wide distances between the switches for transmission and latency can be taken into

account. We suggest the use of traceroute like tools to calculate measuring transit delays of

packets across an Internet Protocol (IP) network. This way the UDF can be more e�ective

inclusive of delays and mean time in each hop.

Further study can be done to see how the controller can adapt to enterprise class

resiliency and scalability. Also, the controller can be studied to provide northbound support

to network fabric instead of a single switch, since the incoming tra�c from span is over a high

bandwidth. Also the controller APIs can be leveraged to dynamically and automatically

program the network.

The OpenFlow based SDN architecture for monitoring and controlling an analysis

network allows to have centralized, granular control and in-depth network visualization.

But, future studies can implement automatic requisition of dynamic changes to bandwidth

allocation and also study quality of service parameters at packet and/or optical layers.

A more important consideration will be the role of high performance hardware that

can fully utilize the advantage of SDN through Network Functions Virtualization (NFV) so

that the network can be optimized based on the performance requirements for individual

services.

In future, we must also consider how to establish a clean abstraction of the services

from hardware infrastructure using SDN principles, so that it is easier to evolve the network

deployment.

42

References

[1] Chia-Chi Lin, Matthew Caesar, and Kobus Van Der Merwe. Toward Interac-

tive Debugging for ISP Networks. In Lakshminarayanan Subramanian, Will E.

Leland, and Ratul Mahajan, editors, HotNets. ACM SIGCOMM, 2009.

[2] Shannon McFarland, Muninder Sambi, Nikhil Sharma, and Sanjay Hooda. IPv6

for Enterprise Networks. Pearson Education, 2011.

[3] GENI. Global Environment for Network Innovations, 2006. Available at http:

//www.geni.net (visited on 2014-12-14).

[4] Seyed Kaveh Fayazbakhsh, Luis Chiang, Vyas Sekar, Minlan Yu, and Je�rey C

Mogul. Extending SDN to Handle Dynamic Middlebox Actions via FlowTags.

Presented as part of the Open Networking Summit, 2014.

[5] Brian Carpenter and Scott Brim. Middleboxes: Taxonomy and issues. Technical

report, RFC 3234, February, 2002.

[6] Ying Zhang, Neda Beheshti, Ludovic Beliveau, Geo�rey Lefebvre, Ravi Manghir-

malani, Ramesh Mishra, Ritun Patney, Meral Shirazipour, Ramesh Subrahma-

niam, Catherine Truchan, et al. StEERING: A Software-Defined Networking for

Inline Service Chaining. In ICNP, pages 1–10, 2013.

[7] Justine Sherry, Shaddi Hasan, Colin Scott, Arvind Krishnamurthy, Sylvia Rat-

nasamy, and Vyas Sekar. Making Middleboxes Someone Else’s Problem: Network

Processing as a Cloud Service. ACM SIGCOMM Computer Communication Re-

view, 42(4):13–24, 2012.

[8] Vyas Sekar, Sylvia Ratnasamy, Michael K Reiter, Norbert Egi, and Guangyu

Shi. The Middlebox Manifesto: Enabling Innovation in Middlebox Deployment.

43

In Proceedings of the 10th ACM Workshop on Hot Topics in Networks, page 21.

ACM, 2011.

[9] Big Switch Networks. Big Tap Monitoring Fabric, 2014. Available at http://

www.bigswitch.com/products/big-tap-monitoring-fabric (visited on 2014-

12-14).

[10] Baek-Young Choi, Sejun Song, George Ko�er, and Deep Medhi. Outage Analysis

of a University campus Network. In Computer Communications and Networks,

2007. ICCCN 2007. Proceedings of 16th International Conference on, pages 675–

680. IEEE, 2007.

[11] Open Networking Foundation. ONF White Paper on ONF SampleTap - An

Educational Journey. ONF White Paper, 2014.

[12] OpenDaylight. Linux Foundation Collaborative Project.

[13] Shaochun Wang. Temporal Filter A Temporal Extension to Wireshark Display

Filter. In SEKE, pages 421–424, 2010.

[14] Peyman Kazemian, George Varghese, and Nick McKeown. Header Space Anal-

ysis: Static Checking for Networks. In NSDI, pages 113–126, 2012.

[15] Peyman Kazemian, Michael Chan, Hongyi Zeng, George Varghese, Nick McKe-

own, and Scott Whyte. Real Time Network Policy Checking Using Header Space

Analysis. In NSDI, pages 99–111, 2013.

[16] Martin Casado, Michael J Freedman, Justin Pettit, Jianying Luo, Nick McKe-

own, and Scott Shenker. Ethane: Taking Control of the Enterprise. In ACM

SIGCOMM Computer Communication Review, volume 37, pages 1–12. ACM,

2007.

44

[17] Hyojoon Kim and Nick Feamster. Improving Network Management with Soft-

ware Defined Networking. Communications Magazine, IEEE, 51(2):114–119,

2013.

[18] Ye Yu, Qian Chen, and Xin Li. Distributed Collaborative Monitoring in Software

Defined Networks. CoRR, abs/1403.8008, 2014.

[19] Martin éádnik, Petr äpringl, and Pavel �eleda. Flexible FlowMon. Technical

report, Technical report 36/2007, Praha: CESNET, 2007.

[20] Anilkumar Vishnoi, Rishabh Poddar, Vijay Mann, and Suparna Bhattacharya.

E�ective Switch Memory Management in OpenFlow Networks. In Proceedings

of the 8th ACM International Conference on Distributed Event-Based Systems,

pages 177–188. ACM, 2014.

[21] Ankur Kumar Nayak, Alex Reimers, Nick Feamster, and Russ Clark. Resonance:

Dynamic Access Control for Enterprise Networks. In Proceedings of the 1st ACM

workshop on Research on enterprise networking, pages 11–18. ACM, 2009.

[22] Shihabur Rahman Chowdhury, Md Bari, Reaz Ahmed, Raouf Boutaba, et al.

Payless: A Low Cost Network Monitoring Framework for Software Defined Net-

works. In Network Operations and Management Symposium (NOMS), 2014

IEEE, pages 1–9. IEEE, 2014.

[23] Ricardo Oliveira Schmidt. Measurement-based Link Dimensioning for the Future

Internet. University of Twente, 2014.

[24] Alok Tongaonkar, Ram Keralapura, and Antonio Nucci. Challenges in Network

Application Identification. In Proceedings of the 5th USENIX Conference on

Large-Scale Exploits and Emergent Threats, ser. LEET, volume 12, pages 1–1,

2012.

45

[25] Alberto Dainotti, Antonio Pescape, and Kimberly C Cla�y. Issues and Future

Directions in Tra�c Classification. Network, IEEE, 26(1):35–40, 2012.

[26] Cisco. NetFlow, 2008.

[27] Andrew C Myers. JFlow: Practical Mostly-Static Information Flow Control. In

Proceedings of the 26th ACM SIGPLAN-SIGACT symposium on Principles of

programming languages, pages 228–241. ACM, 1999.

[28] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peter-

son, Jennifer Rexford, Scott Shenker, and Jonathan Turner. OpenFlow: Enabling

Innovation in Campus Networks. ACM SIGCOMM Computer Communication

Review, 38(2):69–74, 2008.

[29] OpenFlow Switch Specification. Version 1.4. 0, October 14, 2013, .

[30] Manuel Palacin Mateo. OpenFlow Switching Performance. Politecnico Di Torino

in Telecommunication Engineering, 2009.

[31] Open Networking Foundation. ONF White Paper on OpenFlow Table Type

Patterns, Version No. 1.0. ONF White Paper, 2014.

[32] Ostinato Packet/Tra�c Generator and Analyzer. Available at http://code.

google.com/p/ostinato (visited on 2014-12-14).

[33] Michele C Weigle, Prashanth Adurthi, Félix Hernández-Campos, Kevin Je�ay,

and F Donelson Smith. Tmix: A Tool for Generating Realistic TCP Application

Workloads in NS-2. ACM SIGCOMM Computer Communication Review, 36(3):

65–76, 2006.

[34] Rude and Crude. Available at http://rude.sourceforge.net (visited on 2014-

12-14).

46

[35] Network Tra�c Generator. Available at http://www.softpedia.com/get/

Network-Tools/Network-Testing/Network-Traffic-Generator.shtml (vis-

ited on 2014-12-14).

[36] Netspec, . Available at http://www.ittc.ku.edu/netspec (visited on 2014-12-

14).

[37] Netperf, . Available at http://www.netperf.org/netperf (visited on 2014-12-

14).

[38] Iperf. Available at http://sourceforge.net/projects/iperf (visited on 2014-

12-14).

[39] Andrey W Kolesnikov, Bernd E Wolfinger, Norbert Luttenberger, and Hagen

Peters. Web Workload Generation According to the UniLoG Approach. In

KiVS, pages 49–60, 2011.

[40] Chloé Rolland, Julien Ridoux, and Bruno Baynat. Catching IP Tra�c Burstiness

with a Lightweight Generator. In NETWORKING 2007. Ad Hoc and Sensor Net-

works, Wireless Networks, Next Generation Internet, pages 924–934. Springer,

2007.

[41] Gerald Combs. Wireshark, 1998. Available at https://www.wireshark.org

(visited on 2014-12-14).

[42] Peter Phaal, Sonia Panchen, and Neil McKee. InMon Corporation’s sFlow: A

Method for Monitoring Tra�c in Switched and Routed Networks. Technical

report, RFC 3176, 2001.

[43] InMon Corp. sFlow Agent Software Description, 2003. Available at http://

www.inmon.com/technology/InMon_Agentv5.pdf (visited on 2014-12-14).

47

[44] Myung-Ki Shin, Ki-Hyuk Nam, and Hyoung-Jun Kim. Software-Defined Net-

working (SDN): A Reference Architecture and Open APIs. In ICT Convergence

(ICTC), 2012 International Conference on, pages 360–361. IEEE, 2012.

[45] OpenFlow Switch Specification. Version 1.2 (Wire Protocol 0x03), .

[46] Kevin Benton, L Jean Camp, and Chris Small. Openflow Vulnerability Assess-

ment. In Proceedings of the second ACM SIGCOMM workshop on Hot topics in

software defined networking, pages 151–152. ACM, 2013.

[47] Mark Masse. REST API Design Rulebook. " O’Reilly Media, Inc.", 2011.

[48] Big Switch Networks. Floodlight OpenFlow Controller, 2012. Available at http:

//www.projectfloodlight.org/floodlight (visited on 2014-12-14).

48

Appendix A. Pica P3290 48 x 1 GbE

Specification Guide

Pica8 white box switches run PicOST M , an open network operating sys-

tem (OS) that runs standards-based Layer 2/Layer 3 protocols with industry-leading

OpenFlow 1.4 and Open vSwitch (OVS) v2.0 integration. OVS runs as a process

within PicOS, and provides the OpenFlow interface for external programmability.

PicOS utilizes proven high-performance hardware with a maximum switching fabric

capacity of 176 Gbps for 1 GbE and 1.28 Tbps for 10 GbE platforms.

49

Figure A.1: Product Reference Guide for Pica P-3290 Switch

50

Appendix B. Tra�c Statistics for links between CoreSwitches and Services at the University of Houston

This section illustrates tra�c statistics between links on Core switches de-

ployed at University of Houston. The sources are obtained from http://monitor.hpcc.uh.edu.

University of Houston IT manages the infrastructure as well as the connections be-

tween the UH System universities. The software used to develope these graphs is

Cacti, which is a complete frontend to RRDTool, it stores all of the necessary infor-

mation to create graphs and populate them with data in a MySQL database. The

frontend is completely PHP driven. Along with being able to maintain Graphs, Data

Sources, and Round Robin Archives in a database, cacti handles the data gathering.

There is also SNMP support for those used to creating tra�c graphs with MRTG.

51

UH Core Connection Statistics for Current Average and Maximum

Tra�c

Vespasian ¡ Caesar

Caesar ¡ Cornelia

52

UH Core Connection Statistics for Current Average and Maximum

Tra�c

Gracchus ¡ Caesar

Gracchus ¡ Vespasian

53

UH Core Connection Statistics for Current Average and Maximum

Tra�c

Flavia ¡ Graccnus

Flavia ¡ Cornelia

54

UH Core Connection Statistics for Current Average and Maximum

Tra�c

Flavia ¡ Vespesian

Cornelia ¡ Suebi

55

Outbound (Services and Internet) Tra�c Statistics from Core Switches

for Current Average and Maximum Tra�c

Caesar ¡ SETG

SETG ¡ UHV/SDC

56

Outbound (Services and Internet) Tra�c Statistics from Core Switches

for Current Average and Maximum Tra�c

Cornelia ¡ OPT-E-MAN

Cornelia ¡ Zayo

57

Appendix C. OpenFlow Specification

OpenFlow Table Flow Entries

An OpenFlow Switch consists of a flow table, which performs packet lookup

and forwarding, and a secure channel to an external controller.

Each flow table entry contains:

• header fields: to match against packets

• counters: to update for matching packet

• actions: to apply to matching packets

58

All packets processed by the switch are compared against the flow table. If

a matching entry is found, any actions for that entry are performed on the packet.

Figure C.1: OpenFlow 1.0 Flow Entry List

59

OpenFlow 12-tuple

The fields in the OpenFlow 12-tuple are listed below in Fig C.2 along with

details on the properties of each field.

Figure C.2: Match Field Details

60

OpenFlow Actions

Each flow entry is associated with zero or more actions that dictate how the

switch handles matching packets. Fig C.3 below illustrates the various field-modify

actions.

Figure C.3: Field-modify Actions

61