performance analysis on dynamic vlan and …861021/fulltext01.pdf · master thesis electrical...

Master Thesis

Electrical Engineering

October 2015

Performance Analysis on Dynamic

VLAN and OpenFlow

Reddy Kamal Teja Gurramkonda

Department of Communication Systems

Blekinge Institute of Technology

SE-371 79 Karlskrona

Sweden

This thesis is submitted to the Faculty of Computing at Blekinge Institute of Technology

in partial ful�lment of the requirements for the degree of Master of Science in Electrical

Engineering. The thesis is equivalent to 20 weeks of full time studies.

Contact Information:Author(s):Reddy Kamal Teja Gurramkonda.E-mail:[email protected],[email protected]

University advisor(s):Dr. Patrik ArlosSchool of Computing

University examiner(s):Dr. Kurt TutschkuDepartment of Communication Systems

School of ComputingBlekinge Institute of Technology Internet : www.bth.se/comSE-371 79 Karlskrona Phone : +46 455 38 50 00Sweden Fax : +46 455 38 50 57

Abstract

In the current innovative network, to cope with the increased require-ments of customers, there is a rapid increase in the development of di�erentprotocols and applications. With such increase in networking technology,the security constraints are becoming more and more severe, reducing theaccessibility to the actual network for implementing new protocols. Thisscenario forced for an urgent need of a technology, which can help the re-searchers to implement their developed protocols in the network withoutin�uencing the production tra�c. This need resulted in a concept callednetwork isolation. This is achieved by VLAN or SDN technologies.

In this study, we investigate the performance of VLAN and an APIof SDN in the context of establishing dynamic link, in switching setup. Forsuch a link creation, dynamic VLAN (dVLAN) is used in the former caseand OpenFLow protocol is used in the later scenario. The main focus in thisstudy is to compare the dynamic behavior of both the protocols in layer-2context by measuring network level performance metrics of each protocol.Some of the features like, vendor independency and software independencyis taken into account while measuring the performance metrics.

In order to evaluate the performance, an experimental testbed isimplemented. The network level performance metric called protocol setuptime is measured. It is the time taken by each protocol to setup an activelink between two end-hosts. A two-tire network architecture is implementedwith the mentioned features.

From the analytical and statistical results obtained, OpenFlow re-sulted in performing relatively better when compared to dynamic VLANs.By carefully examining the protocol setup time of OpenFlow against dVLAN,OpenFlow took less time when compared to dVLAN resulting in faster exe-cution in enabling connectivity. On the other hand, the analytical study onthe two protocols re�ects the simplicity exhibited by dVLAN over Open-Flow.

Keywords: Dynamic VLAN, Network Isolation, OpenFlow, SDN.

i

Acknowledgments

I would like to thank the supremacy, God, for blessing me with the knowl-edge of understanding and exceptional hope for which I am greatful to. Nextly,I would thank my parents for encouraging me in performing the tasks of duty. Iespecially have deep scence of gratitude towards my friends who helped me andgave hope of light.

I particularly owe my debt of gratitude to Dr.Patrik Arlos � senior lecture,DIKO, for his vision and foresight which inspired me in coping with challengingtasks. I have surely learnt many lots of things by working under him and especiallyincreased my self thinking capabilities and problem detection thinking.

� Reddy Kamal Teja Gurramkonda

ii

Contents

Abstract i

Acknowledgments ii

Table of Contents iii

List of Figures v

List of Tables vi

Acronyms vii

1 Introduction 21.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Scope of Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Aims and objectives . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 51.6 Research Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Background 82.1 VLAN � Virtual Local Area Networks . . . . . . . . . . . . . . . . 8

2.1.1 Port-Based VLAN . . . . . . . . . . . . . . . . . . . . . . 92.1.2 MAC Address Based VLAN . . . . . . . . . . . . . . . . . 102.1.3 Protocol-Based VLAN . . . . . . . . . . . . . . . . . . . . 102.1.4 GVRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 The New Network Architecture . . . . . . . . . . . . . . . . . . . 132.2.1 Need for Software-De�ned Networking . . . . . . . . . . . 132.2.2 Restrictions in Current Network . . . . . . . . . . . . . . . 14

2.3 OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.1 OpenFlow Switch components . . . . . . . . . . . . . . . . 152.3.2 Operational steps of OpenFlow . . . . . . . . . . . . . . . 162.3.3 Classes of OpenFlow Communication . . . . . . . . . . . . 172.3.4 NOX � An OpenFlow Controller . . . . . . . . . . . . . . 19

2.4 Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

iii

3 Methodology 223.1 Experiment Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.1 Dynamic Virtual LAN (dVLAN) Implementation . . . . . 223.1.2 OpenFlow Implementation . . . . . . . . . . . . . . . . . . 26

3.2 Performance Metric Measurement . . . . . . . . . . . . . . . . . . 293.2.1 Dynamic VLAN Setup Time Measurement . . . . . . . . . 303.2.2 OpenFlow Setup Time Measurement . . . . . . . . . . . . 32

4 Experiment Results and Analysis 364.1 Dynamic VLAN Assessment . . . . . . . . . . . . . . . . . . . . . 364.2 OpenFlow Assessment . . . . . . . . . . . . . . . . . . . . . . . . 374.3 Theoretical Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3.1 Dynamic VLAN . . . . . . . . . . . . . . . . . . . . . . . . 384.3.2 OpenFlow Protocol . . . . . . . . . . . . . . . . . . . . . . 39

5 Conclusions 41

References 44

Appendix 47

iv

List of Figures

2.1 Ethernet frame with VLAN tag . . . . . . . . . . . . . . . . . . . 82.2 VLAN Architcture . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 GARP Architecture [11] . . . . . . . . . . . . . . . . . . . . . . . 122.4 GARP Architecture [11] . . . . . . . . . . . . . . . . . . . . . . . 132.5 Flow Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.6 10-Tuple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.7 Procedural steps carried out by OpenFlow [7][12] . . . . . . . . . 172.8 Pipeline Processing [7][10] . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Dynamic VLAN Experiment setup . . . . . . . . . . . . . . . . . 243.2 GVRP exchange between switches . . . . . . . . . . . . . . . . . . 253.3 GVRP exchange in LAN . . . . . . . . . . . . . . . . . . . . . . . 253.4 OpenFlow Architecture . . . . . . . . . . . . . . . . . . . . . . . . 273.5 Mode of OpenFlow - Virtualization mode . . . . . . . . . . . . . . 283.6 Mode of OpenFlow - Aggregation mode . . . . . . . . . . . . . . . 283.7 OF Switch - controller communication . . . . . . . . . . . . . . . 293.8 Capture Description . . . . . . . . . . . . . . . . . . . . . . . . . 303.9 Sequence diagram of dVLAN . . . . . . . . . . . . . . . . . . . . 313.10 Time line diagram of dVLAN . . . . . . . . . . . . . . . . . . . . 323.11 Sequence diagram of OpenFlow . . . . . . . . . . . . . . . . . . . 333.12 Time line diagram of OpenFlow . . . . . . . . . . . . . . . . . . . 34

4.1 dVLAN Setup Time (iterations plot) . . . . . . . . . . . . . . . . 374.2 OpenFlow Setup Time (iterations plot) . . . . . . . . . . . . . . . 38

1 Trace of dVLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 502 Trace of OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . 51

v

List of Tables

3.1 Hardware Speci�cations - Switch . . . . . . . . . . . . . . . . . . 233.2 Hardware Speci�cations - Host . . . . . . . . . . . . . . . . . . . . 23

4.1 Protocol Setup Time for dVLAN . . . . . . . . . . . . . . . . . . 364.2 Protocol Setup Time for OpenFlow . . . . . . . . . . . . . . . . . 37

vi

vii

Acronyms

CLI Command Line Inerface

DOS Denial of Service

dVLAN Dynamic Virtual LAN

GARP Generic Attribute Resolution Protocol

GVRP GARP VLAN Registration Protocol

ICMP Internet Control Message protocol

ID Identification

IP Internet Protocol

IT Information Technology

LTS Long Term Support

MAC Medium Access Control

NIC Network Interface Card

ONF Open Network Foundation

QoS Quality of Service

SDN Software Defined Networking

STP Spanning Tree Protocol

TCAM Ternary Content-Addressable Memory

TLS Transport Level Security

VID VLAN Identifier/Identity

VLAN Virtual Local Area Network

VMPS VLAN Member Policy Server

Chapter 1:

INTRODUCTION

Chapter 1

Introduction

