OpenFlow – Encouraging Experiments in Campus Networks

Uzair AhmedStudent, National University of Computer & Emerging

Science – FAST,Department of Computer Sciences, Shah Latif Town,

KarachiK122046@nu.edu.pk

Taha AliStudent, National University of Computer & Emerging

Science – FAST,Department of Computer Sciences, Shah Latif Town,

KarachiK122062@nu.edu.pk

Basit JasaniStudent, National University of Computer & Emerging

Science – FAST,Department of Computer Sciences, Shah Latif Town,

KarachiK122080@nu.edu.pk

Faraz Idris KhanAssistant Professor, National University of Computer &

Emerging Science – FAST,Department of Sciences and Humanities, Shah Latif

Town, Karachifaraz.idris@nu.edu.pk

Abstract: This study aims to research openflow, a new advancement in the field of computer networks. It is currently the most commonly deployed Software Defined Networking (SDN) technology. We try to emphsis the fact to networks vendors that OpenFlow is a sensible compromise, and they should include OpenFlow to their switch products for deployment in campus as it enables experiments for researchers on combination of switches and routers in a well-organized way.

Keywords— openflow; deployed Software Defined Networking; switches; routers;

I. INTRODUCTION

This research proposes OpenFlow: a mode for researchers to run observational protocols in the networks they use in routine. OpenFlow is established on an Ethernet switch, with an internal flow-table, and a standardized interface to increase and decrease flow entries. Our objective is to advocate networking vendors to include OpenFlow to their switch products for deployment in college campus backbones.

II. LITERATURE REVIEW (PROBLEM BACKGROUND.)

After introducing standardized OpenFlow descriptions, Kazuya Suzuki inspected and surveyed research

on enforcing OpenFlow to data center networks, network security and carrier networks. Though OpenFlow is a new technology for commanding and controlling networks and has lots of classifiable features, mainstream technologies can do nearly all of what OpenFlow can do. Consequently, it is not worthy to merely substitute pervious established networks with OpenFlow networks. It is significant for researchers to have outlook as to how OpenFlow can be applied to figure out problems. He summed up these overviews and expects that this report or paper will be useful in the near future. [1]

Nick McKeown expect that a modern generation of control software comes forth, permitting researchers to recycle experiments and controllers, and create on the work of others. And with the passage of time, we expect that the zones of OpenFlow networks at different campus will be co-ordinated by overlay networks, and possibly by new OpenFlow networks performing in the backbone networks that link up campuses to each other. [2]

Hari Balakrishnan thinks that OpenFlow is a realistic compromise that permits researchers to do investigation on heterogeneous routers and switches in a consistent manner, no need for vendors to disclose the internal mechanism of their products. [4]

Some of the fundamental ideas of SDN are the beginning of active programmability in forwarding devices by

open southbound interfaces, the uncoupling of the information and control plane, and the world-wide belief of the network by logical centralization of the “network brain”. While information plane components became dumb, but programmable and extremely efficient packet forwarding devices, the control plane components are now demonstrated by an individual entity, the network operating system or controller. [3]

III. METHODOLOGY (SOLUTION)

A. The need for programmable networks

Networks have transform part of the vital infrastructure of our institutions. This prosperity has been both a curse and a blessing for networking researchers; their activity is more to the point, but their attempt of making an impression is more distant. The decrease in real-world impact of any devoted network creation is because the tremendous installed base of protocols and equipment, and the hesitation to experiment with production traffic, which have produced an extremely high roadblock to fresh and innovative ideas.

A couple of these software platforms already coexist, but don’t have the functioning we need. The easiest case is a PC with many network interfaces and an operating system. The trouble is the functioning or performance: A PC can neither affirm the amount of ports involved for a campus wiring closet (a fanout of 100+ ports is needed per box), nor the packet-processing performance.

B. Dedicated OpenFlow switches

The fundamental idea is not complex: we utilize the concept that almost all modern Ethernet routers and switches constitute flow-tables that run at line-rate to enforce firewalls, NAT, QoS etc. Although all vendors’ flow-table is not similar, we’ve distinguished concerning mutual set of functions that run in lots of routers and switches. OpenFlow maximize this mutual set of functions. A committed OpenFlow Switch is a dumb data path component that forwards packets between ports, as outlined by a remote control process. Figure 1 demonstrates an instance of an OpenFlow Switch. All flow-entry has a straight forward action linked with it; the 3 basic ones are: 1. To a given port (or ports), forward this flow’s packets .2. To a given controller, Encapsulate this flow’s packets. 3. Cut down this flow’s packets.

Figure 1

Some commercial switches, routers and access points will be enhanced with the OpenFlow feature by adding the Flow Table, Secure Channel and OpenFlow Protocol Typically, the Flow Table will again utilize existing hardware, such as a TCAM; the Secure Channel and Protocol will be ported to run on the switch’s operating system. Our goal is to enable experiments to take place in an existing production network alongside regular traffic and applications.

C. Controllers

