openflow: an approach towards centralizing the … · openflow: an approach towards centralizing...

OpenFlow: An Approach towards Centralizing the Routing Decision

*(Department of Information Technology, Kalol Institute of Technology, Kalol)

** (Asst. Prof., Department of Information Technology, Kalol Institute of

Abstract

Software Defined Networking (SDN)

approach which allows the network operator to

manage network elements using software

running on external server. This is

accomplished by a split in the architecture

between the forwarding element and the control

element. This paper proposes the OpenFlow as a

way of networking where the controlling

software is moved to one or more hardware

module (controllers) which can control many

switches. Flow table in all the forwarding

elements (Switches) are modified by the

centralized controller, and so all the routing

information is centralized to controller.

OpenFlow provides a standardize interface for

remotely controlling the forwarding tables in

network switch, routers and access

Finally this paper shows the features and the

concept of information centralization.

Keywords: OpenFlow, Software Defined

Networking, Ethernet switch, Flow Table

1. Introduction

In the discussion about the growing Internet,

OpenFlow is seen as one of the approach that may

pave the way towards that goal. OpenFlow [1]

was first proposed in for the researcher to perform

experiment within the production network. In real

OpenFlow was beyond experiments and research

e.g. in the context of network vir

offers high flexibility in the routing of network

flows and freedom to change the behavior of a

part of a network without affecting the whole

network. This was achieved by the concept of

plane separation where separating the control

plane in the network switched from data plane

(forwarding plane), and allowing the centralized

Approach towards Centralizing the Routing Decision

BY

Viral Parmar *

Amit Patel**


** (Asst. Prof., Department of Information Technology, Kalol Institute of Technology, Kalol)

Software Defined Networking (SDN)[7] is an

approach which allows the network operator to

manage network elements using software

running on external server. This is

accomplished by a split in the architecture

n the forwarding element and the control

element. This paper proposes the OpenFlow as a

way of networking where the controlling

software is moved to one or more hardware

module (controllers) which can control many

switches. Flow table in all the forwarding

elements (Switches) are modified by the

centralized controller, and so all the routing

information is centralized to controller.

OpenFlow provides a standardize interface for

remotely controlling the forwarding tables in

network switch, routers and access points.

Finally this paper shows the features and the

concept of information centralization.

OpenFlow, Software Defined

itch, Flow Table

In the discussion about the growing Internet,

one of the approach that may

pave the way towards that goal. OpenFlow [1]

was first proposed in for the researcher to perform

experiment within the production network. In real

OpenFlow was beyond experiments and research

e.g. in the context of network virtualization. It

offers high flexibility in the routing of network

flows and freedom to change the behavior of a

part of a network without affecting the whole

network. This was achieved by the concept of

plane separation where separating the control

n the network switched from data plane

(forwarding plane), and allowing the centralized

or separate controller [4] entity that m

ay change

the forwarding rules in the modern swi

tches.

The whole routing decision is centrali

zed in such

a way that the switches act only as the

forwarding

plane, and the switch tables are m

odified by

controller as per the routing requir

ed by data

packets.

In remainder of this paper we

explain the

OpenFlow architecture in more deta

ils and the

way flow entries are modified in the

switches (forwarding plane) by the

centralized

controller.

2. Background

To better understand OpenFlow, we

first give a

brief overview of OpenFlow with

regards to

commercial network switch without

OpenFlow

feature.

OpenFlow was designed as a ne

w era

networking, which enables the expe

rimenter to

test new ideas under realistic conditi

on without

affecting the real production netw

ork on an

existing network infrastructure. Bel

ow is the

outline figure of commercial netw

without OpenFlow capability.

Fig 1: Simple Switch Architecture

[2]

OpenFlow separates the control plane

from data

plane and connects them by open in

terface;

controller plane is implemented in the

software in

form of a controller on an externa

l PC. For

Communication between controller an

d

OpenFlow protocol over secure chann

el as shown

in the figure [2].

Approach towards Centralizing the Routing Decision


Technology, Kalol)

entity that

may change

the forwarding rules in the modern sw

itches.