In today's world, innovation of enterprise network is increasing day byday. Enterprise networks are often large networks that incorporate di�erent vari-eties of protocols and applications. These networks are installed with enormousequipment and protocols, increasing the security constrains creating a challeng-ing environment for the researchers in network innovation. The current possiblemethods are fragile making the enterprise expensive and error-prone. The cur-rent methods are indeed manual con�guration setups done by trained operatorsto achieve adequate security [1][2][3]. A research group called Yankee reportedthat, on an average the total network downtime was around 62% which was onlydue to human error and 80% of IT budget was spent only on maintenance andoperations [4]. This situation made the researchers impossible to have real envi-ronment experiments to test new protocols.

This situation forced for the need of network isolation, i.e., to have theavailability to use the same network but without in�uencing the production traf-�c. Network isolation can be provided by VLAN � Virtual local Area Network.VLANs are layer-2 entities that bring di�erent hosts at di�erent localities intoa single network which are software administrated. These VLANs are indepen-dent of physical connectivity i.e., hosts at di�erent physical locations are broughttogether, resulting in more �exible network administration, management and re-con�guration [5][6][7]. The next stage of VLANs is Dynamic VLANs [8]. Thisconcept is derived, as the manual con�guration of these VLANs is very com-plex in the current innovative enterprise network architecture. The con�guringof desired VLANs is performed on one network device (switch � mostly the ad-ministrator switch) and the rest of the network is made to learn the VLANs fromthat switch resulting in dynamic creation of those advertised VLANs from theadministrator switch. Such dynamic VLANs, cope with some of the limitationsof the traditional network by making the administration �exible and easy.

Upon the passing of many development years, new architectures emerged,giving a programmable ability to manage the network. This is achieved by de-veloping an operating system to the network. Many attempts have been made tomake the network more manageable and secure. To meet up with this require-ment, an architecture has been developed called the SDN � Software De�ned

2

Chapter 1. Introduction 3

Networking.

SDN � Software De�ned Networking is the new technology introduced [9].SDN is a network architecture enabling isolated �ows for researchers. Decouplingnetwork control and forwarding plane achieve this. The network control planeand forwarding plane communicate via a secured channel. This secured controldata path interface is managed by OpenFlow protocol. OpenFlow is the �rstcommunication interface protocol constructed between the control and data pathof SDN architecture [9][10].

OpenFlow is a protocol that provides the feasibility for the administratorto program the �ow tables of di�erent switches. OpenFlow virtualizes networkinto �ows delegating network segments to researchers as if they are new networks.This implementation resulted in advantageous scenarios like network virtualiza-tion, low cost, etc. In general an OpenFlow switch consists of three components:�ow table, secure channel, OpenFlow protocol [10].

Thus, such �exible software administered method � dVLAN (dynamicVLAN) have some similar features with the new architecture protocol � OpenFlowmaking an interesting research topic.

The performance of both the protocols is measured and analyzed withthe help of an experimental setup. Protocol latency is measured in the contextof protocol establishment at layer-2.

1.1 Motivation

The main reason for performing this study is to evaluate the performanceof the two dynamic switching protocols dVLAN (GVRP) and OpenFlow. Themotivative reason behind choosing this study is availability of similar featuredprotocols to implement network isolation. The break point scenarios are alsoexplained, where one is reasonably better over the other protocol in the contextof switching setup.

In case of dynamic VLANs, there are di�erent types of protocols (like,GVRP, VMPS) to implement it. In this study, GVRP is used because of itsapplication and vendor independence. GVRP is concerned with dynamic VLANcreation in the network, whereas VMPS is con�ned within a switch. GVRP is avendor independent protocol, which sends broadcast messages into the network,con�guring dynamic VLANs in all the devices (GVRP aware) of the network.VMPS is vendor dependent (cisco) and creates VLANs dynamically within aswitch, depending on the position (port on the switch) the host is connected to[8][19].

The behavior exhibited by the two protocols at link layer for LAN connec-tivity is analyzed. The similarities in the behavior of both the protocols, enabledto implement comparable scenarios.


1.2 Scope of Thesis

This thesis work describes about the performance study on OpenFlowand dynamic VLAN protocol. This study mainly deals with the initial setup ofeach protocol in the layer-2 network, used for the communication between hostsin a LAN. The performance study is performed by measuring the metric calledprotocol latency, i.e., protocol setup time.

Protocol setup time describes the time taken for each protocol to establisha link between the end-hosts and a successful ARP request-reply. It includes thetotal time taken for a host to connect to other host, i.e., establishing a linkbetween them and replying to the ARP request. By evaluating this, we can judgewhich protocol is e�ective enough in terms of time taken by each protocol inestablishment of link.

1.3 Problem Statement

In the present enterprise networks, LAN switching scenarios are beingimplemented in a large scale domains. For example, a large scale consortiumhaving many architectures, communication within hosts in a single architectureis established via LANs (layer 2 switching). Layer 2 switching uses MAC addressesfor communication between end-hosts. For such switching scenarios, VLANs arecon�gured in the whole architecture by network administrators. If there is asmall change in the network infrastructure, the administrator has to recon�gurethe whole architecture. In present industries, the behavioral patterns of hostsconnecting to the network is changing rapidly making manual recon�gurationsof the network merely impossible. To cope with this scenario, protocols aredeveloped that understand the position of end-hosts in the network creating arobust peer-to-peer link to maintain the connectivity.

For such connectivity, network implementations like dVLAN and Open-Flow are developed. The problem here is which protocol to use. Each protocolhas its own advantages and disadvantages.

1.4 Aims and objectives

The initial idea of this thesis was to focus only on the communicationsbetween the switches connected in the network (i.e., not an end-user perspective).The ideology of performance measurement was based on monitoring the packetinvolving in network connectivity. This idea was implemented in a network modeland later decided to omit this type of view due to lack of incomparable scenarioswhen looked through inter-switch communication channels.


The main challenge was to create/design comparable scenarios, which isachieved through end-users perceptive. This is performed by analyzing the com-munication between the end-hosts to establish the network connectivity betweenthem.

The main research goal of this project is to evaluate the performance ofdynamic Virtual LAN and OpenFlow technologies on the establishment of a peer-to-peer link. The reason behind choosing these two protocols for investigating theperformance and the a�ects they impose onto network is because of the dynamicbehavior they impose to cope with the behavior of the present enterprise network.

To obtain the projected goals, the following objectives are achieved.

� An in depth literature review is performed on the working of these twotechnologies.

� The implementations of these two protocols are performed in a networkmodel.

� MAC sni�ng by ARP is observed and analyzed.

� The network performance metric: protocol latency, is calculated for thisevaluation.

� Multi-vendor network devices are used in the experimental setup, obtainingvender independent communication.

� The analyzed data of both these protocols is compared and recommenda-tions are projected on which protocol to choose for a speci�c scenario.

1.5 Research Questions

RQ 1. How does OpenFlow protocol a�ect the link establishment between end-hosts in a two-tier network?

RQ 2. How does dVLAN (GVRP protocol) a�ect the link establishment betweenend-hosts in a two-tier network?

RQ 3. What is/are the performance metric/s that is/are to be considered toanalyze the behavior of each protocol in the handshaking process?

1.6 Research Method

This section explains the approaches used in implementing the protocols� OpenFlow and dVLAN. An initial literature review is performed for gainingknowledge on the required information to perform practical implementation of


the protocols. Later, an experiment bed is setup for this implementation, wheresame hardware is used in testbed to avoid the in�uence of di�erent hardwarecapabilities in the performance results extracted.

To answer RQ1 and RQ2; a performance metric called Protocol SetupTime is considered. To measure this metric, a testbed is setup, which gives thefeasibility to collect layer-2 packets and trace the relative packets from the traces,featuring in calculating the protocol delay.

The implementation of dVLAN is done using GVRP protocol. Thepresent manageable switches are all capable of exhibiting VLAN capabilities withsome having source functionalities (i.e., acting as a source/management device isa network) and some having end-node functionalities (i.e., acting as slave devices).In this protocol implementation, the GVRP protocol communication between theswitches is executed which enables in exchanging and learning the VLAN infor-mation and registering them into its own device.

The implementation of OpenFlow is done by installing an OpenFlow con-troller in a Linux based system. NOX is used as the controller for the OpenFlowswitch. OpenFlow switch is con�gured in virtualization mode, i.e., by assigningrespective VLANs for controller and OpenFlow instance.

Chapter 2:

BACKGROUND

Chapter 2

Background

This section describes in detail, the background theory of the protocols electedfor this research study.

2.1 VLAN � Virtual Local Area Networks

Figure 2.1: Ethernet frame with VLAN tag