A controller adds and removes entries of the flow from the table known as Flow Table on behalf of experiments. For instance, a non-dynamic controller might be a straight forward program running on a machine to statically support flows to interlink a set of test machine for the time period of an experiment. If considered this way, OpenFlow is a principle of VLANs.

Using OpenFlow

There are established questions to call for about the performance, scalability and reliability of a controller that non-statically increases and decreases flows as an experiment advances: The question is can such a centralized controller be quick enough to compute freshly entered flows and program the Flow Switches? Exploratory results proposed that an Ethane controller based on a low-cost machine could compute over 10,000 newly added flows per second. This is adequate for a big-sized campus.

Examples

There are limitless set of experiments as is the case with any experimental platform — majority of the experiments in OpenFlow networks are yet to be discovered. For now, as an illustration, we exhibits few examples of how OpenFlow enabled networks allow experimentation with new network applications and architectures.

1) Network Management and Access Control

2) VLANs

3) Mobile wireless VOIP clients

4) A non-IP network

5) Implementing an OpenFlow Switch on the NetFPGA platform

6) Processing packets rather than flows

The way to process packets is to route them to a programmable switch that does packet processing. An advantage will be processing of packets at line-rate that is definable by user; Figure 2 shows an example of how this could be done, in it operation of the OpenFlow-enabled switch is basicaly as a patch-panel to enable the packets to get to the router.

Figure 2

D. Deploying OpenFlow switches

We foresee and exemplary opportunity for network equipment vendors to sell OpenFlow-enabled switches to research community. Each and every building in hundreds of universities and colleges has cabinets containing wiring with Ethernet switches and routers, also a widespread of wireless access points covering the campus. We inquired from several switch and router manufacturers that include OpenFlow feature in their products by making use of Flow Table in existing hardware; this means no need to change hardware. Secure Channel software is being run by these switches on their existing processor.

E. Implementing an OpenFlow Switch on the NetFPGA

platform

Figures: These are measurements obtained from theFAST EE and CS departments. The top graph is the

total number of active flows per second observed on thenetwork over six days, and the bottom graph is

the number of new flows that are seen every secondover the same six days.

Forwarding: We started off by running two test on our NetFPGA Open- Flow switch. First test was to check forwarding rate of the hardware, we ran streams over all four ports of the NetFPGA after inserting entries into the hardware’s flow table. A NetFPGA packet generator was used, one which transmit pre- determined packets at line-rate. To make sure we get the expected packets, a NetFPGA packet capture device cached the output from the OpenFlow switch. In table 1 the forwarding column exhibits that our switch is capable of running at the full line-rate across 64, 512, 1024, and 1518 packet sizes.

New Flow Insertion: Second test was for rate at which new flows can be inserted into the hardware flow table. This was an answer to servel questions as follows: Taking an infinitely fast OpenFlow controller for instance, before getting dropped, at what rate can new flows be coming into the switch? NetFPGA switch was connected to an external host which was generating new flows continously and the test was run. Inorder for OpenFlow controller & local OpenFlow switch manager to communicate through memory a simple controller implementing a static Ethernet switch 3 was run on the same machine. Rate at which new flows were received was calculated and also the rate at which new entries were created in the NetFPGA flow table. The summarized results are in the full loop column of table below.

Packet Size (Kbytes)

Forwarding (Kbps)

Time (sec)

Full Loop (flows/s)

64x10-3 1000000 5 310K

512x10-3 1000000 3 123K

1024x10-3 1000000 2 58K

1518x10-3 1000000 4 72K

IV. CONCLUSION

Belief has been established that OpenFlow is a sensible compromise, it enables experiments for researchers on mixture of switches and routers in an organized way, there is no need for vendors to reveal inner working of their products and for researchers to prepare control software that is vendor specific. We are hopeful that OpenFlow will catch-on in other universities if we succeed in deploying OpenFlow networks in our campuses. We await an era where new control software emerges, enabling researchers to make use of controllers and experiments again and again, and build upon the efforts of others.

V. REFERENCES

[1] K. S. Y. Y. Y. H. Kazuya Suzuki, "A survey on OpenFlow technologies," IEICE TRANS. COMMUN, Vols. VOL

E97-B, no. NO.2, 2014.

[2] N. McKeown, A. Tom and B. Hari, "OpenFlow: Enabling Innovation in Campus Networks," 2008.

[3] D. Kreutz, F. M. V. Ramos and P. Verissimo, "Software-Defined Networking: A Comprehensive Survey," no. 2.01,

p. 61, 2014.

[4] J. Halliday, S. Shrivastava and S. Wheater, "Flexible workflow management in the OpenFlow system," Enterprise Distributed Object Computing Conference, pp. 82-92, 2001.

[5] Bianco, Birke and Palacin, "OpenFlow Switching: Data Plane Performance," Communications (ICC), 2010 IEEE International Conference, pp. 1-5, 2010.

[6] J. Naous, D. Erickson and G. Appenzeller, "Implementing an OpenFlow switch on the NetFPGA platform," Symposium on Architectures for Networking and Communications Systems, pp. 1-9, 2008.