The whole routing decision is central

ized in such

s act only as th

e forwarding

plane, and the switch tables are

modified by

controller as per the routing requi

red by data

In remainder of this paper w

e explain the

OpenFlow architecture in more det

ails and the

way flow entries are modified in th

e OpenFlow

switches (forwarding plane) by the

centralized

To better understand OpenFlow, we

first give a

ow with

regards to

commercial network switch withou

t OpenFlow

OpenFlow was designed as a n

ew era in

networking, which enables the exp

erimenter to

test new ideas under realistic condit

ion without

affecting the real production net

work on an

existing network infrastructure. Be

low is the

outline figure of commercial net

work switch

Simple Switch Architectur

e [2]

OpenFlow separates the control plan

e from data

i

nterface; the

controller plane is implemented in th

e software in

form of a controller on an extern

al PC. For

Communication between controller a

nd switch an

n

nel as shown

Viral Parmar et al , Int.J.Computer Technology & Applications,Vol 4 (3),474-477

IJCTA | May-June 2013 Available [email protected]

474

ISSN:2229-6093

Fig 2: OpenFlow Enabled Swi

The OpenFlow switch flow table is mainly

populated with three components. Fir

component consist of 12 fields with the

information found in the packet header used to

match the incoming packet, second is the list of

action that tells how to handle the matched

packets and third, a collection of statistics for

particular flow, like number of bytes, number of

packets, and time passed since the last match.

Fig 3: Open Flow Network model with Flow table

abstraction [2].

Figure 4: Flow Table Fields [2]

3. OpenFlow Concept The concept of OpenFlow is based on separating

forward-ing logic and control funct

(Ethernet) switch and implementing the latter in a

remote control unit. To realize this, the proposed

architecture for OpenFlow is composed of

main building blocks as depicted in Fig. 1. The

building blocks are namely the OpenFlow switch,

the controller and the OpenFlow protocol that

enables the connection between the

blocks over a secure channel [1]. In the following,

Fig 2: OpenFlow Enabled Switch

The OpenFlow switch flow table is mainly

populated with three components. First set of the

component consist of 12 fields with the

information found in the packet header used to

match the incoming packet, second is the list of

action that tells how to handle the matched

packets and third, a collection of statistics for

low, like number of bytes, number of

packets, and time passed since the last match.

Fig 3: Open Flow Network model with Flow table

Figure 4: Flow Table Fields [2]

The concept of OpenFlow is based on separating

ing logic and control functions of a

implementing the latter in a

this, the proposed

ure for OpenFlow is composed of three

ocks as depicted in Fig. 1. The

s are namely the OpenFlow switch,

OpenFlow protocol that

bles the connection between the first two

blocks over a secure channel [1]. In the following,

we explain each of the three blocks in more

details.

Fig 5: Functional elements of an OpenFlow switch and

controller

.

An OpenFlow switch includes a data

element that realizes the packet forwarding

engine. In the heart of the data-path there is a

table that is used to decide about how

incoming packets. The table has an

identified flow of packets, and hence it is called

flow table. Each flow entry in the flow table

includes rules for identifying the associated

frames, a set of actions to be executed on the

associated frames, and counters for collecting

statistics about the frames that have successfully

matched that entry. The data-path element is

exposed to an external control unit by means

standard application programming interface

The rules matching incoming frame with flow

entries are based on the value of frame’ L1

header fields. Fig 6[8] shows the header fields

that are used for the matching process in an

OpenFlow version 1.0. The value of a field for a

flow entry

can also be set to a wildcard, which means the

content of that field in an incoming frame does

not influence the result of the matching process.

This facilitates a flexible definition of flows

ranging from micro flows (e.g., an individual

TCP/UDP flow) to highly aggregated flows (e.g.,

all packets originated from a given autonomo

system (AS) domain).

Fig 6: Header field used for matching frame to flow

entries

The flow table is usually implemented in

hardware using ternary content addressable

memory (TCAM)[8], which enables efficient

matching of frame with flow entries at line

TCAM’s are quite expensive as compared to

conventional random access memories(RAM).

explain each of the three blocks in more