Virtual Local Area Networks also called as VLANs [11], help to createmultiple broadcast domains on a single network hardware. VLANs generally workwith VLAN ID's otherwise called as VID's and MAC addresses. The VLANenabled devices introduce a VID into the frame of MAC header, which is used bythe switch in switching the packet to the desired destination MAC address. The�gure 2.1 illustrates the Ethernet frame with a VLAN tag in it.

The logically created broadcast domains using VLANs are independentto one another even though all these domains are physically interconnected. TheseVLANs come-in handy when there is a requirement of multiple networks but lacknetwork resources. By the use of VLANs, di�erent security regulations can beimplemented for di�erent users on their respective VLANs. A VLAN network isrepresented in �gure 2.2.

8

Chapter 2. Background 9

A packet is said to belong to a particular type of VLAN by determiningto which category it belongs to. VLANs are classi�ed into three types based onthe layer they act on: Port-Based VLANs, MAC Address Based VLANs (act onlayer-2) and Protocol-Based VLANs (propagate across layer-3) [9][10].

Figure 2.2: VLAN Architcture

2.1.1 Port-Based VLAN

These VLANs are assigned to speci�c port/s on a switch. For thistype of VLAN, network administrator need to perform a manual con�gurationon switch. A VLAN can be on a single port or on multiple ports.

The limitations on such type of VLANs are: 1) Port-Based VLANscannot overlap, 2) When a user changes to other port on the switch, then networkadministrator should recon�gure the switch [9][10].

Coming to con�guring these VLANs on a switch, di�erent modes of com-munication are associated within a switch to handle VLANs. Practically a switchis operated on three di�erent VLAN modes: Untagged, Tagged, No/Forbid.


� Untagged. A port of this mode is con�gured for end-user communication.A port-based VLAN con�gured as untagged, makes the end-user a memberof that VLAN. There can't be more than one untagged VLAN on a port.Whenever this port receives a packet with no VLAN tag (described in Figure2.1), then a VLAN tag of the con�gured VLAN on that port is assigned tothat packet by the switch. Packets that have a VLAN tag with this VLANID are dropped.

� Tagged. A port of this type is generally used for con�guring uplinks. Inthis case, the packets only with VLAN tags for those VLAN ID's that arecon�gured on that port are accepted. Packets without VLAN tags arehandled by the untagged VLANs con�gured on that port. If, no untaggedVLAN is con�gured, packet is dropped. Here, switch will not modify theheader of packet. Whenever an end-user is connected to a tagged port, useris responsible for tagging the packets to be able to communicate throughthe con�gured VLAN.

� No/Forbid. The port-based VLANs con�gured with this mode, rejects anyVLAN tagged packets for that VID and packets with no VLAN tags aremanaged by the untagged VLAN of that port.

2.1.2 MAC Address Based VLAN

In this category of VLANs, VLANs are assigned to MAC addressesof the devices connected to the switch. So, a membership between VLAN andMAC address is established. Unlike port-based VLANs, MAC address basedVLANs have a better deal of portability. For example, a user (MAC) assigned toa particular VLAN can connect to any port of the switch network without losingthe connectivity. It is the duty of switch to update its MAC table and it identi�esthe position of the user and switches the packet to the intended destination MACaddress [9][10].

2.1.3 Protocol-Based VLAN

In this case, the VLANs are de�ned by layer-3 addresses and protocoltype. Here, to determine the VLAN membership, the protocol type (if multipleprotocols are supported) or layer-3/network-layer address (IP address) is takenin to account.

This type of VLAN membership is developed to avoid the overhead torecon�gure the switch network due to rapid changing behavior of networks thatare IP con�gured. Replacing the entire IP con�gured structure with an IP-BasedVLAN would reduce the burden of recon�guring any changes that occurs to thenetwork like, a relocated node to a di�erent IP subnet.


Upon the mentioned advantage of protocol-based VLAN, there are sev-eral other advantages of such VLANs like, VLANs can be partitioned based onprotocols, network devices can be moved from one node to other without anyrecon�gurations, the frame tagging can be avoided as these VLAN work at net-work layer resulting in less transport overhead. The disadvantageous scenario inprotocol based VLANs is it's performance. Layer-2 switching is faster that layer-3routing resulting in time consuming factor [9][10].

All the classi�cations explained above (in sections: 2.1.1, 2.1.2, 2.1.3(cross)) need the network administrator to manually con�gure each and everynetwork device. Such a con�guration mechanism is not feasible in current enter-prise network. To avoid such a scenario, making the switches learn the VLANsin network by themselves will solve the problem. Implementing a protocol calledGVRP does this.

2.1.4 GVRP

GARP VLAN Registration Protocol (GVRP) is used to register VLANsin the switches, i.e., it broadcasts the con�gured VLANs in to network enablingother switches to learn from those broadcast packets. GVRP is an application ofGARP as illustrated in �gure 2.4. It explains the architectural design of GARP.GARP � Generic Address Resolution Protocol, provides a generic framework forend-hosts to register or deregister attribute values, like VID's etc. This helps inpropagating the attributes among the devices in the LAN. The devices in LANdo not directly use GARP; rather it speci�es di�erent applications to performrequired actions, like GVRP, GMPR � used for MAC registrations in LAN. As likeGARP, GVRP also de�nes both GVRP application address and GVRP attributetypes.

� GVRP application address. The GVRP aware switch starts to transmit theGVRP exchange messages with the destination address as 0x01-80-C2-00-00-21. This is the default destination address of a GVRP packet that isread by a GVRP enabled end/intermediate switch.

� GVRP attribute types. GVRP de�nes only one attribute, i.e., VLAN Iden-ti�er. This VLAN Identi�er is encoded in as 0x01 in the attribute type�eld. The other �eld is the attribute list �eld which contains the totallist of attributes consisting of VLAN ID's to be advertised. Each attributehas three �elds: attribute length, attribute event and attribute value. Theattribute value �eld contains the VID which is learned by the receivingswitch depending upon the event �eld. An event �eld describes the actionto be performed by the end/intermediate switches on the attribute val-ues. The action commands in the attribute event �eld are: LEAVE_ALL,


Figure 2.3: GARP Architecture [11]

JOIN_EMPTY, and JOIN_IN. A pictorial illustration of GVRP protocolformat is shown in Figure 2 4.

� LEAVE_ALL: This event will ask the switch to forget all the dynam-ically learnt VLANs from the source switch.

� JOIN_EMPTY: This event is triggered when an unknown VLAN isasked to be created in the end/intermediate switch.

� JOIN_IN: This event is triggered when a known VLAN is asked to becreated in the end/intermediate switch, i.e., if the end/intermediateswitch already has the VLAN con�gured and if it receives that sameVLAN ID from broadcast, then JOIN_IN is triggered.


Figure 2.4: GARP Architecture [11]

2.2 The New Network Architecture

A new architecture is established, called Ethane, to cope with the draw-backs of current architecture (explained in 2.2.2). Ethane is precursor to Open-Flow. It is built around three fundamental principles [12].

� "The network should be governed by policies declared over high

level names".

� " Policy should determine the path that packets follow".

� "The network should enforce a strong binding between a packet

and its origin".

2.2.1 Need for Software-De�ned Networking

The traditional network architecture is build based on a hierarchy, likea tree like structure. This type of architecture is inappropriate/not very wellsuited for the present dynamic behavior of computing. The following are somereasons for the need of improvised architecture [9].

� The dynamic changing patterns of tra�c between the hosts. Like in a client-server communication model, bulk of data tra�c is exchanged. The present


applications, access di�erent databases and servers for information, creatingan east-west machine-to-machine tra�c in prior to the response to the endhost/user through north-south tra�c pattern.

� The consumption of IT resources. Like-wisely in today's developing technol-ogy, introduction of smart phones and many other personal mobile devicesinto the network is creating pressure on the IT sector for accommodatingthe required resources for the end users at the same time providing securityfor the corporate data i.e., the production tra�c.

� The increase in cloud technology. Today's enterprise network is accompa-nied with both public and private cloud services giving forth a rapid growthof these services. These actions resulted in more security constraints, in-creased complexity, increase in demand for access of IT resources by enter-prise business units, etc.

2.2.2 Restrictions in Current Network

The points mentioned in section 2.2.1 are some of the current marketdemands for which the present network architecture is impossible to implement.The following are the limitations of current network architecture [9].

� Human administration. The current network is relatively static. Dynamicbehavior of the network needs an administrator (human) control. Accordingto a survey [4], 80% of the disruption in the network connectivity is due tohuman errors. Any change in the network infrastructure needs immediateadministration on several components in the network.

