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:
regu14@student.bth.se,
kamalteja.gurramkonda@gmail.com
University advisor(s):
Dr. Patrik Arlos School of Computing
University examiner(s):
Dr. Kurt Tutschku
Department of Communication Systems
School of Computing
Blekinge Institute of Technology Internet : www.bth.se/com
SE-371 79 Karlskrona Phone : +46 455 38 50 00
Sweden 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 dierent protocols and applications. With such increase in networking technology, the security constraints are becoming more and more severe, reducing the accessibility to the actual network for implementing new protocols. This scenario forced for an urgent need of a technology, which can help the re- searchers to implement their developed protocols in the network without in uencing the production tra c. This need resulted in a concept called network isolation. This is achieved by VLAN or SDN technologies.
In this study, we investigate the performance of VLAN and an API of SDN in the context of establishing dynamic link, in switching setup. For such a link creation, dynamic VLAN (dVLAN) is used in the former case and OpenFLow protocol is used in the later scenario. The main focus in this study is to compare the dynamic behavior of both the protocols in layer-2 context by measuring network level performance metrics of each protocol.
Some of the features like, vendor independency and software independency is taken into account while measuring the performance metrics.
In order to evaluate the performance, an experimental testbed is implemented. The network level performance metric called protocol setup time is measured. It is the time taken by each protocol to setup an active link between two end-hosts. A two-tire network architecture is implemented with 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 on the 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. I especially have deep scence of gratitude towards my friends who helped me and gave 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 challenging tasks. I have surely learnt many lots of things by working under him and especially increased 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 2
1.1 Motivation . . . 3
1.2 Scope of Thesis . . . 4
1.3 Problem Statement . . . 4
1.4 Aims and objectives . . . 4
1.5 Research Questions . . . 5
1.6 Research Method . . . 5
2 Background 8 2.1 VLAN Virtual Local Area Networks . . . 8
2.1.1 Port-Based VLAN . . . 9
2.1.2 MAC Address Based VLAN . . . 10
2.1.3 Protocol-Based VLAN . . . 10
2.1.4 GVRP . . . 11
2.2 The New Network Architecture . . . 13
2.2.1 Need for Software-De ned Networking . . . 13
2.2.2 Restrictions in Current Network . . . 14
2.3 OpenFlow . . . 15
2.3.1 OpenFlow Switch components . . . 15
2.3.2 Operational steps of OpenFlow . . . 16
2.3.3 Classes of OpenFlow Communication . . . 17
2.3.4 NOX An OpenFlow Controller . . . 19
2.4 Related Works . . . 19 iii
3 Methodology 22
3.1 Experiment Setup . . . 22
3.1.1 Dynamic Virtual LAN (dVLAN) Implementation . . . 22
3.1.2 OpenFlow Implementation . . . 26
3.2 Performance Metric Measurement . . . 29
3.2.1 Dynamic VLAN Setup Time Measurement . . . 30
3.2.2 OpenFlow Setup Time Measurement . . . 32
4 Experiment Results and Analysis 36 4.1 Dynamic VLAN Assessment . . . 36
4.2 OpenFlow Assessment . . . 37
4.3 Theoretical Model . . . 38
4.3.1 Dynamic VLAN . . . 38
4.3.2 OpenFlow Protocol . . . 39
5 Conclusions 41
References 44
Appendix 47
iv
List of Figures
2.1 Ethernet frame with VLAN tag . . . 8
2.2 VLAN Architcture . . . 9
2.3 GARP Architecture [11] . . . 12
2.4 GARP Architecture [11] . . . 13
2.5 Flow Table . . . 15
2.6 10-Tuple . . . 16
2.7 Procedural steps carried out by OpenFlow [7][12] . . . 17
2.8 Pipeline Processing [7][10] . . . 18
3.1 Dynamic VLAN Experiment setup . . . 24
3.2 GVRP exchange between switches . . . 25
3.3 GVRP exchange in LAN . . . 25
3.4 OpenFlow Architecture . . . 27
3.5 Mode of OpenFlow - Virtualization mode . . . 28
3.6 Mode of OpenFlow - Aggregation mode . . . 28
3.7 OF Switch - controller communication . . . 29
3.8 Capture Description . . . 30
3.9 Sequence diagram of dVLAN . . . 31
3.10 Time line diagram of dVLAN . . . 32
3.11 Sequence diagram of OpenFlow . . . 33
3.12 Time line diagram of OpenFlow . . . 34
4.1 dVLAN Setup Time (iterations plot) . . . 37
4.2 OpenFlow Setup Time (iterations plot) . . . 38
1 Trace of dVLAN . . . 50
2 Trace of OpenFlow . . . 51
v
List of Tables
3.1 Hardware Speci cations - Switch . . . 23
3.2 Hardware Speci cations - Host . . . 23
4.1 Protocol Setup Time for dVLAN . . . 36
4.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 by day. Enterprise networks are often large networks that incorporate dierent vari- eties of protocols and applications. These networks are installed with enormous equipment and protocols, increasing the security constrains creating a challeng- ing environment for the researchers in network innovation. The current possible methods are fragile making the enterprise expensive and error-prone. The cur- rent methods are indeed manual con guration setups done by trained operators to achieve adequate security [1][2][3]. A research group called Yankee reported that, on an average the total network downtime was around 62% which was only due to human error and 80% of IT budget was spent only on maintenance and operations [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 the availability 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 dierent hosts at dierent localities into a single network which are software administrated. These VLANs are indepen- dent of physical connectivity i.e., hosts at dierent physical locations are brought together, resulting in more exible network administration, management and re- con guration [5][6][7]. The next stage of VLANs is Dynamic VLANs [8]. This concept is derived, as the manual con guration of these VLANs is very com- plex in the current innovative enterprise network architecture. The con guring of 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 from that switch resulting in dynamic creation of those advertised VLANs from the administrator switch. Such dynamic VLANs, cope with some of the limitations of 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 to make 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. Decoupling network control and forwarding plane achieve this. The network control plane and forwarding plane communicate via a secured channel. This secured control data path interface is managed by OpenFlow protocol. OpenFlow is the rst communication interface protocol constructed between the control and data path of SDN architecture [9][10].
OpenFlow is a protocol that provides the feasibility for the administrator to program the ow tables of dierent switches. OpenFlow virtualizes network into 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 (dynamic VLAN) have some similar features with the new architecture protocol OpenFlow making an interesting research topic.
The performance of both the protocols is measured and analyzed with the help of an experimental setup. Protocol latency is measured in the context of protocol establishment at layer-2.
1.1 Motivation
The main reason for performing this study is to evaluate the performance of the two dynamic switching protocols dVLAN (GVRP) and OpenFlow. The motivative reason behind choosing this study is availability of similar featured protocols to implement network isolation. The break point scenarios are also explained, where one is reasonably better over the other protocol in the context of switching setup.
In case of dynamic VLANs, there are dierent types of protocols (like, GVRP, VMPS) to implement it. In this study, GVRP is used because of its application and vendor independence. GVRP is concerned with dynamic VLAN creation in the network, whereas VMPS is con ned within a switch. GVRP is a vendor 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 a switch, 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, enabled to implement comparable scenarios.
Chapter 1. Introduction 4
1.2 Scope of Thesis
This thesis work describes about the performance study on OpenFlow and dynamic VLAN protocol. This study mainly deals with the initial setup of each protocol in the layer-2 network, used for the communication between hosts in a LAN. The performance study is performed by measuring the metric called protocol latency, i.e., protocol setup time.
Protocol setup time describes the time taken for each protocol to establish a link between the end-hosts and a successful ARP request-reply. It includes the total time taken for a host to connect to other host, i.e., establishing a link between them and replying to the ARP request. By evaluating this, we can judge which protocol is eective enough in terms of time taken by each protocol in establishment of link.
1.3 Problem Statement
In the present enterprise networks, LAN switching scenarios are being implemented in a large scale domains. For example, a large scale consortium having many architectures, communication within hosts in a single architecture is established via LANs (layer 2 switching). Layer 2 switching uses MAC addresses for communication between end-hosts. For such switching scenarios, VLANs are con gured in the whole architecture by network administrators. If there is a small change in the network infrastructure, the administrator has to recon gure the whole architecture. In present industries, the behavioral patterns of hosts connecting to the network is changing rapidly making manual recon gurations of the network merely impossible. To cope with this scenario, protocols are developed that understand the position of end-hosts in the network creating a robust 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 protocol has its own advantages and disadvantages.
1.4 Aims and objectives
The initial idea of this thesis was to focus only on the communications between the switches connected in the network (i.e., not an end-user perspective).
The ideology of performance measurement was based on monitoring the packet involving in network connectivity. This idea was implemented in a network model and later decided to omit this type of view due to lack of incomparable scenarios when looked through inter-switch communication channels.
Chapter 1. Introduction 5 The main challenge was to create/design comparable scenarios, which is achieved through end-users perceptive. This is performed by analyzing the com- munication between the end-hosts to establish the network connectivity between them.
The main research goal of this project is to evaluate the performance of dynamic Virtual LAN and OpenFlow technologies on the establishment of a peer- to-peer link. The reason behind choosing these two protocols for investigating the performance and the aects they impose onto network is because of the dynamic behavior 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 two technologies.
The implementations of these two protocols are performed in a network model.
MAC sni ng by ARP is observed and analyzed.
The network performance metric: protocol latency, is calculated for this evaluation.
Multi-vendor network devices are used in the experimental setup, obtaining vender 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 aect the link establishment between end- hosts in a two-tier network?
RQ 2. How does dVLAN (GVRP protocol) aect the link establishment between end-hosts in a two-tier network?
RQ 3. What is/are the performance metric/s that is/are to be considered to analyze 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 gaining knowledge on the required information to perform practical implementation of
Chapter 1. Introduction 6 the protocols. Later, an experiment bed is setup for this implementation, where same hardware is used in testbed to avoid the in uence of dierent hardware capabilities in the performance results extracted.
To answer RQ1 and RQ2; a performance metric called Protocol Setup Time is considered. To measure this metric, a testbed is setup, which gives the feasibility 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. The present manageable switches are all capable of exhibiting VLAN capabilities with some having source functionalities (i.e., acting as a source/management device is a network) and some having end-node functionalities (i.e., acting as slave devices).
In this protocol implementation, the GVRP protocol communication between the switches 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 OpenFlow switch. OpenFlow switch is con gured in virtualization mode, i.e., by assigning respective VLANs for controller and OpenFlow instance.
Chapter 2:
BACKGROUND
Chapter 2
Background
This section describes in detail, the background theory of the protocols elected for 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 create multiple broadcast domains on a single network hardware. VLANs generally work with VLAN ID's otherwise called as VID's and MAC addresses. The VLAN enabled devices introduce a VID into the frame of MAC header, which is used by the 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 independent to one another even though all these domains are physically interconnected. These VLANs come-in handy when there is a requirement of multiple networks but lack network resources. By the use of VLANs, dierent security regulations can be implemented for dierent users on their respective VLANs. A VLAN network is represented in gure 2.2.
8
Chapter 2. Background 9 A packet is said to belong to a particular type of VLAN by determining to which category it belongs to. VLANs are classi ed into three types based on the layer they act on: Port-Based VLANs, MAC Address Based VLANs (act on layer-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 this type of VLAN, network administrator need to perform a manual con guration on switch. A VLAN can be on a single port or on multiple ports.
The limitations on such type of VLANs are: 1) Port-Based VLANs cannot overlap, 2) When a user changes to other port on the switch, then network administrator should recon gure the switch [9][10].
Coming to con guring these VLANs on a switch, dierent modes of com- munication are associated within a switch to handle VLANs. Practically a switch is operated on three dierent VLAN modes: Untagged, Tagged, No/Forbid.
Chapter 2. Background 10
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 member of 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 Figure 2.1), then a VLAN tag of the con gured VLAN on that port is assigned to that packet by the switch. Packets that have a VLAN tag with this VLAN ID are dropped.
Tagged. A port of this type is generally used for con guring uplinks. In this case, the packets only with VLAN tags for those VLAN ID's that are con gured on that port are accepted. Packets without VLAN tags are handled by the untagged VLANs con gured on that port. If, no untagged VLAN is con gured, packet is dropped. Here, switch will not modify the header of packet. Whenever an end-user is connected to a tagged port, user is responsible for tagging the packets to be able to communicate through the con gured VLAN.
No/Forbid. The port-based VLANs con gured with this mode, rejects any VLAN tagged packets for that VID and packets with no VLAN tags are managed by the untagged VLAN of that port.
2.1.2 MAC Address Based VLAN
In this category of VLANs, VLANs are assigned to MAC addresses of the devices connected to the switch. So, a membership between VLAN and MAC address is established. Unlike port-based VLANs, MAC address based VLANs have a better deal of portability. For example, a user (MAC) assigned to a particular VLAN can connect to any port of the switch network without losing the connectivity. It is the duty of switch to update its MAC table and it identi es the position of the user and switches the packet to the intended destination MAC address [9][10].
2.1.3 Protocol-Based VLAN
In this case, the VLANs are de ned by layer-3 addresses and protocol type. Here, to determine the VLAN membership, the protocol type (if multiple protocols are supported) or layer-3/network-layer address (IP address) is taken in to account.
This type of VLAN membership is developed to avoid the overhead to recon gure the switch network due to rapid changing behavior of networks that are IP con gured. Replacing the entire IP con gured structure with an IP-Based VLAN would reduce the burden of recon guring any changes that occurs to the network like, a relocated node to a dierent IP subnet.
Chapter 2. Background 11 Upon the mentioned advantage of protocol-based VLAN, there are sev- eral other advantages of such VLANs like, VLANs can be partitioned based on protocols, network devices can be moved from one node to other without any recon gurations, the frame tagging can be avoided as these VLAN work at net- work layer resulting in less transport overhead. The disadvantageous scenario in protocol based VLANs is it's performance. Layer-2 switching is faster that layer-3 routing 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 every network device. Such a con guration mechanism is not feasible in current enter- prise network. To avoid such a scenario, making the switches learn the VLANs in network by themselves will solve the problem. Implementing a protocol called GVRP does this.
2.1.4 GVRP
GARP VLAN Registration Protocol (GVRP) is used to register VLANs in the switches, i.e., it broadcasts the con gured VLANs in to network enabling other switches to learn from those broadcast packets. GVRP is an application of GARP as illustrated in gure 2.4. It explains the architectural design of GARP.
GARP Generic Address Resolution Protocol, provides a generic framework for end-hosts to register or deregister attribute values, like VID's etc. This helps in propagating the attributes among the devices in the LAN. The devices in LAN do not directly use GARP; rather it speci es dierent applications to perform required actions, like GVRP, GMPR used for MAC registrations in LAN. As like GARP, GVRP also de nes both GVRP application address and GVRP attribute types.
GVRP application address. The GVRP aware switch starts to transmit the GVRP exchange messages with the destination address as 0x01-80-C2-00- 00-21. This is the default destination address of a GVRP packet that is read 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 total list of attributes consisting of VLAN ID's to be advertised. Each attribute has three elds: attribute length, attribute event and attribute value. The attribute value eld contains the VID which is learned by the receiving switch depending upon the event eld. An event eld describes the action to be performed by the end/intermediate switches on the attribute val- ues. The action commands in the attribute event eld are: LEAVE_ALL,
Chapter 2. Background 12
Figure 2.3: GARP Architecture [11]
JOIN_EMPTY, and JOIN_IN. A pictorial illustration of GVRP protocol format 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 is asked to be created in the end/intermediate switch.
JOIN_IN: This event is triggered when a known VLAN is asked to be created in the end/intermediate switch, i.e., if the end/intermediate switch already has the VLAN con gured and if it receives that same VLAN ID from broadcast, then JOIN_IN is triggered.
Chapter 2. Background 13
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, like a tree like structure. This type of architecture is inappropriate/not very well suited for the present dynamic behavior of computing. The following are some reasons 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
Chapter 2. Background 14 applications, access dierent databases and servers for information, creating an east-west machine-to-machine tra c in prior to the response to the end host/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 devices into the network is creating pressure on the IT sector for accommodating the required resources for the end users at the same time providing security for 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 growth of 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 market demands 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. Dynamic behavior of the network needs an administrator (human) control. According to a survey [4], 80% of the disruption in the network connectivity is due to human errors. Any change in the network infrastructure needs immediate administration on several components in the network.
Less exible networks. The increase in demands on ne-grained network- ing aects the infrastructure of network i.e., the increase in the growth of the network, number of devices in the network. This situation resulted in a more dynamic behavior of the data tra c patterns in network, making them unpredictable. To cope with such behavior, IT management has em- ployed many parallel processing algorithms and multi-processing data sets into its blend. For this massive implementation, IT have empower many technicians to provide high-performance in data transfer and to maintain connectivity among hundreds of devices and servers. Such high scale manual con guration is merely laborious and highly error-prone.
Vendor speci cations. IT consortiums are seeking to implement new services to cope with accelerated change in the behavior of the network, but the vendor dependencies on the products are eecting the deployment of new services. This restriction on the deployment limits the operators to con ned product cycles.
Chapter 2. Background 15 These limitations mentioned above had brought the development of tra- ditional network to halt. Therefore, this resulted in demanding for a new network architecture, thus in response, consortiums developed Software De ned Network- ing (SDN) [9] architecture converting the above mentioned limitations into it's features. The architecture (SDN) and its associated standards are explained in section 2.2.
2.3 OpenFlow
The idea for implementing/designing the OpenFlow protocol was taken from 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. These tables are dierent for each vendor. OpenFlow has taken advantage of this com- mon property of maintaining ows giving an open exibility to program ows in dierent network devices. By taking in such programming ability, the network can be partitioned into individual streams.
An OpenFlow switch [7][10][11] completely depends upon datapath which consists of Flow Table and action. The actions associated with each ow entry of the switch can be expandable with extreme caution achieving greater exibility and higher-performance. The components of an OpenFlow switch are described in 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 respective actions 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 to match with the receiving ow packets and applies the action associated
Chapter 2. Background 16 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 an action accordingly. The header eld is contained with 10-tuple as described in the following Figure 2.6. These ten header elds are used for matching against the receiving ows.
Figure 2.6: 10-Tuple
ii. Counters This eld keeps track of statistical data like, number of received packets for that particular matched entry, bytes for each ow and duration of each ow.
iii. Instruction sets These sets are nothing but actions speci ed for each entry ow. These actions provide information on how to administer the packets of that ow. The basic actions that all dedicated OpenFlow switch support are:
i. Forward packets.
ii. Drop the packets (can be used for security purposes like, avoiding DoS attack).
iii. Sending the new ows to the controller for actions.
b) Secure Channel The secure connection between switch and controller using TLS (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 by switch. 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 dierent types of port abstractions, supported by OpenFlow like Standard 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 by OpenFlow protocol.
Chapter 2. Background 17
Figure 2.7: Procedural steps carried out by OpenFlow [7][12]
From the Figure 2.7 [10][14], the working of OpenFlow can be depicted as: the moment switch receives a new ow, the rst packet of the ow is sent to the controller. The controller parses the header of the packet and is matched against the ow-tables in the switch. If multiple matches are found, the actions are considered according to the prioritization of the tables in the switch. When a match is found, the action associated with the matched ow entry is performed and the counters are updated. If a switch contains multiple ow-tables, then matching is performed by pipeline processing which is illustrated in the following Figure 2.8 [7][10].
If none of the ow entries in the ow table of the switch matchs, then the switch decides it to be a new ow and noti es it to the controller using a PACKET_IN message. The controller receiving the PACKET_IN message, analyses the header of the packet and decides the appropriate action for the ow and alters the ow table accordingly, using a PACKET_MOD message. The reply to PACKET_IN message is responded by PACKET_OUT message. If there are multiple OpenFlow supported switches in the network connected to a single controller, then the controller sets a path for the ow by sending PACKET_MOD messages 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 using OpenFlow protocol is classi ed into three type [10][11]:
Chapter 2. Background 18
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 controller doesn't expect for any reply, i.e., the switch doesn't necessarily need to respond to every such messages.
b) Asynchronous Communication It is a switch triggered message to the controller without its request. Asynchronous messages from the switch are sent 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. The asynchronous 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 the devices start to transmit messages to check the liveliness of the secure link between the switch and controller. There are a total of three symmetric messages exchanged by the two devices:
Hello. When an OpenFlow instance is enabled on the switch, hello messages 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 echo reply from the other end. This is performed periodically by both the devices only to verify whether the secure link is alive or not.
Experimenter. This message is triggered by the switch providing them
Chapter 2. Background 19 a standard way to oer additional functionality within its message type space 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 written in machine-level language and hard coded into each device manually which had no 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 requires the knowledge on topology of the network and position of each user. For more complex events, require more knowledge on the network. Such technique of hard coded machine-level con gurations is re ected on an enterprise network is like con 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 network by establishing an operating system for network. Alone the operating system doesn't manage the entire network underneath, it just provides an interface to program the network. Whereas the applications installed on top of this operating system 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 to be 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 operating system for network called NOX. NOX is a programmatic interface designed to achieve 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 controller see [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 to illustrate all the features of OpenFlow and its aects in the implementation of programmatic network architectures providing a pragmatic compromise for the researchers to run the experiments. Supporting to this, the speci cations of an OpenFlow 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
Chapter 2. Background 20 the performance in terms of scalability and adaptability of OpenFlow in the cur- rent network. This study was based on measuring switching time of OpenFlow hardware, re ecting the forwarding speed and blocking probability of OpenFlow switch attached to an OpenFlow controller. The authors concluded by explaining the time taken by the controller to respond to the data plane requests with respect to 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 with high forwarding speeds. The authors of [17] focused their research completely on data plane performance of OpenFlow, i.e., the switching performance. This study was performed using OpenFlow implementations on Linux based PC's and com- paring the data path switching performance against layer-2 Ethernet switching and layer-3 IP routing. The conclusions given were based on forwarding through- put and packet latency modeled in each scenario. The observations were in favor of OpenFlow switch in handling multiple ow tables when compared to layer-2 Ethernet switching. The statistical analysis re ected a surprising performance drop of 30% against OpenFlow.
The authors of [18] provided an in depth view on the concepts of VLAN and its components by elaborating the bene ts of network virtualization through implementation of VLAN and also, IEEE 802.1Q trunking protocol is illustrated. 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 dynamic end-host behaviors. This publication is based on VLAN technology incorporating GVRP registrations, enabling dynamic creation of VLANs in the network. This study involves in explaining the behavior of VLANs in wireless end-host roaming in the network with dynamic exhibition of GVRP properties.
Chapter 3:
METHODOLOGY
Chapter 3
Methodology
This chapter involves in explaining the methodology used for evaluating the performance of the selected protocols.
3.1 Experiment Setup
In this stage of research, a laboratory testbed is setup to evaluate the network level performance of OpenFlow and dVLAN, focusing on the aects of each protocol impose in link connection between the end-hosts to their respective connected switches.
A two-tier network architecture is considered for this experimentation, which include two dierent vendor switches and three end-hosts. The reason be- hind choosing two-tier architecture is to represent centralized networking. The Figures 3.1 and 3.4 illustrates the experiment set involved in the testbed. The source switch is the switch under administrator controller where all the con g- urations are done which are re ected in the underneath network devices, hence representing a centralized architecture. For both the cases, the same architecture is 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 system with one running a desktop version and the other running a server version while the other host runs OSX 10.10.4. The switches used are a HP ProCurve 2920 and a NetGear GSM7224. Two dierent vendor switches are used in this testbed so 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 hardware speci 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 two hosts connected to each switch. The source switch is the one which advertises the VLAN information to beneath switch re ecting the registration of VLAN in
22
Chapter 3. Methodology 23
Hardware Speci cations Switch 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 cations Host Speci cations
Host-1 Host-2 Host-3
OS Ubuntu-14.04
LTS-Desktop Ubuntu-14.04
LTS- 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 the switches, the host communicates with the connected switch and creates a path way to the source switch of that particular VLAN. On the other hand, if there is another 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 host to host making those two hosts belonging to a single VLAN.
This process is implemented with the above mentioned hardware that is explained 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-mode is enabled in the switch, resulting in making the device a GVRP-aware switch. By this step, the source switch will start to advertise GVRP packets through all of its ports into the network, with the destination MAC address as 01:80:C2:00:00:21.
In the end-switch, GVRP admin-mode is enabled, making the end-switch GVRP enabled device. As soon as the end-switch is connected to the source switch, the advertisement packets broadcasted by the source switch is re-
Chapter 3. Methodology 24
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 the switches. 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 to the network. For example, the VLANs that are con gured in one switch is propagated 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 the desired VLAN/s and once they are connected to any one of the ports of the switch (source switch), the host and switch will start to communicate with each 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 switch a tagged member of that VLAN.
By the end of all these processes, there is a VLAN established in the network
Chapter 3. Methodology 25
Figure 3.2: GVRP exchange between switches
connecting the two end-hosts (host1 and host2) in a LAN network. Figure 3.3 describes the result of GVRP.
If the position of the hosts are changed, i.e., if the hosts are reconnected into dierent ports or, if there is another switch that is inserted in between the switches, the above explained process is performed and a VLAN of desired ID 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 gured in it, the VLANs should be active in that switch, i.e., at least one port on the switch should be a member of the VLAN and must detect a linkbeat.
Chapter 3. Methodology 26 Note 2:The GVRP-learned VLANs function as tagged VLANs. If a switch advertises an untagged VLAN to another switch, then the learning switch will create a VLAN in it as a tagged VLAN on the port on which the switch learned the VLAN. In this case, communication between the two switches is lost because of the untagged VLAN which can't be used as an uplink to the other switch. So, to avoid such risks, tagged VLANs are created in the source switch.
Note 3: A tagged VLAN port accepts only packets that have VLAN tags 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 the member of that VLAN. This can be achieved by creating a virtual interface in a physical NIC of the host, naming it with the desired VLAN ID and sending packets 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 secure channel. This secure channel uses transport level security (TLS). There are many more OpenFlow controller softwares like, POX which is one of the powerful con- troller used in SDN architecture. NOX is selected as the OpenFlow controller for this 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 OpenFlow implementation. The following setup consists of an OpenFlow capable switch that is connected to an external controller, an end switch and two end-hosts. This controller 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 to an end host (host2) via a manageable switch (end switch). In this case, the extra switch 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 the host1 tries to reach host2, then the OpenFlow machenism comes into picture. As the OpenFlow switch receives a request, the packet is forwarded to the controller and in response, the controller sends the commands to the switch accordingly.
This makes the switch to forward the packet as commanded, establishing a link connectivity between the end-hosts. This process is implemented with the above mentioned hardware that is explained in the following steps:
The initial steps of implementation include checking whether the OpenFlow switch software is up to date, i.e., the rmware support of OpenFlow.
Chapter 3. Methodology 27
After all the software requirements are set, the switch is now capable of implementing OpenFlow instances. An instance is nothing but a con gura- tion set of parameters con gured into an OpenFlow switch. There can be n 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 controlled by OpenFlow protocol and a VLAN for controller. There are two OpenFlow modes a switch can be con gured to:
Virtualization Mode: In this mode of operation, VLANs con gured on the switch can be members of OpenFlow instances or can be non- OpenFlow VLANs. Each instance is independent of itself and has an own controller. An instance should have a VLAN as member associated with it. The following Figure 3.5 gives a clear cut idea of virtualization mode.
Aggregation mode: In this operative mode, all the VLANs that are con gured in the switch are members of OpenFlow instance exclud- ing the management VLAN and the controller VLAN. The following Figure 3.6 gives a sketch on aggregation mode.
In this research, virtualization mode is opted because there are only two host systems under test which can be controlled through vitualization moded.
Chapter 3. Methodology 28
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 communication are created in the switch.
Chapter 3. Methodology 29
An OpenFlow instance is created by making the VLAN (created for the sake of OpenFlow) a member of that instance and attaching a controller to that instance.
A controller ID is created which is accompanied with the controller network parameters like, controller IP address, controller VLAN ID, and controller port number.
After all the con gurations are made (set of commands for con guring an OpenFlow instance is detailed in Appendix, Section B), the OpenFlow in- stance is enabled on the switch making the switch a dumb forwarding device where the brain being the controller (NOX, in our case).
When host1 wants to communicate with host2, the switch will forward the packet to the controller using a PACKET_IN message. The response to this message is given to switch by controller using a PACKET_OUT message containing the actions for the switch to perform on such ows. Along with the out message, PACKET_MOD message is also sent to the switch, giving instructions to the switch to add a ow entry into its ow table. The Figure 3.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 between the hosts by OpenFlow protocol.
3.2 Performance Metric Measurement
The metric protocol setup time is calculated by capturing the required traces using tshark. The path followed by the packets (i.e., the packet ow), on the initiation 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. The following Figure 3.8 explains the location at which tshark is used to capture traces.
Chapter 3. Methodology 30
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 the end-switch is considered, relative to the ARP reply obtained from host1 indicating the establishment of link. This relative time gives the total protocol setup time for dynamic VLAN establishment using GVRP.
To calculate this metric, packets at link layer are captured. For such a capture, a set of testbed con gurations are performed and the capture is executed as 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 inter packet delay of 1ms from host2 with target IP address of host1.
Now, GVRP is enabled on host2 resulting in the injection of GVRP packet into end-switch.
Chapter 3. Methodology 31
The sequence of ARP requests with target IP of host1 are sent, till an ARP reply 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 to eliminate any randomness present in the capture (a perl script is written to automate the iterations and parse the values).
In the step of parsing the trace les, the capture times of rst GVRP packet going from host2 and the rst ARP reply from host1 are traced and the dierence of these times is calculated, which gives the protocol setup time of 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 the Figure 3.9 we can depict that, when a link is established, the ARP request from host2 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 VLAN member port in the end-switch, in this case, it is the 802.1q VLAN trunk port created by GVRP. Packet reaches source switch and forwards it to the VLAN tagged port on the switch where host1 is connected. The ARP reply from host1 follows the same path to host2 through the switches indicating successful VLAN establishment.
Figure 3.9: Sequence diagram of dVLAN
Chapter 3. Methodology 32 The Figure 3.10 illustrates the packets involved in one run. It displays a bunch of ARP requests with inter packet delay of 1ms. The ARP inter packet delay is manipulated so as to reduce the time gap that is introduced between the point of time, when VLAN is created and the next ARP request going into the network. As, the default time for ARP is 1 second, the GVRP injection could be at any time between two ARP requests, which results in the addition of extra time for the next ARP request to go into the network and get the reply. This randomness can be avoided by sending multiple ARP requests with much less inter packet delay and considering the rst ARP reply received from host1. The average 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 request from host2 to host1 and the following subsequent ARP reply from host1 to host2 respectively. Calculating the dierence between request and response ARPs, gives the 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.
Chapter 3. Methodology 33
The instance on OpenFlow switch is enabled and the NOX controller is started.
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 are captured at that interface of host2.
The relative time dierence between the last ARP request going out from host2 and the rst ARP reply coming to host2 gives the protocol setup time.
Now, tshark is stopped and traces are witten into a le, that is parsed for the required packets (as explained in above section 3.2.1). This is done using 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 end switch, which is forwarded to OpenFlow switch through trunk port managed by default_VLAN. Now, the new ow is detected and switch communicates with controller for the necessary actions. Then it is forwarded to the host1 which sends an ARP reply to host2 following the same path. The reply packet received at host2 indicates the successful establishment of link between host1 and host2.
Figure 3.11: Sequence diagram of OpenFlow
Chapter 3. Methodology 34 The Figure 3.12 represents the time line diagram ofcommunication be- tween OpenFlow and controller. From the experimental observations, it is noted that, the time taken for the openFlow-controller communication, from request to reply, impose 4 extra packets for receiving and sending commands to con- troller. The average time mentioned, is obtained from the experiment iterations performed.
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 randomness that occur between the ARP request and GVRP packet injection.
Dynamic
VLAN Average
(ms) Min (ms) Max (ms) Standard
Deviation Coe cient of Variance Protocol
Setup 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 the VLANs at necessary switch ports to establish the connectivity between the hosts is 39 ms. We can observe that, an almost consistant pattern is followed by dVLAN in 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, a set of 900 iterations are plotted to show the pattern. As described in section 3.2.1, a perl script is used to iterate the experiment a 1000 times and parsing the statistics. There could be a possibility were, the tshark is triggered after the tra c is initiated, resulting in missing the capture of packets. Due to this, that iteration would result in no value. This can be the reason why out of 1000, 900 samples were obtained. By seeing at this plot, we can say that the setup times are 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 randomness which could occur between the ARP request and reply packets. The following table lists the statistical values obtained after performing the experiment for OpenFlow.
OpenFlow Average
(ms) Min (ms) Max (ms) Standard
Deviation Coe cient of Variance Protocol
Setup 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 of variance 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 is 10ms 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 to 10ms.
From both the cases, we can observe that the variation between the iterations is very less, i.e., 2% for dVLAN and 7% for OpenFlow. This consistency in the obtained results can be due to no application of any sort of load in the network.
Chapter 4. Experiment Results and Analysis 38
Figure 4.2: OpenFlow Setup Time (iterations plot)
4.3 Theoretical Model
From the methodology described above, it is clearly understood that the main focus of this study is on the protocol mechanism, but not on the hardware used. To give the reader an information regarding the hardware, switches and hosts in the testbed are equipped with latest processors with high processing speeds and latest rmware's.
A question would pop in the readers mind, that, does this have any hardware dependency. The purpose here is to compare two protocols, which is done through performance evaluation on a desired hardware. Upon passing of several years, there can be developments in the processing power of hardware which can reduce the time obtained when compared to this study. Even though, the individual protocol setup time may reduce, but the relative dierence between the times of the two protocols would be same.
From this discussion, a theoretical model (for each protocol) can be derived, which gives the setup time for that respective protocol upon taking necessary 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.
Chapter 4. Experiment Results and Analysis 39
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 the network. The second and third parameters de ne the physical link speed used to 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 in the 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 protocol setup 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 the network. The second and third parameters de ne the physical link speed used to connect devices. The fourth parameter can be split into two sub-parameterts:
distance between switches, distance between switch and hosts. Last but not the least, controller placement de nes the distance between OpenFlow switch and controller.
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 be extended 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 on the tra c patterns is carried out by using ARP MAC sni ng technology. A prede ned hardware is used for both the implementations, so as to avoid any hardware 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 when compared to OpenFlow. This re ects that OpenFlow is much faster in establish- ing connectivity against dVLAN. The variations existed in dVLAN is due to the dierent 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 perfectly con gured host is only capable of using the services provided by GVRP. Any miscon gurations done in hosts results is connectivity breakage. The chances of having such dearth in host con gurations is because, the network administrator is 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 are not required, the task of end-host is to just get connected to the network, where all the work is done by OpenFlow. Coming to critiques of OpenFlow, chain of OpenFLow switches can eect in two perspectivies: 1) New Flow: When ever a new ow is received by the OpenFLow switch, it takes 8 ms to register the ow and 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 other end.
In a wide-spread approach, consortiums which have time dependencies can 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 time but like to reduce the complexity in network architecture, can choose dVLAN for its easy implementation.
41
Chapter 5. Conclusions 42
Linking to Research Questions:
RQ 1. How does OpenFlow protocol aect the link establishment be- tween end-hosts in a two-tier network?
Ans: A link between the two hosts is established by the switch-controller communication done using OpenFlow. Table 4.2 gives a statistical view on the performance of OpenFlow. The experimental analyses projects the pat- terns of tra c followed by OpenFlow in establishing the connection. These patterns illustrates the latency introduced by OpenFlow in dealing with new 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 the link 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 be the eective protocol in the terms of protocol setup time.
RQ 2. How does dVLAN (GVRP protocol) aect the link establish- ment between end-hosts in a two-tier network?
Ans: A link between the two hosts is established by the GVRP exchange exhibited by the network devices resulting in dynamic VLAN creation and VLAN 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 ects the poor performance of dVLAN which takes an average time of 39 ms to establish 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 eective metric to evaluate the performance of each protocol in establishing connectivity. This is choosen as the vital metric in this study because the focus of this study is entirely based only on the time taken by each protocol in establishing connectivity, where calculating this metric would help in achieving this time along with having a better comparission to recommend which is eective.
