network innovation through openflow and sdn - it · pdf filevii contents preface xi editor xv...

Network Innovationthrough OpenFlow

and SDN

Principles and Design

Edited by

FEI HU

CRC PressTaylor & Francis Group6000 Broken Sound Parkway NW, Suite 300Boca Raton, FL 33487-2742

© 2014 by Taylor & Francis Group, LLCCRC Press is an imprint of Taylor & Francis Group, an Informa business

No claim to original U.S. Government works

Printed on acid-free paperVersion Date: 20131227

International Standard Book Number-13: 978-1-4665-7209-6 (Hardback)

This book contains information obtained from authentic and highly regarded sources. Reasonable efforts have been made to publish reliable data and information, but the author and publisher cannot assume responsibility for the validity of all materials or the consequences of their use. The authors and publishers have attempted to trace the copyright holders of all material reproduced in this publication and apologize to copyright holders if permission to publish in this form has not been obtained. If any copyright material has not been acknowledged please write and let us know so we may rectify in any future reprint.

Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information stor-age or retrieval system, without written permission from the publishers.

For permission to photocopy or use material electronically from this work, please access www.copy-right.com (http://www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400. CCC is a not-for-profit organization that pro-vides licenses and registration for a variety of users. For organizations that have been granted a pho-tocopy license by the CCC, a separate system of payment has been arranged.

Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identification and explanation without intent to infringe.

Visit the Taylor & Francis Web site athttp://www.taylorandfrancis.com

and the CRC Press Web site athttp://www.crcpress.com

vii

Contents

Preface xi

editor xv

contributors xvii

Part i fundamentals

chaPter 1 sdn/oPenflow: concePts and aPPlications 3Ashley Ger r it y A nd Fei h u

chaPter 2 an oPenflow network design cycle 17Pedro A. A r A ndA Gu t iér r ez A nd dieGo r . loPez

Part ii design

chaPter 3 iP source address Validation solution with oPenflow extension and oPenrouter 41J u n Bi

chaPter 4 language and Programming in sdn/oPenflow 73M u h A M M A d FA rooq A nd Fei h u

viii Contents

chaPter 5 control and management software for sdns: concePtual models and Practical View 87nAtA li A CAstro Fer nA ndes A nd lu iz Cl Au dio sCh A r A M AGA lh ã es

chaPter 6 controller architecture and Performance in software-defined networks 121t inG zh A nG A nd Fei h u

chaPter 7 mobile aPPlications on global clouds using oPenflow and software-defined networking 133su Bh A rthi PAu l , r AJ JA in, JAy i y er , A nd dAv e or A n

chaPter 8 hybrid networking toward a software-defined era 153Chr ist i A n estev e rothenBerG, A ll A n v idA l , M A rCos roGer io sA lvA dor , CA r los n. A . Cor r êA, sidney luCenA, Fer nA ndo FA r i As, João sA lvAt t i, eduA r do Cerqu eir A , A nd A ntônio A BeléM

chaPter 9 network Virtualization for oPenflow 199ru i M A A nd Fei h u

Part iii Quality of serVice

chaPter 10 multimedia oVer oPenflow/sdn 219ColBy diCk er son, Fei h u, A nd su nil ku M A r

chaPter 11 Qos issues in oPenflow/sdn 235ku heli l . h A ldA r A nd dh A r M A P. AGr AwA l

chaPter 12 Qos-oriented design in oPenflow 249X inGA nG F u A nd Fei h u

chaPter 13 Programmable network traffic classification with oPenflow extensions 269sA nPinG li , er iC M ur r Ay, A nd yA n luo

ixContents

Part iV adVanced toPics

chaPter 14 oPenflow/sdn for metro/backbone oPtical networks 305lei li u, honGX i A nG Guo, A nd tA k ehiro tsur itA ni

chaPter 15 oPenflow/sdn and oPtical networks 387ly ndon y. onG

chaPter 16 security issues in sdn/oPenflow 415nAGA r AJ heGde A nd Fei h u

chaPter 17 inVestigation of anycast imPlementation in software-defined networking 435J inGGuo Ge , y u lei w u, y u ePenG e , J u nlinG you, A nd Ch uA n du

index 459

xi

Preface

Software-defined network (SDN)/OpenFlow research and develop-ment have attracted the attention of many researchers and companies. The key idea of an SDN is to split the network forwarding function, performed by the data plane, from the network control function, per-formed by the control plane. This allows a simpler and more flexible network control and management, and also network virtualization. OpenFlow is the main SDN implementation. The network controller communicates with OpenFlow switches using the OpenFlow proto-col through a secure channel. Using this connection, the controller is able to configure the forwarding tables of the switch. The figure (in the right) shows a simple OpenFlow architecture.

OpenFlow-based SDN technologies enable us to address the high-bandwidth, dynamic nature of computer networks; adapt the net-work functions to different business needs easily; and reduce network operations and management complexity significantly. Many large companies (such as Cisco, Microsoft, Google, etc.) have produced OpenFlow-supported products (such as switches).

xii Preface

Channel

Open flow Switch

Controller

OpenFlow Protocol

Flowtable

Group table

Flowtable

Flowtable

Needless to say, SDN/OpenFlow will become one of the most important trends for the future Internet and regional networks. In the future, you do not need to program, configure, or debug each network device individually. Instead, you can just sit in a centralized manage-ment office and customize your network based on the different needs in scientific experiments, business management, home network con-trol, and local community communications. Those centralized control commands can be run in any vendor’s switches and can be executed by a standard networking operating system. Isn’t that awesome?

Features of the Book

Compared with other similar books, this book emphasizes both OpenFlow engineering design and basic principles. This is perhaps the first book that systematically discusses the different design aspects in an SDN/OpenFlow written by experts worldwide. It is different from some similar books that mainly introduce the basic principles. This book covers the entire system architecture, language and pro-gramming issues, switches, multimedia support, quality of service (QoS), network operating system, how to smoothly transfer from

xiiiPreface

conventional networks to SDN/OpenFlow, security, OpenFlow for optical networks, and others.

Targeted Audiences

This book is suitable to the following types of readers:

(1) Industry/engineers: We have provided a detailed SDN/OpenFlow design process. Thus, company engineers could use those principles in their product design.

(2) College students: This book can serve as a textbook or ref-erence book for college courses on advanced networking, especially on OpenFlow. Such courses could be offered in computer science, electrical and computer engineering, infor-mation technology and science, or other departments.

(3) Researchers: Because each chapter is written by top experts, the contents are very useful to researchers (such as graduate students and professors) who are interested in this field.

Book Architecture

This book uses four parts to cover the most important aspects in SDN/OpenFlow. Those four parts include basic concepts, engineer-ing design, QoS, and advanced topics. The following flowchart shows the book organization.

xiv Preface

Chapter 1 - Introduces the basic principle of SDN/openflow and its applications in network systems.Part I. Fundamentals

Chapter 2 - Introduces the entire design process (different nuts and bolts) of a practical openflow/SDN.

Chapter 3 - Explains the engineering design of an openflow router called openrouter, as well as addressing issues.

Part II. Design

Chapter 4 - On the programming language design principle for an openflow's networking operating system.

Chapter 5 - On the control panel software design principle including its model and practical issues.

Chapter 6 - Describes different control panel architectures.

Chapter 7 - Design issues when applying openflow in cloud computing with mobile users.

Chapter 8 - How do we ensure the co-existence of conventional networks and SDN?

Chapter 9 - Visualizing the SDN topology and status.

Chapter 11 - What new issues come up when we want to support quality of service (QoS) in SDN?

Chapter 10 - What are issues if we send multimedia (video, audio, text, etc.) over the SDN?Part III. Quality of Service

Chapter 12 - Compares different solutions in QoS support.

Chapter 13 - Traffic classification in QoS - aware SDN flows.

Chapter 14 - Practical design issues in metroc/backbone parts when using openflow for optical network control. Part IV. Advanced topics

Chapter 15 - Overview of efficient solutions to the integration of SDN with optical networks.

Chapter 17 - Anycasting communications in SDN.

Chapter 16 - What types of network attacks could exist in openflow? How do we overcome them?

Disclaimer

We have tried our best to provide credits to all cited publications in this book. Because of the time limit, this book could have some errors or missing contents. Moreover, we sincerely thank all the authors who have published materials and who directly/indirectly contributed to this book through our citations. If you have questions on the con-tents of this book, please contact the publisher and we will correct the errors and thus improve this book.

xv

Editor

Dr. Fei Hu is an associate professor in the Department of Electrical and Computer Engineering at the University of Alabama (main campus), Tuscaloosa, Alabama. He obtained his PhD at Tongji University (Shanghai, People’s Republic of China) in the field of signal processing (in 1999) and at Clarkson University (New

York) in the field of electrical and computer engineering (in 2002). He has published more than 150 journal/conference articles and book chapters.

Dr. Hu’s research has been supported by the U.S. National Science Foundation (NSF), Department of Defense (DoD), Cisco, Sprint, and other sources. His research expertise can be summarized as 3S: Security, Signals, Sensors. (1) Security: This is about how to overcome different cyber attacks in a complex wireless or wired network. Recently, he focused on cyberphysical system security and medical security issues. (2) Signals: This mainly refers to intelligent signal processing, that is, using machine learning algorithms to process sensing signals in a smart way to extract patterns (i.e., achieve pattern recognition). (3) Sensors: This includes microsensor design and wireless sensor networking issues.

3

1SDN/OpeNFlOw: CONCeptS

aND appliCatiONS

A s h l e y G e r r i t y A n d F e i h u

introduction

The Internet has become an important part of everyday life. From searching via Google to buying from Amazon to keeping up with friends on Facebook, it is a part of people’s daily lives. Google has even become prolific enough to warrant becoming a dictionary term. Behind each of these multibillion dollar companies are networks that have to adapt to ever-changing needs. Because the Internet becomes more invaluable than ever, it is important for it to be more accessible and easier to maintain.

The networks, which make up the backbone of the Internet, need to adapt to changes, without being hugely labor intensive in hardware or software changes. By updating switches so that the data plane and the control plane can be separated, a centralized controller can cre-ate more optimized routes to appropriately forward traffic. These for-warding tables can use rule input to the controller to optimize routing and make networks more efficient.

Contents

Introduction 3SDN Application 1: Internet Research 4SDN Application 2: Rural Connectivity 6SDN Application 3: Updating Networks by Changing Silicon 8SDN Application 4: Updating Data Center Networks 8SDN Application 5: Cloud Data Scalability 10SDN Application 6: Mobile Application Offloading 11SDN Application 7: Mobile Virtual Machines 12Discussion 13Conclusion 14References 14

4 Ashley Gerrity And Fei hu

With new protocols, such as OpenFlow, which is becoming more standard in the industry, software-defined network (SDN) is becom-ing easier to implement. SDN decouples the control plane from the data plane, thus allowing switches to compartmentalize their two main functions. The control plane generates the routing table, whereas the data plane, using the control plane tables, determines where the packets should be sent to [1]. This separation allows the network to be abstracted further, which simplifies networking analysis. Many companies use OpenFlow protocols within their data center networks to simplify operations. OpenFlow and SDN allow data centers and researchers to innovate their networks with new ways because it is easier to abstract the network.

sdn Application 1: internet research

The Internet was originally built for research. As such, during its ori-gin, its architects never conceived of the vast network that it has now become. Security and mobility were not considered during its forma-tion because computers were not mobile, and researchers wanted an open environment for ideas to spread. With the ever-increasing user base, the Internet is not as idyllic as when it was originally envisioned. Most of its main concepts have not changed much since its found-ing. There are ways to make it better and allow it to work with future hardware developments that will be developed according to Moore’s law. As technology evolves, the Internet is not able to meet the new requirements as well as it could if it had been designed to do so from the start [2].

Updating the Internet brings many challenges because it is con-stantly being used; it is difficult to test new ideas and strategies to solve the problems found in an existing network. SDN technologies provide a means of testing ideas for a future Internet without chang-ing the current network. In Ref. [2], it is pointed out that SDN “allows new networking protocols to be defined and readily experimented in real conditions over production networks.” Because SDN allows control and data traffic to be separated with an OpenFlow switch, it is easier to separate the hardware from the software. This separa-tion allows experimenting with new addressing schemes so that new Internet architecture schemes can be tested.

5sdn/OpenFlOw: COnCepts And AppliCAtiOns

Generally, it is difficult to experiment with new types of networks. Because new types of networks often use different addressing schemes and include other nonstandard aspects, it is difficult to incorporate these changes into existing networks. OpenFlow allows routers, switches, and access points from many different companies to use the separation of the control and data planes. The devices forward data packets that were received based on defined rules from the controller. If the devices do not have a rule for the data packet that has arrived, the devices forward the packet to the controller for review. The con-troller determines what to do with the packet and, if necessary, sends a new rule to the device so that it can handle future data packets in the same manner.

OpenFlow has gone through much iteration, and it is currently on version 1.3; however, only version 1.0 is available for the hardware and the software. OpenFlow uses both hardware and software switches. Based on the headers in these fields, the controller can decide on what to do with the packet. The second and subsequent versions of OpenFlow changed the match structures so that the number and bit count of each header field could be specified. Thus, it would be easier to implement new protocols. A special controller is used to separate control bits from data bits, which allows the network infrastructure to be shared more easily [2]. A server is often used for the controller portion of OpenFlow systems.

Currently, there are several projects that use OpenFlow, which includes Europe and Brazil. In Europe, eight islands are currently inter-connected using OpenFlow, whereas in Brazil, there are plans to create a network that will work with that in Europe to create a more wide-spread testbed. The project in Brazil is particularly important because replacing the Internet is a global endeavor, and a network that will only work with landmasses clustered together is not a viable solution [2].

Several other projects are currently being developed, including MobilityFirst, eXpresssive Internet Architecture, content centric inter-networking architecture (CONET), and Entity Title Architecture. MobilityFirst determined mobility as the most important goal. It uses a globally unique identifier (GUID) mapped to a network address and a generalized storage-aware routing to handle data transfer at different quality links. Basically, if a link is good, then it immediately sends; oth-erwise, data are stored until it can be sent out. eXpressive uses a directed


acyclic graph addressing scheme. This architecture is in a prototype stage using Linux, and it plans to move toward an OpenFlow-based approach. CONET, as the name suggests, is a content-centric approach. It uses two approaches: one of a clean slate packet and another that uses a traditional IPv4 or IPv6 packet. In this approach, an end node requests content, and the request is forwarded along until it reaches a node with the content in its cache or until it reaches a serving node for the content. The content is then taken in reverse back to the original node. Finally, entity title architecture uses an open form of communication to make the physical layer as efficient as possible. It is similar to user datagram protocol (UDP), where delivery, ordering, and other guarantees are only made if required. For example, if secrecy is required, then the means to set that up are provided, but extra steps have to be set up to ensure these aspects [2].

Each of these projects is important in creating a better Internet for current and, hopefully, future needs. The Internet has brought about many wonderful advantages that most people could not conceive of being without, but it has also brought about new threats, such as domain naming service (DNS) attacks, personal identification theft, and other security issues that were previously far less widespread or nonexistent. Perhaps one of these projects, or a future project, will help bring a less inherently flawed Internet, which will lead to even more innovations in the future.

sdn Application 2: rural Connectivity

SDN has not just led to innovations in researching new Internet protocols; it also has many other applications, such as making the Internet more widespread than it already is. If a person lives away from vastly populated areas, it is almost impossible to use the Internet. Rural areas are often forgotten or ignored by large companies because the profit margins are small, and it is difficult to update the required network hardware [3].

SDN simplifies complex data center and enterprise networks; it can further be used to simplify rural Wi-Fi networks. The main issues with rural environments include sparse populations, small profit margins and resource constraints, and others. However, there have been many recent innovations that help alleviate these issues. These innovations


include long-distance Wi-Fi, a larger unlicensed frequency band (e.g., adding the microwave spectrum), and SDN itself [3].

SDN is beneficial because it separates network construction and net-work configuration by placing the control and management function-ality into the central controller. This separation allows companies to decrease startup costs in rural environments, thereby allowing them to gain more profit. As rural networks become more profitable, more com-panies will be willing to give access to more and more rural areas [3].

Separating the hardware and the software aspects of networking allows for flexible network control. SDN allows for virtualization of networks so that one can look at the network more abstractly and focus on the big picture rather than on all the gritty details. Furthermore, SDN would allow for network management to be conducted off-site by a separate company. Then, a local company needs only to focus on the physical construction and maintenance of the components needed for the network [3].

Another benefit of SDN would be that all of the rural networks would then be viewing the network from a global perspective, and the companies could then share software solutions with others, rather than rely on ad-hoc methods that are only applicable to a specific situ-ation or environment [3].

SDN would allow rural networking companies to work with estab-lished companies rather than to compete. The rural companies could each work on the maintenance and construction side, whereas the more established telecommunication companies could work on the management of the rural networks. The idea of working together is foreign to the mindsets of many large corporations. Generally, com-panies are striving against one another, but this solution would allow both companies to mutually benefit in separate areas of expertise (hardware and software).

There are several difficulties involved in setting up this rural net-work solution. These difficulties include a network such as this that has never been set up in practice anywhere, and it is more difficult to set up controls in rural environments than in data centers, where it is easier to separate control traffic from data traffic [3]. A true test envi-ronment in a rural area would need to be conducted to find the feasi-bility of this solution. Companies would also have to learn accepting the idea that cooperation would be beneficial to all those involved.


sdn Application 3: updating networks by Changing silicon

SDN is limited by the hardware that can use it [4]. If one were to change the silicon from a common merchant silicon to one that was designed with SDN in mind, SDN could even be more beneficial.

The basic hardware limitations found with merchant silicon include small-size tables to implement SDN data planes, lack of support for flexible actions, slow bus speeds between pipeline and on-chip CPU, and slow on-chip CPUs. In Ref. [4], by using a combination of hard-ware and software, they implemented a solution that uses merchant hardware and an network processing unit (NPU)-drive software sub-system to keep costs down. They benchmarked common merchant sili-con switch chips and found the limitations previously mentioned [4].

They were able to make their version of switches capable of P2P detection and prevention, detect intrusion, and encrypt on-demand flows. This solution was able to work well with the existing software implementation of SDN. Because it requires a hardware change, it could have potential issues in upgrading. Moreover, it cannot effi-ciently support networks with tight delay requirements. It also requires the two planes (data and control) to have consistent state information, which involves communication between the controller and the switch.

Upgrade issues as well as the sharing of current state information may be too difficult to overcome. Further testing would need to be implemented to see if this solution is viable. Different switch and hardware companies would each have to use the new silicon solution to create a widespread adoption of it. If all of the major companies do not upgrade their hardware, then the solution will never move past small trials.

sdn Application 4: updating data Center networks

It is currently difficult to connect different data center networks. Often, data center networks use proprietary architectures and topologies, which create issues when merging different networks; however, there is often a need to merge two divergent networks. For example, when a new company is acquired, the original network must be expanded to


incorporate the new network, but with the aforementioned problems, this merge is often time consuming.

SDN brings a solution to this networking issue. In Ref. [5], they proposed to use an OpenFlow-based network infrastructure service software to connect data center networks. They further stated that these interconnected data center networks could solve problems with latency by moving the workload to underused networks. If a network is busy at a certain time of the day, the workload might be completed sooner in a network of a different time zone or in a network that is more energy efficient.

They also tested their solution by using two data center network topologies. The established infrastructure service software application sets OpenFlow rules for network connectivity under different opera-tions. Generally, it would take a long time for the switches to discover all of the rules, so they created a resource description that contained all of the available data center resources. Two different types of rules that were used are global and specific. Global rules are based on the data center topology, whereas specific rules determine how the opera-tions are handled by the hardware.

They found some limitations in their solution. It was found that it is difficult to scale because it is trying to match a large number of packet fields of multiple protocols at different layers [5]. Furthermore, in severe cases, the lookup times can be slow because of collisions.

Such an approach requires that a number of rules be established. This number of rules is proportional to the number of switches and servers in the network. As more rules are introduced, it is more difficult to ensure that every rule is valid, and none of the rules conflicts with a previously defined rule. They, however, created a generic set of configuration rules for data centers, which allows for data centers using OpenFlow to be interconnected easily. The original setup time of the OpenFlow rules is in the 20- to 40-ms time frame, depending on whether the network is a standard network or a virtual machine, respectively.

In the future, we should test this approach in a real-world situation or, at least, create a virtual testbed with more than two data centers. Google has at least 12 data centers; although many companies have fewer data centers, it would be a good idea to at least test this software on more than two data centers.


sdn Application 5: Cloud data scalability

As previously mentioned, data centers are an integral part of many companies. For example, Google has a large number of data cen-ters, so they can quickly and accurately provide data when requested. Similarly, many other companies use data centers to provide data to clients in a quick and efficient manner, but data centers are expensive to maintain. OpenFlow allows companies to save money on setting up and configuring networks because it allows switches to be man-aged from a central location [1].

OpenFlow allows testing of new routing techniques and changes in protocols without affecting anything in a production environment. This ability to test new ideas allows researchers to invent new networking protocols that can work more efficiently for many applications [1,2]. In Ref. [1], it would be interesting to see if cloud data centers could be more scalable and faster to set up if they used OpenFlow.

In Ref. [1], a data center model is created with a large number of nodes to test performance, throughput, and bandwidth. The model included 192 nodes with four regular switches and two core switches with an OpenFlow controller. There was a firewall between the core switches, the OpenFlow controller, and the router. They also used Mininet to prototype their network and test the performance. Mininet is an application that allows researchers to customize an SDN using OpenFlow protocols. Furthermore, they used several tools to analyze their network setup, including Iperf, Ping, PingAll, PingPair, and CBench. These tools allow people to check the possible bandwidth in the network, the connectivity among nodes, the connectivity between the deepest nodes, and the speed in which flows can be changed in a network. Wireshark was also used to view traffic in the network.

After they tested their network using all the tools previously described, they found that OpenFlow would be good to use in data centers because of its ability to reduce switch configuration time as well as to be controlled from a centralized controller. They recom-mend that data centers wait on OpenFlow to be tested further before changing all their switches to OpenFlow switches. Because their test-ing was done on a virtual machine using Mininet, it would need to be tested further in a real environment to ensure that all results are realistic.


sdn Application 6: Mobile Application Offloading

Mobile devices have become increasingly popular both for general consumers and for businesses in recent years. To make mobile devices truly useful in a business environment, they need to securely send data to other servers and other work machines. Because battery life and performance are critical on mobile platforms, any additional software necessary for security would need to be lightweight enough to not impede the functioning of the device.

Two important considerations to make when creating offload-ing software for mobile devices are privacy and resource sharing [6]. Privacy is important for business applications because people often work on data that need to be kept secure. Some data can be sent among only a few people, whereas other data do not require the same level of security. The ability to determine which data require additional security is important for mobile offloading applications. In addition, resource sharing is important for mobile offloading because it allows mobile devices to exploit the machines that are idle or not fully using their capabilities.

In Ref. [6], they used an enterprise-centric offloading system (ECOS) to address these concerns of security and resource sharing. The control-ler of the system needed to do most of the computational work to relieve mobile devices of this necessity. ECOS was designed to offload data to idle computers while ensuring that applications with additional security requirements are only offloaded on approved machines. Performance was also considered for different users and applications [6].

ECOS reviews the available idle computing resources to find an appropriate resource to offload data. The machine chosen is required to provide a benefit in either latency or energy savings or both. Furthermore, the machine chosen has to meet the minimum security requirements for the particular application. Three security catego-ries for the applications are user-private data, enterprise-private data, and no-private data. Only certain users can access user-private data, whereas enterprise-private data need only remain within the business environment. No-private data require no security because they can be accessed by anyone [6].

SDN is used to control the network and to select resources. It is a good choice because it is less resource intensive than the other choices.


The selected resources must be able to meet the security requirements listed above. The controller will determine if such a device is available for offloading that meets the security requirements while maintaining energy savings. If there is no such device, data are not allowed to be offloaded from the mobile device. If energy savings are not necessary, then any available resource with enough capacity is used. OpenFlow switches are used so that the controller can regulate the flows.

ECOS was able to provide decision-making controls to offloading while not ignoring security or energy-saving requirements. It is able to use the benefits of SDNs. In Ref. [6], they showed that ECOS was able to offload while considering security requirements without an overly complex scheme. Furthermore, ECOS was shown to scale to accommodate many mobile devices.

sdn Application 7: Mobile Virtual Machines

Applications running on virtual machines in businesses are becom-ing increasingly common [7]. These virtual machines allow companies to be more flexible and to have lower operational costs. To extract the full potential from a virtual machine, there needs to be a means of making them more portable. The main issue with making virtual machines portable is the need to maintain the IP address of the vir-tual machine in the process. To maintain the same IP address, the virtual machine would have to remain in the same subnet or a new scheme would need to be created.

It was found that the current methods of handling virtual machines were not efficient. The choice of solutions that they found in Ref. [7] includes using a mobile IP or a dynamic DNS. The main issue with both of these solutions is that someone has to manually reconfigure the network settings after removing the virtual machine. This limits businesses and data centers from easily porting their virtual machines to new locations [7].

CrossRoads was an application developed by Mann et al. [7] to solve the mobility issue for virtual machines. It was designed to allow the mobility of both live and offline virtual machines. It has three main purposes. The first purpose is to take care of traffic from data centers as well as external users. The second purpose is to make use of OpenFlow with the assumption that each data center uses an


OpenFlow controller. The third purpose is to make use of pseudo addresses for IP and MAC addresses so that they remain constant when porting while allowing the real IP to change accordingly [7].

The basic implementation of their software was to create rules for finding the virtual machines in different networks. The CrossRoads controller would keep track of the real IP and MAC addresses for the controllers in each data center as well as the virtual machines in its own network. When a request is sent for an application running on a particular virtual machine, a request is broadcasted to the control-lers. If the controller receives a request for a virtual machine that is not in its table, it then broadcasts the request to the other controllers; the controller who has the real IP address of the virtual machine then sends the pseudo MAC address to the original controller, and the original controller can update its table in case it gets another request in the near future.

To test their implementation, Mann et al. [7] set up a virtual testing environment. This virtual environment consisted of two data centers, which were used to understand how CrossRoads performs in a realistic environment. They ran four 15-min experiments to test the performance of their network. They were able to decrease the address resolution pro-tocol (ARP) latency by 30% while maintaining similar ping times, available bandwidth, and HTTP response time with respect to a default testbed, where the virtual machines are all in the same subnet [7].

discussion

SDN has been shown to be a valuable resource in many different types of applications. From Internet research to many data center applica-tions, SDN has found a wide array of useful possibilities. SDN allows users to quickly adapt networks to new situations as well as to test new protocols for production networks. Different network situations can be tested using OpenFlow and SDN.

Table 1.1 shows some differences between the applications previ-ously discussed. As one can see from the table, OpenFlow was used in most of the applications for its versatility. Data centers were also a topic for many of these applications. Data centers continue to become an important part of the Internet and many large companies. The col-umn for mobile applications in Table 1.1 refers to cell phones, tablets,


and other nontraditional media formats rather than laptops and other typical computing platforms. A few of the applications use cloud for their platforms. Hardware changes are difficult to implement in large-scale changes. One of the applications calls for a hardware change to make SDN work better. Hardware changes are often not practical because they require system shutdown during upgrade.

Conclusion

SDNs have many applications, including researching new protocols prior to implementing them in real networks, increasing connec-tivity in rural environments, making both cloud-based and regular data centers better, and supporting mobile device offloading. As the Internet continues to grow and becomes available to more and more people, networks will need to adapt to ever-changing circumstances. SDNs allow the data and control planes to be separated to make it easier for improvements.

References 1. Baker, C., A. Anjum, R. Hill, N. Bessis, and S. L. Kiani. 2012. Improving

cloud data center scalability, agility and performance using OpenFlow. 2012 4th International Conference on Intelligent Networking and Collaborative Systems (INCoS). IEEE. Bucharest, Romania, pp. 20–27.

Table 1.1 Differences between Different Applications

ApplicAtions openFlow? DAtA centers?Mobile

plAtForM? clouD?HArDwAre cHAnge?

internet research Yes Yes/for all that uses the internet

Yes no Maybe

rural connectivity no no no no nochanging silicon no Yes/could be

utilized by data centers and all

other users

no no Yes

Data centers Yes Yes no no nocloud data centers Yes Yes Yes Yes noMobile applications Yes no Yes no noVirtual machines Yes Yes Yes Yes no


2. de Oliverira Silva, F., J. H. de Souza Pereira, P. F. Rosa, and S. T. Kofuji. 2012. Enabling future Internet architecture research and experimenta-tion by using software-defined networking. 2012 European Workshop on Software-Defined Networking (EWSDN). IEEE, Darmstadt, Germany, pp. 73–78.

3. Hasan, S., Y. Ben-David, C. Scott, E. Brewer, and S. Shenker. 2013. Enhancing rural connectivity with software-defined networks. Proceedings of the 3rd ACM Symposium on Computing for Development. ACM, New York, Article 49, 2 pp.

4. Narayanan, R., S. Kotha, G. Lin, A. Khan, S. Rizvi, W. Javed, H. Khan et al. 2012. Macroflows and microflows: Enabling rapid network inno-vation through a split SDN data plane. 2012 European Workshop on Software-Defined Networking (EWSDN). IEEE, Darmstadt, Germany, pp. 79–84.

5. Boughzala, B., R. Ben Ali, M. Lemay, Y. Lemieux, and O. Cherkaoui. 2011. OpenFlow supporting interdomain virtual machine migration. 2011 8th International Conference on Wireless and Optical Communications Networks (WOCN). IEEE. Paris, France, pp. 1–7.

6. Gember, A., C. Dragga, and A. Akella. 2012. ECOS: Leveraging software-defined networks to support mobile application offloading. Proceedings of the 8th ACM/IEEE Symposium on Architectures for Networking and Communications Systems. ACM, New York, pp. 199–210.

7. Mann, V., A. Vishnoi, K. Kannan, and S. Kalyanaraman. 2012. CrossRoads: Seamless VM mobility across data centers through software-defined networking. Network Operations and Management Symposium (NOMS). IEEE. Maui, HI, pp. 88–96.

network innovation through openflow and sdn - it · pdf filevii contents preface xi editor xv...

Documents