� Less �exible networks. The increase in demands on �ne-grained network-ing a�ects the infrastructure of network i.e., the increase in the growth ofthe network, number of devices in the network. This situation resulted ina more dynamic behavior of the data tra�c patterns in network, makingthem unpredictable. To cope with such behavior, IT management has em-ployed many parallel processing algorithms and multi-processing data setsinto its blend. For this massive implementation, IT have empower manytechnicians to provide high-performance in data transfer and to maintainconnectivity among hundreds of devices and servers. Such high scale manualcon�guration is merely laborious and highly error-prone.

� Vendor speci�cations. IT consortiums are seeking to implement new servicesto cope with accelerated change in the behavior of the network, but thevendor dependencies on the products are e�ecting the deployment of newservices. This restriction on the deployment limits the operators to con�nedproduct cycles.


These limitations mentioned above had brought the development of tra-ditional network to halt. Therefore, this resulted in demanding for a new networkarchitecture, thus in response, consortiums developed Software De�ned Network-ing (SDN) [9] architecture converting the above mentioned limitations into it'sfeatures. The architecture (SDN) and its associated standards are explained insection 2.2.

2.3 OpenFlow

The idea for implementing/designing the OpenFlow protocol was takenfrom the current functioning of manageable switches. Each switch has its own�ow-tables that are built from TCAMs (Ternary Content Addressable Memory)which include QoS, statistical data collection and line-rate performance. Thesetables are di�erent for each vendor. OpenFlow has taken advantage of this com-mon property of maintaining �ows giving an open �exibility to program �ows indi�erent network devices. By taking in such programming ability, the networkcan be partitioned into individual streams.

An OpenFlow switch [7][10][11] completely depends upon datapath whichconsists of Flow Table and action. The actions associated with each �ow entry ofthe switch can be expandable with extreme caution achieving greater �exibilityand higher-performance. The components of an OpenFlow switch are describedin the following section.

2.3.1 OpenFlow Switch components

The basic and fundamental components of an OpenFlow switch are clas-si�ed into three: a) A Flow Table, b) A Secure Channel, c) An OpenFlow protocol[10][14].

a) Flow Table � A Flow Table is a set of �ow entries, which consists of header�elds, counters and instruction sets. These are used to apply the respectiveactions on the �ows received by the switch (illustrated in Figure 2.5).

Figure 2.5: Flow Table

i. Header Fields � OpenFlow switch uses this column of the �ow table tomatch with the receiving �ow packets and applies the action associated


with the �ow entry, when a match is found. If no match is obtained,then the switch forwards the packet to the controller and receives anaction accordingly. The header �eld is contained with 10-tuple asdescribed in the following Figure 2.6. These ten header �elds are usedfor matching against the receiving �ows.

Figure 2.6: 10-Tuple

ii. Counters � This �eld keeps track of statistical data like, number ofreceived packets for that particular matched entry, bytes for each �owand duration of each �ow.

iii. Instruction sets � These sets are nothing but actions speci�ed for eachentry �ow. These actions provide information on how to administer thepackets of that �ow. The basic actions that all dedicated OpenFlowswitch support are:

i. Forward packets.

ii. Drop the packets (can be used for security purposes like, avoidingDoS attack).

iii. Sending the new �ows to the controller for actions.

b) Secure Channel � The secure connection between switch and controller usingTLS (Transport Level Security) for commands exchange and modifying the�ow tables in the switch.

c) OpenFlow Protocol � The protocol for enabling the controller to commu-nicate with the switch for giving commands on the new �ows received byswitch. A prede�ned interface is speci�ed for this communication and re-mote modi�cation of �ow tables. OpenFlow network consists of network in-terfaces/ports for passing the packets between the switches of the network.There are di�erent types of port abstractions, supported by OpenFlow likeStandard ports, Logical ports, etc [13].

The speci�cations of OpenFlow switch are explained in detail in Open-Flow Switch Speci�cation [13].

2.3.2 Operational steps of OpenFlow

The following Figure 2.7 explains the procedural steps performed byOpenFlow protocol.


Figure 2.7: Procedural steps carried out by OpenFlow [7][12]

From the Figure 2.7 [10][14], the working of OpenFlow can be depictedas: the moment switch receives a new �ow, the �rst packet of the �ow is sentto the controller. The controller parses the header of the packet and is matchedagainst the �ow-tables in the switch. If multiple matches are found, the actionsare considered according to the prioritization of the tables in the switch. Whena match is found, the action associated with the matched �ow entry is performedand the counters are updated. If a switch contains multiple �ow-tables, thenmatching is performed by pipeline processing which is illustrated in the followingFigure 2.8 [7][10].

If none of the �ow entries in the �ow table of the switch matchs, thenthe switch decides it to be a new �ow and noti�es it to the controller usinga PACKET_IN message. The controller receiving the PACKET_IN message,analyses the header of the packet and decides the appropriate action for the �owand alters the �ow table accordingly, using a PACKET_MODmessage. The replyto PACKET_IN message is responded by PACKET_OUT message. If thereare multiple OpenFlow supported switches in the network connected to a singlecontroller, then the controller sets a path for the �ow by sending PACKET_MODmessages to all the OpenFlow switches present in the network [10][14].

2.3.3 Classes of OpenFlow Communication

The classes of communication between switch and the controller usingOpenFlow protocol is classi�ed into three type [10][11]:


Figure 2.8: Pipeline Processing [7][10]

a) Controller-to-Switch Communication � is a controller triggered �ow/mes-sage used for feature detection, modify the con�gurations of switch and etc.There are many other purposes for these controller messages like, Modify-State, Packet-out, Role-Request, etc. These messages by the controllerdoesn't expect for any reply, i.e., the switch doesn't necessarily need torespond to every such messages.

b) Asynchronous Communication � It is a switch triggered message to thecontroller without its request. Asynchronous messages from the switch aresent to controller to intimate the controller regarding the events like, ar-rival of new �ow or change in state of switch or any error messages. Theasynchronous messages are majorly classi�ed into four types: Packet-in,Flow-Removed, Port-status, and Error [10][11].

c) Symmetric Communication � It is triggered by both the devices namely,switch and controller without any requisition by any device, i.e., both thedevices start to transmit messages to check the liveliness of the secure linkbetween the switch and controller. There are a total of three symmetricmessages exchanged by the two devices:

� Hello. When an OpenFlow instance is enabled on the switch, hellomessages are exchanged between switch and controller.

� Echo. This message is based on echo request/reply phenomena, i.e.,any of the device can send echo request message and expecting an echoreply from the other end. This is performed periodically by both thedevices only to verify whether the secure link is alive or not.

� Experimenter. This message is triggered by the switch providing them


a standard way to o�er additional functionality within its message typespace featuring a staging area for future improvements.

2.3.4 NOX � An OpenFlow Controller

The traditional network is constituted with low-level/machine-level con-�guration of individual devices. Machine-level means, the programs were writtenin machine-level language and hard coded into each device manually which hadno common abstractions/familiarities for the elemental network resources. Con-�guring such devices in the network with such level of abstraction is di�cult.For example, forcing users of a network to use a particular HTTP proxy requiresthe knowledge on topology of the network and position of each user. For morecomplex events, require more knowledge on the network. Such technique of hardcoded machine-level con�gurations is re�ected on an enterprise network is likecon�guring hardware peripherals of a computer without an operating system.

This problem can be overcome by having a way to con�gure all the net-work devices from one place. This can be done by creating a centralized networkby establishing an operating system for network. Alone the operating systemdoesn't manage the entire network underneath, it just provides an interface toprogram the network. Whereas the applications installed on top of this operatingsystem are the actual managers of the network. For this type of operating system,the important concepts to be remembered are: 1) the programming interface is tobe centralized, 2) the programs are written using high-level abstractions like, user-name, hostname rather that low-level abstractions like, IP and MAC addresses.

The answer for these requirements is given by designing an operatingsystem for network called NOX. NOX is a programmatic interface designed toachieve the requirements above mentioned in establishing a centralized program-matic network. NOX has adopted advantageous features like control granularity,switch abstraction, scaling, etc. For detailed understanding about NOX controllersee [15].

2.4 Related Works

The study of [10] details the work done on developing OpenFlow pro-tocol and its implementations in campus networks. The authors attempted toillustrate all the features of OpenFlow and its a�ects in the implementation ofprogrammatic network architectures providing a pragmatic compromise for theresearchers to run the experiments. Supporting to this, the speci�cations of anOpenFlow switch to be used in such networks are illustrated by the authors [13].

The research study performed in [16] were the initial steps taken to eval-uate the performance of OpenFlow. The authors made an attempt to measure