ts of an OpenFlow switch and

cludes a data-path

element that realizes the packet forwarding

path there is a

hat is used to decide about how to forward

an entry per

identified flow of packets, and hence it is called

flow table. Each flow entry in the flow table

the associated

f actions to be executed on the

associated frames, and counters for collecting

the frames that have successfully

path element is

external control unit by means of a

standard application programming interface.

The rules matching incoming frame with flow

alue of frame’ L1-L4

shows the header fields

that are used for the matching process in an

The value of a field for a

can also be set to a wildcard, which means the

incoming frame does

matching process.

a flexible definition of flows

g., an individual

to highly aggregated flows (e.g.,

given autonomous

Fig 6: Header field used for matching frame to flow

The flow table is usually implemented in

hardware using ternary content addressable

memory (TCAM)[8], which enables efficient

matching of frame with flow entries at line rate

TCAM’s are quite expensive as compared to

conventional random access memories(RAM).



475

ISSN:2229-6093

Once a frame enters the switch and hits a flow

entry in the flow table, a set of actions associated

with that entry are executed on the frame. The

actions could be for example forwarding the

frame to one or all switch ports. If no match can

be found for an incoming Ethernet frame in the

flow table, it is encapsulated in an OpenFlow

frame and forwarded to the remote controller to

which the switch is connected. The cont

then decides about what to do with the frame

and if necessary can cache its decision into the

flow table in form of a new entry. In that case, the

switch can directly handle upcoming frames of

the same flow without consulting the controller.

To realize that, an OpenFlow controller utilizes

the API provided by the OpenFlow protocol to

implement a control layer for a network of

OpenFlow switches. A single controller can

manage several OpenFlow switches if it enjoys

enough resources (e.g., processing po

an important feature, which facilitates realization

of a centralized control plane for a network of

OpenFlow switches.

The standard open set of API provided by the

OpenFlow, further provides the flexibility that

any network provider can deve

controller, which can also be used to control the

OpenFlow switches developed by different

vendor.

4. Working Principal

The basic working principal of an OpenFlow

network is, when any packet arrived at OpenFlow

switch, its header information is extracted and

matched against the header portion of the flow

entries. If checking against each of entries in each

of the switch table does no result I a match the

packet is forwarded to the centralized controller,

which examinee and determine how the

should be handled. In the case of match, the

switch applies appropriate to the packet and

update statistic for the flow table entry. This

process is visualized in the figure [3] below.

Fig 5: Handling of incoming packets in OpenFlow

switch

5. Using OpenFlow

A sample example will show how to deal with

OpenFlow switch, suppose Marry had developed

her own protocol or modified the existing one.

Suppose we named it as Marrry-11x. She wanted

Once a frame enters the switch and hits a flow

the flow table, a set of actions associated

with that entry are executed on the frame. The

or example forwarding the

frame to one or all switch ports. If no match can

be found for an incoming Ethernet frame in the

flow table, it is encapsulated in an OpenFlow

frame and forwarded to the remote controller to

which the switch is connected. The controller

then decides about what to do with the frame

and if necessary can cache its decision into the

flow table in form of a new entry. In that case, the

switch can directly handle upcoming frames of

the same flow without consulting the controller.

ize that, an OpenFlow controller utilizes

the API provided by the OpenFlow protocol to

implement a control layer for a network of

OpenFlow switches. A single controller can

manage several OpenFlow switches if it enjoys

enough resources (e.g., processing power). This is

an important feature, which facilitates realization

of a centralized control plane for a network of

The standard open set of API provided by the

OpenFlow, further provides the flexibility that

any network provider can developed its own

controller, which can also be used to control the

OpenFlow switches developed by different

The basic working principal of an OpenFlow

network is, when any packet arrived at OpenFlow

n is extracted and

portion of the flow

entries. If checking against each of entries in each

of the switch table does no result I a match the

packet is forwarded to the centralized controller,

which examinee and determine how the packet

should be handled. In the case of match, the

switch applies appropriate to the packet and

update statistic for the flow table entry. This

process is visualized in the figure [3] below.

Fig 5: Handling of incoming packets in OpenFlow

A sample example will show how to deal with

OpenFlow switch, suppose Marry had developed

her own protocol or modified the existing one.

11x. She wanted

to try her protocol in live production traffic.

Marry-11x will run in controller; each time a new

application flow starts Marry-11x picks up a route

through a series of OpenFlow switches [5] an

adds the flow entry in each switch along the path.

Traffic that arise from any of the switch port; the

packets are matched against the entry in the flow

table, then are forwarded to the controller.

Controller working with the new Marry

Protocol will choose a route and adds a new flow

entry to every switch along the path. When

subsequent packets arrive at switch it is pr

quickly by flow table and sent to appropriate

destination.

6. Conclusion and Future Work

We believe that OpenFlow is the strong concept

towards software defined networking that allows

the researcher to run experiment in the live traffic

without affecting the production network or

without the need for vender to be specific for

programming their switches. OpenFlow is one of

the technology solutions that have real,

potential to dramatically change the networking

landscape over the next technology generation,

driven initially by the service providers and cloud

services companies that need it most and

the best advantage of all it has to offer.

a player or potential player in the servi

and haven’t yet made the commitment to examine

OpenFlow, two things are clear: Your need to

deliver bandwidth will continue to grow, and at

some point, you will need to consider OpenFlow

as a potential solution.

In future we will implement a discrete event

simulation model of a data center enabled with

the OpenFlow protocol and will show the way

VM migrate within.

7. Reference

[1] N. McKeown et al., OpenFlow: Enabling

innovation in campus networks, SIGCOMM,

Rev. 38(2), 69-74, 2008

[2]Robert Sherwood: An Experimenter guide to

OpenFlow, GENI Engineering Workshop, June

2010

[3] Modeling and Performance Evaluation of

OpenFlow Architecture, ITC 2011

[4] http://www.openflow.org/wp/documents/

[5] The OpenFlow Switch Specification.

Available at http://OpenFlowSwitch.org

to try her protocol in live production traffic.

will run in controller; each time a new

11x picks up a route

through a series of OpenFlow switches [5] an

adds the flow entry in each switch along the path.

Traffic that arise from any of the switch port; the

ed against the entry in the flow

table, then are forwarded to the controller.

Controller working with the new Marry-11x

Protocol will choose a route and adds a new flow

entry to every switch along the path. When

subsequent packets arrive at switch it is processed

quickly by flow table and sent to appropriate

and Future Work

We believe that OpenFlow is the strong concept

towards software defined networking that allows

experiment in the live traffic

affecting the production network or

without the need for vender to be specific for

OpenFlow is one of

the technology solutions that have real, viable

potential to dramatically change the networking

logy generation,

providers and cloud

ompanies that need it most and can take

the best advantage of all it has to offer. If you are

or potential player in the services market

ment to examine

OpenFlow, two things are clear: Your need to

deliver bandwidth will continue to grow, and at

onsider OpenFlow

In future we will implement a discrete event

nter enabled with

the OpenFlow protocol and will show the way

OpenFlow: Enabling

SIGCOMM,

[2]Robert Sherwood: An Experimenter guide to

OpenFlow, GENI Engineering Workshop, June

nd Performance Evaluation of

http://www.openflow.org/wp/documents/

tch Specification.

http://OpenFlowSwitch.org



476

ISSN:2229-6093

[6] Yianni, Yiakoumis, Kok-Kiong, Yap, Sachin

Katti, Guru Parulkar, Nick McKeown, “Slicing

Home Networks”

[7] Software Defined Networking: The new form

for network, April 12, 2012.

[8]A. Rostami, T. Jungel, A.Koepsel, H.Woesner, A.Wolisz, “ORAN: OpenFlow Routers for

Academic Networks”, June, 2012.

[9] Andrea Bianco, Robert Birke, Luca Giraudo, Manuel Palacin, “OpenFlow Switching: Data

Plane Performance”, IEEE ICC 2010



477

ISSN:2229-6093

openflow: an approach towards centralizing the … · openflow: an approach towards centralizing...

Documents