the performance in terms of scalability and adaptability of OpenFlow in the cur-rent network. This study was based on measuring switching time of OpenFlowhardware, re�ecting the forwarding speed and blocking probability of OpenFlowswitch attached to an OpenFlow controller. The authors concluded by explainingthe time taken by the controller to respond to the data plane requests with respectto the number of �ows received by the switch. This model explains the signi�-cance of the performance of controller in installing new �ows in the switch withhigh forwarding speeds. The authors of [17] focused their research completely ondata plane performance of OpenFlow, i.e., the switching performance. This studywas performed using OpenFlow implementations on Linux based PC's and com-paring the data path switching performance against layer-2 Ethernet switchingand layer-3 IP routing. The conclusions given were based on forwarding through-put and packet latency modeled in each scenario. The observations were in favorof OpenFlow switch in handling multiple �ow tables when compared to layer-2Ethernet switching. The statistical analysis re�ected a surprising performancedrop of 30% against OpenFlow.

The authors of [18] provided an in depth view on the concepts ofVLAN and its components by elaborating the bene�ts of network virtualizationthrough implementation of VLAN and also, IEEE 802.1Q trunking protocol isillustrated. They concluded by notifying the properties of VLAN like, scalability,�exibility, security, and network management issues that are associated with it.

Authors of [8] published a study on capability of VLANs on dynamicend-host behaviors. This publication is based on VLAN technology incorporatingGVRP registrations, enabling dynamic creation of VLANs in the network. Thisstudy involves in explaining the behavior of VLANs in wireless end-host roamingin the network with dynamic exhibition of GVRP properties.

Chapter 3:

METHODOLOGY

Chapter 3

Methodology

This chapter involves in explaining the methodology used for evaluatingthe performance of the selected protocols.

3.1 Experiment Setup

In this stage of research, a laboratory testbed is setup to evaluate thenetwork level performance of OpenFlow and dVLAN, focusing on the a�ects ofeach protocol impose in link connection between the end-hosts to their respectiveconnected switches.

A two-tier network architecture is considered for this experimentation,which include two di�erent vendor switches and three end-hosts. The reason be-hind choosing two-tier architecture is to represent centralized networking. TheFigures 3.1 and 3.4 illustrates the experiment set involved in the testbed. Thesource switch is the switch under administrator controller where all the con�g-urations are done which are re�ected in the underneath network devices, hencerepresenting a centralized architecture. For both the cases, the same architectureis used so as to have the same latency to have a better comparable scenario.

Two of the end-hosts run on latest Ubuntu 14.04 LTS operating systemwith one running a desktop version and the other running a server version whilethe other host runs OSX 10.10.4. The switches used are a HP ProCurve 2920and a NetGear GSM7224. Two di�erent vendor switches are used in this testbedso as to represent the vendor independent support of both protocols in switching.The following tables: Table 3.1 and Table 3.2 gives details on the hardwarespeci�cation on the devices used.

3.1.1 Dynamic Virtual LAN (dVLAN) Implementation

The Figure 3.1 illustrates the experimental setup of dVLAN implemen-tation. The following setup consists of a source switch, an end switch and twohosts connected to each switch. The source switch is the one which advertisesthe VLAN information to beneath switch re�ecting the registration of VLAN in

22

Chapter 3. Methodology 23

Hardware Speci�cationsSwitch Speci�cations

Source Switch End Switch

Firmware 15.17.0007 3.0.2.1

Ports 24G 24G

Model HP ProCurve 2920 NetGear GSM7224t

Table 3.1: Hardware Speci�cations - Switch

Hardware Speci�cationsHost Speci�cations

Host-1 Host-2 Host-3

OSUbuntu-14.04LTS-Desktop

Ubuntu-14.04LTS- Server

OS X 10.10.4

RAM 4GB 4GB 8GB

NIC Intel corp Intel corp Intel corp

CPU Intel - i5 Intel - i5 Intel - i5

Table 3.2: Hardware Speci�cations - Host

the end-switch. When a host with a desired VLAN is connected to one of theswitches, the host communicates with the connected switch and creates a pathway to the source switch of that particular VLAN. On the other hand, if there isanother host with the same desired VLAN that is connected to the other switch,the same process of communication takes place between the host and the con-nected switch to the source switch creating the complete VLAN path from hostto host making those two hosts belonging to a single VLAN.

This process is implemented with the above mentioned hardware that isexplained in the following steps:

� Initially, the source switch (in this case, it is the HP ProCurve 2920 switch)is con�gured with the desired VLANs (tagged). Then, GVRP admin-modeis enabled in the switch, resulting in making the device a GVRP-awareswitch. By this step, the source switch will start to advertise GVRP packetsthrough all of its ports into the network, with the destination MAC addressas 01:80:C2:00:00:21.

� In the end-switch, GVRP admin-mode is enabled, making the end-switchGVRP enabled device. As soon as the end-switch is connected to the sourceswitch, the advertisement packets broadcasted by the source switch is re-


Figure 3.1: Dynamic VLAN Experiment setup

ceived by the end-switch which contain the attributes of VLAN informa-tion. Upon reading these attributes, the end-switch will create the adver-tised VLANs in it. The Figure 3.2 shows the GVRP exchange between theswitches. This is how a dynamic VLAN is created in a switch. (Theoreti-cally, there is no limit for the number of switches that can be connected tothe network. For example, the VLANs that are con�gured in one switch ispropagated to the entire network creating VLANs in each switch).

� At this point, tagged VLANs are created in the end-switch. For the end-host(host1) to make use of these VLANs, they should be equipped with GVRP-aware Network Interface Cards (NICs). These NICs are con�gured with thedesired VLAN/s and once they are connected to any one of the ports of theswitch (source switch), the host and switch will start to communicate witheach other, making the port of the switch a member of that VLAN.

� Now, at the other end, when the host (host2) with a GVRP-aware NIC,con�gured to the same VLAN is connected to the end switch, communica-tions between those two devices take place making that port of the switcha tagged member of that VLAN.

� By the end of all these processes, there is a VLAN established in the network


Figure 3.2: GVRP exchange between switches

connecting the two end-hosts (host1 and host2) in a LAN network. Figure3.3 describes the result of GVRP.

� If the position of the hosts are changed, i.e., if the hosts are reconnected intodi�erent ports or, if there is another switch that is inserted in between theswitches, the above explained process is performed and a VLAN of desiredID is created in the network.

Figure 3.3: GVRP exchange in LAN

Note 1: For the source switch to advertise the VLANs that are con�guredin it, the VLANs should be active in that switch, i.e., at least one port on theswitch should be a member of the VLAN and must detect a linkbeat.


Note 2:The GVRP-learned VLANs function as tagged VLANs. If aswitch advertises an untagged VLAN to another switch, then the learning switchwill create a VLAN in it as a tagged VLAN on the port on which the switchlearned the VLAN. In this case, communication between the two switches is lostbecause of the untagged VLAN which can't be used as an uplink to the otherswitch. So, to avoid such risks, tagged VLANs are created in the source switch.

Note 3: A tagged VLAN port accepts only packets that have VLANtags of that VLAN ID in its Ethernet frame. If not, the packet is not accepted.The end-host is responsible for generating the packets with VLAN tags to be themember of that VLAN. This can be achieved by creating a virtual interface ina physical NIC of the host, naming it with the desired VLAN ID and sendingpackets through that virtual interface.

3.1.2 OpenFlow Implementation

In the implementation of OpenFlow protocol, NOX is used as the Open-Flow controller to command the switch that is connected to it though a securechannel. This secure channel uses transport level security (TLS). There are manymore OpenFlow controller softwares like, POX which is one of the powerful con-troller used in SDN architecture. NOX is selected as the OpenFlow controller forthis research work because of the following reasons:

� NOX is an open source software.

� The source of NOX is based on C++ which is fast in execution when com-pared to POX which uses python as its source.

The following Figure 3.4 illustrates the experimental setup of OpenFlowimplementation. The following setup consists of an OpenFlow capable switchthat is connected to an external controller, an end switch and two end-hosts. Thiscontroller is installed on the latest Ubuntu 14.04 LTS OS. In this setup, an end-host (host1) is connected to the OpenFlow switch and this switch is connected toan end host (host2) via a manageable switch (end switch). In this case, the extraswitch is used so as to make sure that the switching time in both the scenarios(dVLAN and OpenFlow) is relatively similar. The connectivity from the end-switch to host2 is maintained by the default_VLAN of the switch. When thehost1 tries to reach host2, then the OpenFlow machenism comes into picture. Asthe OpenFlow switch receives a request, the packet is forwarded to the controllerand in response, the controller sends the commands to the switch accordingly.This makes the switch to forward the packet as commanded, establishing a linkconnectivity between the end-hosts. This process is implemented with the abovementioned hardware that is explained in the following steps:

� The initial steps of implementation include checking whether the OpenFlowswitch software is up to date, i.e., the �rmware support of OpenFlow.


� After all the software requirements are set, the switch is now capable ofimplementing OpenFlow instances. An instance is nothing but a con�gura-tion set of parameters con�gured into an OpenFlow switch. There can ben number of OpenFlow instances con�gured on a physical switch.

Figure 3.4: OpenFlow Architecture

� In the OpenFlow switch static VLANS are con�gured which are controlledby OpenFlow protocol and a VLAN for controller. There are two OpenFlowmodes a switch can be con�gured to:

� Virtualization Mode: In this mode of operation, VLANs con�guredon the switch can be members of OpenFlow instances or can be non-OpenFlow VLANs. Each instance is independent of itself and has anown controller. An instance should have a VLAN as member associatedwith it. The following Figure 3.5 gives a clear cut idea of virtualizationmode.

� Aggregation mode: In this operative mode, all the VLANs that arecon�gured in the switch are members of OpenFlow instance exclud-ing the management VLAN and the controller VLAN. The followingFigure 3.6 gives a sketch on aggregation mode.

� In this research, virtualization mode is opted because there are only two hostsystems under test which can be controlled through vitualization moded.


Figure 3.5: Mode of OpenFlow - Virtualization mode

Figure 3.6: Mode of OpenFlow - Aggregation mode

� A VLAN for OpenFlow protocol and a VLAN for controller communicationare created in the switch.


� An OpenFlow instance is created by making the VLAN (created for thesake of OpenFlow) a member of that instance and attaching a controller tothat instance.

� A controller ID is created which is accompanied with the controller networkparameters like, controller IP address, controller VLAN ID, and controllerport number.

� After all the con�gurations are made (set of commands for con�guring anOpenFlow instance is detailed in Appendix, Section B), the OpenFlow in-stance is enabled on the switch making the switch a dumb forwarding devicewhere the brain being the controller (NOX, in our case).

� When host1 wants to communicate with host2, the switch will forward thepacket to the controller using a PACKET_IN message. The response to thismessage is given to switch by controller using a PACKET_OUT messagecontaining the actions for the switch to perform on such �ows. Along withthe out message, PACKET_MOD message is also sent to the switch, givinginstructions to the switch to add a �ow entry into its �ow table. The Figure3.7 depicts the packet exchange between controller and switch.

Figure 3.7: OF Switch - controller communication

� This process of sequential message exchange establishes the link betweenthe hosts by OpenFlow protocol.

3.2 Performance Metric Measurement

The metric � protocol setup time is calculated by capturing the requiredtraces using tshark. The path followed by the packets (i.e., the packet �ow), on theinitiation of respective protocols is explained in the posterior sections 3.2.1,3.2.2.

The traces are captured using tshark on the interface of host2. Thefollowing Figure 3.8 explains the location at which tshark is used to capturetraces.


Figure 3.8: Capture Description

3.2.1 Dynamic VLAN Setup Time Measurement

In case of dVLAN, the time at which host2 injects GVRP packet into theend-switch is considered, relative to the ARP reply obtained from host1 indicatingthe establishment of link. This relative time gives the total protocol setup timefor dynamic VLAN establishment using GVRP.

To calculate this metric, packets at link layer are captured. For such acapture, a set of testbed con�gurations are performed and the capture is executedas explained below:

� The hosts and switchs are installed with necessary software and con�gu-rations are made to make use of the VLANs that are created by GVRP,explained in Appendix, Section A.

� tshark at host2 is initiated on the interface that it is connected to the end-switch.

� ARP cache on both the hosts are cleared before initiating the tra�c.

� A tool called Mausezahn (mz) is used to generate ARP packets with interpacket delay of 1ms from host2 with target IP address of host1.

� Now, GVRP is enabled on host2 resulting in the injection of GVRP packetinto end-switch.


� The sequence of ARP requests with target IP of host1 are sent, till an ARPreply is received by host2.

� The tshark capture is stopped and the traces are written into a �le.

� All these steps consistute a run. Similarly, 1000 runs are performed toeliminate any randomness present in the capture (a perl script is written toautomate the iterations and parse the values).

� In the step of parsing the trace �les, the capture times of �rst GVRP packetgoing from host2 and the �rst ARP reply from host1 are traced and thedi�erence of these times is calculated, which gives the protocol setup timeof dVLAN. This is done using a perl script.

The following Figure 3.9 explains the sequential diagram of the packets,the path it follows to reach the destination host,i.e., host2 to host1. From theFigure 3.9 we can depict that, when a link is established, the ARP request fromhost2 goes to end-switch. Then the switch checks for a VLAN tag in the header�eld of packet and forwards the packet accordingly to that respective VLANmember port in the end-switch, in this case, it is the 802.1q VLAN trunk portcreated by GVRP. Packet reaches source switch and forwards it to the VLANtagged port on the switch where host1 is connected. The ARP reply from host1follows the same path to host2 through the switches indicating successful VLANestablishment.

Figure 3.9: Sequence diagram of dVLAN


The Figure 3.10 illustrates the packets involved in one run. It displaysa bunch of ARP requests with inter packet delay of 1ms. The ARP inter packetdelay is manipulated so as to reduce the time gap that is introduced between thepoint of time, when VLAN is created and the next ARP request going into thenetwork. As, the default time for ARP is 1 second, the GVRP injection couldbe at any time between two ARP requests, which results in the addition of extratime for the next ARP request to go into the network and get the reply. Thisrandomness can be avoided by sending multiple ARP requests with much lessinter packet delay and considering the �rst ARP reply received from host1. Theaverage time mentioned, is obtained from the experiment iterations performed.

Figure 3.10: Time line diagram of dVLAN

3.2.2 OpenFlow Setup Time Measurement

In case of OpenFlow, the request and reply include, the last ARP requestfrom host2 to host1 and the following subsequent ARP reply from host1 to host2respectively. Calculating the di�erence between request and response ARPs, givesthe protocol setup time of OpenFlow.

The following steps are followed in the capturing of packets for Open-FLow implementation:

� The installations and necessary con�gurations are performed on the Open-Flow switch in order to make the switch listen to the commands from con-troller through OpenFlow, which are explained in Appendix, Section B.

� In case of OpenFlow, tshark is initiated at host2.


� The instance on OpenFlow switch is enabled and the NOX controller isstarted.

� ARP cache on both the hosts are cleared out before initiating the tra�c.

� Using ping command, host1 is pinged from host2 and ARP messages arecaptured at that interface of host2.

� The relative time di�erence between the last ARP request going out fromhost2 and the �rst ARP reply coming to host2 gives the protocol setuptime.

� Now, tshark is stopped and traces are witten into a �le, that is parsed forthe required packets (as explained in above section 3.2.1). This is doneusing a perl script.

The following Figure 3.11 depicts the sequence diagram of packets in-volved in link establishment using OpenFlow. In the setup, it is ensured that�ow tables are empty. When host2 pings host1, ARP request is sent to endswitch, which is forwarded to OpenFlow switch through trunk port managed bydefault_VLAN. Now, the new �ow is detected and switch communicates withcontroller for the necessary actions. Then it is forwarded to the host1 whichsends an ARP reply to host2 following the same path. The reply packet receivedat host2 indicates the successful establishment of link between host1 and host2.

Figure 3.11: Sequence diagram of OpenFlow


The Figure 3.12 represents the time line diagram ofcommunication be-tween OpenFlow and controller. From the experimental observations, it is notedthat, the time taken for the openFlow-controller communication, from requestto reply, impose 4 extra packets for receiving and sending commands to con-troller. The average time mentioned, is obtained from the experiment iterationsperformed.

Figure 3.12: Time line diagram of OpenFlow

Chapter 4:

EXPERIMENT RESULTS AND

ANALYSIS

Chapter 4

Experiment Results and Analysis

This section describes the experimental results that are obtain by per-forming research on OpenFlow and dynamic VLAN switching protocols.

4.1 Dynamic VLAN Assessment

A total of 1000 iterations were performed to minimize the randomnessthat occur between the ARP request and GVRP packet injection.

DynamicVLAN

Average(ms)

Min (ms) Max (ms)StandardDeviation

Coe�cientof Variance

ProtocolSetup time

39 37 40 0.82 0.02

Table 4.1: Protocol Setup Time for dVLAN

The above Table 4.1 depicts the statistis obtained from the experimen-tation performed on dVLAN. The average time dVLAN took to establish theVLANs at necessary switch ports to establish the connectivity between the hostsis 39 ms. We can observe that, an almost consistant pattern is followed by dVLANin establishing VLAN dynamically. This can be seen in the following Figure 4.1,where x-axis represents the iteration number (i.e, like, iteration-1, iteration-2,etc., ) and y-axis represents the protocol setup time in milli-seconds. Here, aset of 900 iterations are plotted to show the pattern. As described in section3.2.1, a perl script is used to iterate the experiment a 1000 times and parsingthe statistics. There could be a possibility were, the tshark is triggered after thetra�c is initiated, resulting in missing the capture of packets. Due to this, thatiteration would result in no value. This can be the reason why out of 1000, 900samples were obtained. By seeing at this plot, we can say that the setup timesare varying between 37 ms and 40 ms.

36

Chapter 4. Experiment Results and Analysis 37

Figure 4.1: dVLAN Setup Time (iterations plot)

4.2 OpenFlow Assessment

A total of 1000 iterations were performed to minimize any randomnesswhich could occur between the ARP request and reply packets. The followingtable lists the statistical values obtained after performing the experiment forOpenFlow.

OpenFlowAverage(ms)

Min (ms) Max (ms)StandardDeviation

Coe�cientof Variance

ProtocolSetup time

8 7 10 0.59 0.07

Table 4.2: Protocol Setup Time for OpenFlow

From the above Table 4.2, we can observe that, OpenFlow protocol fol-lows a consistent pattern in establishing the link between hosts. Coe�cient ofvariance is listed to 7%, indicating only 7% variation between the iterations ob-tained from the mean. The maximum time taken by OpenFlow to setup a link is10ms which is relatively less when compared to dVLAN.

An iteration plot for OpenFlow of 900 iterations is plotted and repre-sented in Figure 4.2, displaying the setup time variation in the range of 7ms to10ms.

From both the cases, we can observe that the variation between theiterations is very less, i.e., 2% for dVLAN and 7% for OpenFlow. This consistencyin the obtained results can be due to no application of any sort of load in thenetwork.


Figure 4.2: OpenFlow Setup Time (iterations plot)

4.3 Theoretical Model

From the methodology described above, it is clearly understood that themain focus of this study is on the protocol mechanism, but not on the hardwareused. To give the reader an information regarding the hardware, switches andhosts in the testbed are equipped with latest processors with high processingspeeds and latest �rmware's.

A question would pop in the readers mind, that, does this have anyhardware dependency. The purpose here is to compare two protocols, which isdone through performance evaluation on a desired hardware. Upon passing ofseveral years, there can be developments in the processing power of hardwarewhich can reduce the time obtained when compared to this study. Even though,the individual protocol setup time may reduce, but the relative di�erence betweenthe times of the two protocols would be same.

From this discussion, a theoretical model (for each protocol) can bederived, which gives the setup time for that respective protocol upon takingnecessary parameters as inputs.

4.3.1 Dynamic VLAN

In case of dVLANs, the parameters involved would be:

� Switch processing speed.

� Link speed between connected switches.


� Link speed between switch and host.

� Processing speed of NIC in the host.

� Distance.

The �rst parameter de�nes the CPU speed of the switch used in thenetwork. The second and third parameters de�ne the physical link speed usedto connect devices. The fourth parameter de�nes the speed at which NIC works.Last but not the least, distance parameter de�nes the distance between devices inthe network. This is used as a time scale factor, i.e., depending on the distance,the latency vary. For example, for a cat6 Gigabit Ethernet cable of 250 meters,introduces 10 nano seconds of latency.

By giving these parameters as inputs to the dVLAN model, the protocolsetup time for a two-tier architecture can be obtained.

4.3.2 OpenFlow Protocol

In case of OpenFlow, the parameters involved would be:

� Switch processing speed.

� Link speed between connected switches.

� Link speed between switch and host.

� Distance.

� Controller Placement.

The �rst parameter de�nes the CPU speed of the switch used in thenetwork. The second and third parameters de�ne the physical link speed usedto connect devices. The fourth parameter can be split into two sub-parameterts:distance between switches, distance between switch and hosts. Last but not theleast, controller placement de�nes the distance between OpenFlow switch andcontroller.

By giving these parameters as inputs to the OpenFlow model, the pro-tocol setup time for a two-tier architecture can be obtained. This model can beextended to next level architecture, taking number of switches and the architec-ture shape as inputs.

Chapter5:

CONCLUSIONS

Chapter 5

Conclusions

For the evaluation of performance on OpenFlow and dVLAN, an im-plementation of both these protocols is performed and an in-depth analysis onthe tra�c patterns is carried out by using ARP � MAC sni�ng technology. Aprede�ned hardware is used for both the implementations, so as to avoid anyhardware in�uences in the performance of these protocols.

The statistics obtained from the experimental results show that, the av-erage time taken by dVLAN to setup a link between hosts is relatively more whencompared to OpenFlow. This re�ects that OpenFlow is much faster in establish-ing connectivity against dVLAN. The variations existed in dVLAN is due to thedi�erent timings of ARP and GVRP injection, resulted delaying connectivity.

Furthermore, from the observations on experimental setup, GVRP de-pends upon the nature of hosts that connects to the switch, i.e., a perfectlycon�gured host is only capable of using the services provided by GVRP. Anymiscon�gurations done in hosts results is connectivity breakage. The chances ofhaving such dearth in host con�gurations is because, the network administratoris not responsible for con�guring the end hosts, leaving all the troublesome con-�gurations to the end-user. But, in case of OpenFlow, all such con�gurations arenot required, the task of end-host is to just get connected to the network, whereall the work is done by OpenFlow. Coming to critiques of OpenFlow, chain ofOpenFLow switches can e�ect in two perspectivies: 1) New Flow : When ever anew �ow is received by the OpenFLow switch, it takes 8 ms to register the �owand establish a link, 2)Network level : As number of OpenFlow switches increase,the time taken to establish a link proportionally increases. Whereas in dVLANs,once the VLANs are created, it takes just the switching time to reach the otherend.

In a wide-spread approach, consortiums which have time dependenciescan choose OpenFlow for it least execution time and for its easy end-user experi-ence. On the other hand, the organizations that have least interest in setup timebut like to reduce the complexity in network architecture, can choose dVLAN forits easy implementation.

41

Chapter 5. Conclusions 42

Linking to Research Questions:

RQ 1. How does OpenFlow protocol a�ect the link establishment be-tween end-hosts in a two-tier network?Ans: A link between the two hosts is established by the switch-controllercommunication done using OpenFlow. Table 4.2 gives a statistical view onthe performance of OpenFlow. The experimental analyses projects the pat-terns of tra�c followed by OpenFlow in establishing the connection. Thesepatterns illustrates the latency introduced by OpenFlow in dealing withnew �ows. Upon reading a new �ow, switch communicates with the con-troller for the necessary commands, which introduce latency in connectivity.When it comes to protocol time, the average time it takes to establish thelink is 8 ms (which is signi�cantly less when viewed through end-user per-spective). When this is compared with dVLAN, OpenFlow turns out to bethe e�ective protocol in the terms of protocol setup time.

RQ 2. How does dVLAN (GVRP protocol) a�ect the link establish-ment between end-hosts in a two-tier network?Ans: A link between the two hosts is established by the GVRP exchangeexhibited by the network devices resulting in dynamic VLAN creation andVLAN memberships on the ports the VLAN is leant. The Table 4.1 illus-trates the performance statistics exhibited by it in the presented experi-mental model. Looking at these statistics against OpenFlow, this re�ectsthe poor performance of dVLAN which takes an average time of 39 ms toestablish VLANs at required ports on the switch/s to enable connectivity.

RQ 3. What are the performance metrics that are considered to ana-lyze the behavior of each protocol in handshaking process?Ans: Protocol setup time is derived to be an e�ective metric to evaluate theperformance of each protocol in establishing connectivity. This is choosenas the vital metric in this study because the focus of this study is entirelybased only on the time taken by each protocol in establishing connectivity,where calculating this metric would help in achieving this time along withhaving a better comparission to recommend which is e�ective.

Future Work

The research work performed here is regarding the perfor-mance evaluation on OpenFlow and dVLAN. From the conclusions,it is conveyed that OpenFlow using NOX controller is on the upperhand when compared to dVLAN. Firstly, it would be interesting to

Chapter 5. Conclusions 43

replace NOX with POX controller, which is a well-known OpenFlowcontroller and test it against the protocol setup time.

Secondly, the experiment bed used in this study is a two-tirenetwork having only two switches in it. The number of OpenFlowswitches can be increased by expanding the architecture and test-ing for multi-switch control by a single controller (ie., one controllerconnected to more than one OpenFlow switch). Following this, com-parision of OpenFlow versions (like v1.1 vs v1.2 vs v1.3) could beinteresting, whether the protocol setup time depend on the versionsof OpenFlow protocol used.

Thirdly, here, only one OpenFlow switch is used, which canbe expanded to several switches and judging the placement of con-troller. Studying on the controller placement scenario with a networkof several switches could be an interesting research study.

References

[1] D. Caldwell, A. Gilbert, J. Gottlieb, A. Greenberg, G. Hjalmtys-son, and J. Rexford, "The cutting EDGE of IP router con�gura-tion," ACM SIGCOMM Computer Communication Review, vol.34, no. 1. p. 21, 2004.

[2] G. Xie, J. Zhan, D. A. Maltz, H. Zhang, A. Greenberg, and G.Hjï¿½lmtï¿½sson, "Routing design in operational networks," ACMSIGCOMM Computer Communication Review, vol. 34, no. 4. p.27, 2004.

[3] A. Wool, "The use and usability of direction-based �ltering in�rewalls,"Computers and Security, vol. 23, no. 6. pp. 459-468,2004.

[4] Z. Kerravala, "Con�guration management delivers business re-siliency," 2002.

[5] N. M. M. K. Chowdhury and R. Boutaba, "Network virtualiza-tion: state of the art and research challenges," CommunicationsMagazine, IEEE, vol. 47, no. 7. pp. 20-26, 2009.

[6] Allied Telesis, "Overview of VLANs ( Virtual LANs )," 2008.

[7] A. W. Paper, "Applications and Technology," vol. 1, no. 408, pp.1-7.

[8] R. C. Meier, "Mobile Virtual LAN," 7,724,715, 2010.

[9] Open Networking Foundation, "Software-De�ned Networking:The New Norm for Networks [white paper]," ONF White Pap.,pp. 1-12, 2012.

44

References 45

[10] N. Mckeown, T. Anderson, H. Balakrishnan, G. M. Parulkar, L.L. Peterson, J. Rexford, S. Shenker, J. S. Turner, and S. Louis,"OpenFlow: enabling innovation in campus networks," Comput.Commun. Rev., vol. 38, pp. 69-74, 2008.

[11] R. Seifert, The All-New Switch Book, 2nd ed. 2008.

[12] M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown, andS. Shenker, "Ethane: taking control of the enterprise," Sigcomm'07, pp. 1-12, 2007.

[13] B. Heller, "OpenFlow Switch Speci�cation," Current, vol. 0, pp.1-36, 2009.

[14] W. Braun and M. Menth, "Software-De�ned Networking Us-ing OpenFlow: Protocols, Applications and Architectural DesignChoices," Futur. Internet, vol. 6, no. 2, pp. 302-336, 2014.

[15] N. Gude, T. Koponen, J. Pettit, B. Pfa�, M. Casado, N. McK-eown, and S. Shenker, "NOX: towards an operating system fornetworks," SIGCOMM Comput. Commun. Rev., vol. 38, no. 3,pp. 105-110, 2008.

[16] M. Jarschel, S. Oechsner, D. Schlosser, R. Pries, S. Goll, andP. Tran-Gia, "Modeling and performance evaluation of an Open-Flow architecture," 2011 23rd Int. Teletra�c Congr., pp. 1-7,2011.

[17] A. Bianco, R. Birke, L. Giraudo, and M. Palacin, "OpenFlowswitching: Data plane performance," IEEE Int. Conf. Commun.,2010.

[18] I. A. Alimi and A. O. Mufutau, "Enhancement of Network Per-formance of an Enterprises Network with VLAN," vol. 1, no. 2,pp. 82-93, 2015.

[19] VLAN Membership Policy Server (VMPS) / Dynamic VLANs:http://www.cisco.com/en/US/tech/tk389/tk814/tk839/tsd_technology_support_sub-protocol_home.html. Accessed: 2015-09-20.

Appendix

Appendix

In this appendix, the description of sequential steps performedin installations and con�gurations of softwares and hardware used inthis thesis is presented. This appendix is further divided into threesections. The �rst one involves the installations and con�gurationsdone for setting up Dynamic VLAN and the posterior section describesregarding the steps of OpenFlow. The last illustrates the automationfor measurement and parsing of traces that are involved in this study.

SECTION A

In this section, the steps followed to con�gure the source switch,the end-switch and the hosts connecting to the GVRP switches islisted.

Source Switch

It is the administrator switch of the network, which is con-�gured with the desired VLANs. In this study, HP ProCurve 2920managable switch is used as a source switch. Using a console cable(serial port on one side and RJ-45 on the other), the switch can beaccessed through CLI. The following commands are used to login tothe switch and create VLANs. To connect to the switch, a serial portcommunication software called minicom is used. To install minicomin Ubuntu system and to open the minicom session, the followingcommands are used:

$sudo apt-get install minicom$minicom -s

Now, a con�guration box appears listing the con�gurable op-

47

Appendix 48

tions in minicom. Select serial port setup to set the serial connection.Following the options will create a minicom con�gure �le using whichthe switch can be accessed, by the following command:

$sudo minicom <con�g name>

After accessing into switch, following commands are used tocon�gure VLAN-x with name vlanx in the switch.

HP ProCurve Switch# con�gHP ProCurve Switch# vlan x name vlanx

Following with tagged or untagged or forbid. To get help inthe command syntax, type ? which will list all the possible options inthat mode (right now, it's con�g mode). Finally enabling gvrp in it,using:

HP ProCurve Switch# [no] gvrp

Here `no' implies the reverse action of that command, here itsdisabling gvrp.

End Switch

It is the switch which acts as the learning switch that enableto create VLANs broadcasted by source switch. As an end switch,NetGear GSM7224 is used. Similar con�guration steps are followedto this switch to access the CLI of it. Then pressing ? will give thesyntax and list of con�gurable options of that switch.

In this study, end switch is not con�gured with any VLAN(expect for default_VLAN). Here, gvrp admin mode is enabled tomake this switch GVRP aware.

GSM7224# enGSM7224# con�gure

GSM7224# gvrp adminmode

Appendix 49

HostIn this study, the end hosts are installed with Ubuntu 14.04

LTS. To make the host use of the dVLANs created in the switch,they must be con�gured in such a way that, the NIC of hosts wouldtransmit packets with VLAN tags in it. The following commands willdo so:

#apt-get install vlan#modprobe 8021q

#vcon�g add <interface_name> <VLAN ID>#ifcon�g <interface_name>.<VLAN ID> <ip-addr>

netmask 255.255.255.0 up#ifcon�g <interface_name>.<VLAN ID> mtu 1412

SECTION BIn this section, the installations and con�gurations performed

to make a working NOX controller in Ubuntu system is explained.The detailed illustration of creating OpenFlow instances is explainedin HP OpenFlow 1.3 Administrator Guide. The installation steps areas followed:

$cd /etc/apt/sources.list.d

$wget http://open�owswitch.org/downloads/debian/nox.list

$apt-get update

$apt-get install nox-dependencies

$apt-get install nox-dependencies

$apt-get install libtbb-dev

$apt-get install libboost-serialization-dev libboost-all-dev

$git clone git://github.com/noxrepo/nox

$./boot.sh

$cd nox

http://h10032.www1.hp.com/ctg/Manual/c04495114

Appendix 50

$mkdir build

$cd build

$../con�gure

$make

$make install

By the end of this a completely con�gured NOX is installed inthe system. To execute NOX controller, cd in to bulid/src directoryin the source of NOX and execute the following command:

$ ./nox_core -i ptcp:6633 switch

SECTION CIn this section, procedural steps in performing the measurement

iterations on dVLAN is explained. The following Figure 1 displays thetrace obtained from a single run when experimented on dVLAN. Thehighlighted packets are the focus of interest. The timestamps of thesepackets are parsed using a perl script and the di�erence is calculated.

Figure 1: Trace of dVLAN

Appendix 51

The following Figure 2 displays the trace obtained from a singlerun when experimented on OpenFlow. The highlighted packets arethe focus of interest, i.e., the ARP request to host1 and ARP reply tohost2. The timestamps of these packets are parsed using a perl scriptand the di�erence is calculated.

Figure 2: Trace of OpenFlow

This document was typeset usingLATEX edited in MAC. The typeset

software used is TeXShop.

http://tex.stackexchange.com

performance analysis on dynamic vlan and …861021/fulltext01.pdf · master thesis electrical...

Documents