OFSwitch13: Enhancing ns-3 with OpenFlow 1.3 Supportstatic.tongtianta.site/paper_pdf/c47ad942-1bd5-11e9-bccd-00163e08… · forward software tool is Mininet [6]. It is an open-source

OFSwitch13: Enhancing ns-3 with OpenFlow 1.3 Support

Luciano Jerez Chaves, Islene Calciolari Garcia, and Edmundo Roberto Mauro MadeiraComputer Networks Laboratory, Institute of Computing

University of Campinas (Unicamp), [email protected], {islene, edmundo}@ic.unicamp.br

ABSTRACTThe world is witnessing the rapid evolution of communica-tion technologies, and meeting current market requirementsis virtually impossible with traditional network architec-tures. Many works point to the use of Software DefinedNetworking (SDN) paradigm and the OpenFlow protocol asenabling solutions to overcome current limitations. Despitethe fact that the Network Simulator 3 (ns-3 ) already hasa module that supports OpenFlow simulations, it is pos-sible to note that the available implementation provides avery outdated protocol version (0.8.9). As many new ma-jor features were introduced up to the latest versions, it isinteresting to have some of them available for use. In thiscontext, this paper presents the OFSwitch13: a module toenhance the ns-3 with OpenFlow 1.3 technology support.This module provides both an OpenFlow 1.3 switch deviceand a controller application interface. Details about mod-ule design and implementation are discussed throughout thispaper, and a case study scenario is used to illustrate someof the available OFSwitch13 module features.

CCS Concepts•Computing methodologies → Model developmentand analysis; Simulation support systems; Simula-tion environments; Discrete-event simulation; •Networks→ Network simulations;

KeywordsSDN, OpenFlow 1.3, Network Simulator 3 (ns-3 )

1. INTRODUCTIONAs stated by the Open Networking Foundation (ONF),

network operators are facing challenges as the number ofconnected devices increases [14]. Meeting current marketrequirements is virtually impossible with traditional networkarchitectures, where the vendor dependence and lack of openinterfaces limit the ability of network operators to tailor the

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full cita-tion on the first page. Copyrights for components of this work owned by others thanACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re-publish, to post on servers or to redistribute to lists, requires prior specific permissionand/or a fee. Request permissions from [email protected].

WNS3, June 15-16, 2016, Seattle, WA, USAc© 2016 ACM. ISBN 978-1-4503-4216-2/16/06. . . $15.00

DOI: http://dx.doi.org/10.1145/2915371.2915381

network to their individual environments. In this context,SDN has emerged as a network architecture where networkcontrol is decoupled from packet forwarding, enabling moreagile and flexible networks [14]. The OpenFlow protocol [12]is the first standard technology designed specifically for SDNand has been adopted by a number of networking vendorsand by the research community.

As is known, it is very costly to deploy a complete testbedcontaining multiple networked computers, routers, switchesand data links to validate and verify a certain network proto-col or a specific network algorithm. In these circumstances,software tools save a lot of money and time in accomplish-ing this task. When talking about OpenFlow, the straight-forward software tool is Mininet [6]. It is an open-sourceemulator that provides a quick and easy way to prototypeand evaluate SDN networks. It creates user-space or kernelfull-compliant OpenFlow switches, allowing the use of realcontrollers and softwares. However, Mininet suffers from themaximum link bandwidth limited by hardware processingpower and no time dilation, which prevents it from carry-ing out emulations when computational demand is higherthan the real-time processing capacity. When it comes tothe experimentation of the OpenFlow protocol in wirelessnetworks, these shortcomings become more worrisome [3].

A reasonable choice would be using a simulated environ-ment to this end, such as the Network Simulator 3 (ns-3 ) [7].It is a discrete-event simulator, targeted primarily for re-search and educational use, and distributed as free software.ns-3 simulations can model OpenFlow switches via the ex-isting OpenFlow module [4], which relies on an externalOpenFlow switch library linked to the simulator. This mod-ule implements a very outdated OpenFlow protocol (ver-sion 0.8.9 [16]), and too many new major features were in-troduced up to the latest versions. Among these new fea-tures, it is possible to cite multiple tables in the pipeline,group tables, virtual ports, extensible match support, IPv6support, per flow meters, auxiliary connections, and supportfor multiple controllers.

To overcome this shortage, this paper introduces the OF-

Switch13 module for ns-3 [8]. This module provides sup-port for OpenFlow protocol version 1.3 [17], bringing botha switch device and a controller application interface to thesimulator, as depicted in Figure 1. With this module, it ispossible to interconnect ns-3 nodes to send and receive traf-fic using the existing Carrier Sense Multiple Access (CSMA)network devices and channels. To orchestrate the network,the controller application interface can be extended to im-plement any desired control logic. The communication be-

Workshop on ns-3 - WNS3 2016 - ISBN: 978-1-4503-4216-2 Seattle, Washington, USA - June 15-16, 2016

33

ofsoftswitch13 library

ns-3 environmentexternal environment

OpenFlow 1.3 controller application interface

Protocolstack

NetDevice

Controller

(ns-

3 no

de)

OpenFlow 1.3 switch device

Protocolstack

NetDevice

Switch

(ns-

3 no

de)

CSMANetDeviceCSMA

NetDeviceCSMANetDevice

Channel

Con

trol p

lane

Dat

a pl

ane

Figure 1: The OFSwitch13 module overview.

tween the controller and the switch is realized over standardns-3 protocol stack, devices and channels. The module alsorelies on an external library (ofsoftswitch13) [11] that pro-vides the switch datapath implementation, the dpctl utilitytool used to create OpenFlow messages from command lineswith simple syntax, and the code for converting OpenFlowmessages to and from wire format.

The remainder of this paper describes the SDN paradigm,the module design and implementation, and an illustrativecase study scenario. It is organized as follows: Section 2examines the SDN paradigm and the OpenFlow protocolwhile Section 3 describes the module design and implemen-tation. Section 4 presents a case study scenario that is usedto demonstrate some of the OpenFlow 1.3 module features.Section 5 concludes by summarizing the work described inthis paper and looking toward future endeavors.

2. SOFTWARE-DEFINED NETWORKINGSoftware Defined Networking (SDN) is a paradigm that

has been designed to enable more agile and cost-effectivenetworks. In the SDN architecture, the control and dataplanes are decoupled, network intelligence and state are log-ically centralized, and the underlying network infrastructureis abstracted from the applications. By centralizing networkintelligence, decision-making is facilitated based on a global(or domain) view of the network, as opposed to today’s net-works, which are built on an autonomous system view wherenodes are unaware of the overall state of the network [15].To better understand this paradigm, Subsection 2.1 presentsthe classical SDN architecture while Subsection 2.2 describessome of the main OpenFlow protocol features.

2.1 SDN ArchitectureThe ONF is taking the lead in SDN standardization and

has defined the architecture depicted in Figure 2. This SDNarchitecture consists of three distinct layers that are acces-sible through open Application Program Interfaces (APIs):

• The Application Layer consists of the end-user applica-tions that consume the SDN communications services.The boundary between the Application Layer and theControl Layer is traversed by the northbound API.

ONF SOLUTION BRIEF OpenFlow-Enabled Mobile and Wireless Networks

3 of 13© Open Networking Foundation. All rights reserved.

SDN Overview

Software Defined Networking is a new architecture that has been designed to enable

more agile and cost-effective networks. The Open Networking Foundation (ONF) is

taking the lead in SDN standardization, and has defined an SDN architecture model as

depicted in Figure 1.

APPLICATION LAYER

CONTROL LAYER

INFRASTRUCTURE LAYER

NetworkServices

Business Applications

Network Services

APIAPIAPI

The ONF/SDN architecture consists of three distinct layers that are accessible through

open APIs:

The Application Layer consists of the end-user business applications that

consume the SDN communications services. The boundary between the

Application Layer and the Control Layer is traversed by the northbound API.

The Control Layer provides the consolidated control functionality that supervises

the network forwarding behavior through an open interface.

The Infrastructure Layer consists of the network elements (NE) and devices that

provide packet switching and forwarding.

According to this model, an SDN architecture is characterized by three key attributes:

Logically centralized intelligence. In an SDN architecture, network control is

distributed from forwarding using a standardized southbound interface: OpenFlow.

By centralizing network intelligence, decision-making is facilitated based on a

FIGURE 1 ONF/SDN architecture

Figure 2: The ONF/SDN architecture [15].

• The Control Layer provides the consolidated controlfunctionality that supervises the network forwardingbehavior through the southbound API.

• The Infrastructure Layer consists of the simplified net-work elements and devices that provide packet switch-ing and forwarding.

Network intelligence is centralized at control layer, in asoftware-based controller. The controller can maintain anetwork global view, providing real-time information, fastoptimized routing, etc. By centralizing network state, SDNgives network managers the flexibility to configure, man-age, secure, and optimize network resources via dynamic,automated SDN programs. Such programmability enablesnetwork configuration to be automated, influenced by therapid adoption of the cloud. By providing open APIs for ap-plications to interact with the network, SDN networks canachieve unprecedented innovation and differentiation [15].


34

2.2 OpenFlow ProtocolThe OpenFlow protocol [12] is the first southbound inter-

face designed for SDN networks, providing high-performanceand granular traffic control across multiple network devicesfrom different vendors. OpenFlow uses the concept of flowsto identify network traffic based on predefined match rulesthat can be programmed by the SDN controller. The Open-Flow protocol is implemented on both sides of the interfacebetween infrastructure devices and the SDN control soft-ware. The current specification covers the components andthe basic functions of the switch, and the OpenFlow proto-col to manage a switch from a remote controller. Figure 3shows the main components of an OpenFlow switch.

The OpenFlow channel is the interface that connects eachOpenFlow switch to an OpenFlow controller. Through thisinterface, the controller configures and manages the switch,receives events and sends packets out to the network. Thecontrol channel of the switch may support a single Open-Flow channel with a single controller, or multiple OpenFlowchannels enabling multiple controllers to share managementof the switch. All OpenFlow channel messages must be for-matted according to the OpenFlow protocol. The OpenFlowchannel is usually encrypted using Transport Layer Secu-rity (TLS), but may be run directly over plain TransmissionControl Protocol (TCP).

The OpenFlow switch datapath consists of a pipeline ofone or more flow tables, which perform packet lookups andforwarding, based on flow entries configured by the con-troller. Each flow entry consists of OpenFlow eXtensibleMatch (OXM) Type-Length-Value (TLV) fields to identifythe flow, counters, and a set of instructions to apply tomatching packets. The matching starts at the first pipelineflow table, following order of priority, and may continue tonext tables. If a matching entry is found, the instructionsassociated with the specific flow entry are applied. Instruc-tions can modify the pipeline processing, sending the packetto one of the following tables, or can contain actions thatdescribe packet forwarding, packet modification, and grouptable processing. The most common action is the output,which forwards the packet to an output port. Another ac-tion is the group action, which directs the packets to anotherswitch datapath element that is called group table. Groupsrepresent sets of actions for flooding, as well as more complexforwarding semantics. The switch can also send unmatchedpackets to the controller, or simply drop the packet.

OpenFlow Switch Specification Version 1.5.1

1 Introduction

This document describes the requirements of an OpenFlow Logical Switch. Additional informationdescribing OpenFlow and Software Defined Networking is available on the Open Networking Foundationwebsite (https://www.opennetworking.org/). This specification covers the components and the basicfunctions of the switch, and the OpenFlow switch protocol to manage an OpenFlow switch from aremote OpenFlow controller.

Port

Port

Port

Port

OpenFlowChannel

FlowTable

FlowTable

FlowTable

Controller

Pipeline

OpenFlow Switch

OpenFlowChannel Group

TableMeterTableControl Channel

Controller

Datapath

Protocol

Figure 1: Main components of an OpenFlow switch.

2 Switch Components

An OpenFlow Logical Switch consists of one or more flow tables and a group table, which perform packetlookups and forwarding, and one or more OpenFlow channels to an external controller (Figure 1). Theswitch communicates with the controller and the controller manages the switch via the OpenFlow switchprotocol.

Using the OpenFlow switch protocol, the controller can add, update, and delete flow entries in flowtables, both reactively (in response to packets) and proactively. Each flow table in the switch containsa set of flow entries; each flow entry consists of match fields, counters, and a set of instructions to applyto matching packets (see 5.2).

Matching starts at the first flow table and may continue to additional flow tables of the pipeline (see5.1). Flow entries match packets in priority order, with the first matching entry in each table beingused (see 5.3). If a matching entry is found, the instructions associated with the specific flow entry areexecuted (see 5.5). If no match is found in a flow table, the outcome depends on configuration of the

11 © 2015; The Open Networking Foundation

Figure 3: The OpenFlow switch architecture [18].

Another OpenFlow switch datapath element is the metertable, consisted of entries defining per-flow meters. Per-flowmeters enable OpenFlow to implement rate-limiting, a sim-ple Quality of Service (QoS) operation constraining a set offlows to a chosen bandwidth. A switch can also optionallyhave one or more queues attached to a specific output port,and in many cases, those two features can be combined toimplement complex work conserving QoS frameworks, suchas Differentiated Services (DiffServ). The reader can re-fer to the OpenFlow Switch specification [18] for details onthe protocol operation. Note that the Appendix B of thespecification contains the release notes highlighting the mainchanges between major versions of the OpenFlow protocol.

3. OFSWITCH13 MODULEThis section describes the OFSwitch13 module design and

implementation. Subsection 3.1 brings the description ofthe switch device, followed by the controller application in-terface at Subsection 3.2. The OpenFlow channel, used forinterconnecting the controller to the switches, is describedin Subsection 3.3. The external ofsoftswitch13 library ispresented in Subsection 3.4, and the current module limi-tations are listed in Subsection 3.5. For details in classesdesign, please refer to the code API documentation [9].

3.1 OpenFlow 1.3 Switch DeviceThe OpenFlow 1.3 switch device (hereinafter referred to as

switch device) can be used to interconnect ns-3 nodes usingthe existing CSMA network devices and channels. Figure 4shows the internal switch device structure. The switch de-vice takes a collection of ports, each one associated with ans-3 underlying CSMA network device. It acts as the inter-mediary between the ports, receiving a packet from one portand forwarding it to another. The OpenFlow switch data-path implementation (flow tables, group table, and metertable) is provided by the ofsoftswitch13 library. For thisreason, packets entering the switch are sent to the libraryfor OpenFlow pipeline processing before being forwarded tothe correct output port(s). Messages received from the con-troller are also sent to the library for datapath configuration.

A packet enters the switch device through a new Open-Flow receive callback in the CSMA network device that isinvoked for packets successfully received by the network de-vice. This is a promiscuous receive callback, but in contrastto a promiscuous protocol handler, the packet sent to thiscallback also includes the Ethernet header, which is neces-sary for pipeline processing. This is the only required modi-fication to the ns-3 source code for OFSwitch13 integration.

OpenFlow 1.3 switch device

OpenFlow ports

OpenFlow channel(controller communication)

OpenFlow port

Output packet(from the library)

Input packet(to the library)

CSMA network device

OpenFlow queue

OpenFlow RX callback


Figure 4: The OFSwitch13 switch device structure.


35

OpenFlow 1.3 queue

Enqueue (Queue ID)Dequeue

…

Queue QueueQueueOutput

scheduller

Figure 5: The OFSwitch13 queue structure.

To model OpenFlow hardware operations, the OFSwitch13module considers the concept of virtual Ternary Content-Addressable Memory (TCAM) to estimate the average flowtable search time [4]. This search time is used to postponethe pipeline processing at the library. To provide a morerealistic delay, the module considers that real OpenFlow im-plementations use sophisticated search algorithms for packetclassification and matching. As most of these algorithms arebased on binary search trees, the equation k∗ log2(n) is usedfor delay estimation, where k is the constant attribute setto the time for a single TCAM hardware operation and n isthe current number of flow entries in the pipeline.

Packets coming back from the library for output actionare sent to the OpenFlow queue. An OpenFlow switch pro-vides limited QoS support by means of a simple queuingmechanism, where one or more queues can attach to a portand be used to map flow entries on it. The OpenFlow queueextends the ns-3 queue interface to allow compatibility withthe CSMA network devices. Figure 5 shows its internalstructure. It can hold a collection of other queues, each oneidentified by a unique ID. Packets sent to the OpenFlowqueue for transmission are expected to carry a queue tag,which is used to identify the internal queue that will holdthe packet. Then, the output scheduling algorithm decidesfrom which queue to get packets during dequeue procedures.

3.2 OpenFlow 1.3 Controller InterfaceThe OpenFlow 1.3 controller application interface (here-

inafter referred to as controller interface) provides the basicfunctionalities for controller implementation. As illustratedin Figure 6, it can manage a collection of OpenFlow switches.For constructing OpenFlow messages and sending them tothe switches, the controller interface relies on the dpctl util-ity provided by the ofsoftswitch13 library. With a simplecommand-line syntax, this utility can be used to add flowsto the pipeline, query for switch features and status, andchange other configurations. For OpenFlow messages com-ing from the switches, the internal collection of handlers areused to deal with the different types of messages. Some han-dlers can not be modified, as they must behave as alreadyimplemented. Other handlers can be overridden by derivedcontrollers to implement the desired control logic.

The OFSwitch13 module brings a learning controller thatimplements the controller interface to work as a learningbridge device without the Spanning Tree Protocol (STP)implementation [5]. It instructs OpenFlow switches to for-ward incoming unicast frames from one port to the correctoutput port whenever possible (as in the BridgeNetDevice).

OpenFlow 1.3 controller application interface

OpenFlow channel(switch communication)


Internal handlers

dpctl commands“flow-mod add …”

Figure 6: The OFSwitch13 controller structure.

3.3 OpenFlow ChannelThe OpenFlow channel is the interface that connects each

switch to an OpenFlow controller. Through this interface,the controller configures and manages the switch, receivesevents from the switch, and sends packets out the switch. Inthe OFSwitch13 module, the controller interface can managethe switch devices remotely over a separate dedicated net-work (out-of-band controller connection). It is possible touse standard ns-3 channels and devices to create an Open-Flow channel using a single shared channel or individualconnections between the controller interface and each switchdevice. This model provides realistic control plane connec-tions, including communication delay and, optionally, errormodels. It also simplifies the OpenFlow protocol analysis,as the ns-3 tracing subsystem can be used for outputtingPCAP files to be read by third-party software.

Considering that the OpenFlow messages traversing theOpenFlow channel follow the standard wire format, it isalso possible to use the ns-3 TapBridge to allow an exter-nal OpenFlow controller, running on the local machine, tointeract with the simulated environment over this controlchannel. This would allow the use of real controller imple-mentations to manage simulated OpenFlow switches. How-ever, note that this use case has not been validated yet.

3.4 ofsoftswitch13 LibraryThe OFSwitch13 module was designed to work together

with the ofsoftswitch13 user-space software switch com-piled as a library [2, 10]. The original implementation wasforked and slightly modified for proper integration with theOFSwitch13 module [11]. The code does not modify the dat-apath implementation, which is currently maintained in theoriginal repository and regularly synced to the modified one.

Figure 7 shows the library architecture and highlights theOFSwitch13 interconnection points. The library providesthe complete OpenFlow switch datapath implementation,including input and output ports, the flow-table pipeline forpacket matching, the group table, and the meter table. Italso provides the OFLib library that is used for converting in-ternal messages to and from OpenFlow 1.3 wire format, andthe dpctl utility for converting text commands into internalmessages. The NetBee library [13] is used for packet decod-ing and parsing, based on the NetPDL XML-based languagefor packet header description [19].

For proper ns-3 integration, the switch ports were setaside, and the library was modified to receive and send pack-ets directly to the ns-3 environment. To accomplish thistask, all library functions related to sending and receiving


36

OpenFlow 1.3Controller

Ports

0

1

N

Ports

0

1

NFlow Tables

0 1 2 N

NetBee Parser(flow extract)

NetPDL

Meter Table

Meter bandRate X

Meter bandRate Y

Meter bandRate Z

Group Table

0Actions

1Actions

NActions

OFLib

NetBee Link

OpenFlow 1.3Software Switch

datapath

OpenFlow messages

User packets

OFSwitch13 moduleinterconnection

Controlchannel

dpctl utility

Figure 7: The ofsoftswitch13 library architecture (adapted from [2]).

packets over ports were annotated as weak symbols, allowingthe module to override them at link time. This same strat-egy was used for overriding time-related functions, ensuringtime consistency between the library and the simulator. Theintegration also relies on callbacks, which are used by the li-brary to notify the module about internal packet events,like packets dropped by meter bands, packet content mod-ifications by pipeline instructions, packets cloned by groupactions, and buffered packets sent to the controller.

One potential performance drawback is the conversionbetween the ns-3 packet representation and the serializedpacket buffer used by the library. This is even more criti-cal for empty packets, as ns-3 provides optimized internalrepresentation for them. To improve the performance, whena packet is sent to the library for pipeline processing, themodule keeps track of its original ns-3 packet. For pack-ets processed by the pipeline without content changes, theswitch device forwards the original ns-3 packet to the spec-ified output port. In the face of content changes, the switchdevice creates a new ns-3 packet with the modified content(eventually copying all packet and byte tags from the origi-nal packet to the new one). This approach is more expensivethan the previous one but is far more simple than identifyingwhich changes were performed in the packet by the libraryto modify the original ns-3 packets.

3.5 Current LimitationsThese are the major limitations of the available module

in current implementation:

• Platform support : The module implementation is onlyavailable for GNU/Linux platforms, and must be com-piled with the GNU Compiler Collection (GCC).

• Auxiliary connections: Only a single connection be-tween the switch and the controller is available. Ac-cording to the OpenFlow specifications, auxiliary con-nections could be created by the switch and are helpfulto improve the switch processing performance and ex-ploit the parallelism of most switch implementations.

• Multiple controllers: Each switch can only be man-aged by a single controller. According to the Open-Flow specifications, having multiple controllers wouldimprove reliability as the switch can continue to oper-ate if one controller or controller connection fails.

• OpenFlow channel encryption: The switch and con-troller may communicate through a TLS connection toprovide authentication and encryption of the connec-tion. However, as there is no straightforward TLS sup-port on ns-3, the OpenFlow channel is implementedover a plain TCP connection, without encryption.

• In-band control : The OpenFlow controller managesthe switches remotely over a separate dedicated net-work (out-of-band controller connection), as the switchport representing the switch’s local networking stackand its management stack is not implemented.

4. CASE STUDY SCENARIOThe network topology proposed for this case study sce-

nario is described in Subsection 4.1, and it is used to demon-strate how some of the OpenFlow 1.3 module features canbe exercised to improve network management. Specifically,a link aggregation, a load balancing, and QoS per-flow me-tering solutions for this network topology are detailed inSubsections 4.2, 4.3, and 4.4, respectively.

4.1 Network TopologyFigure 8 shows the network topology used for this case

study scenario. It represents the internal network of an orga-nization, where servers and client nodes are located far fromeach other (e.g. in separated buildings). The“long-distance”connection between the sites is via two links of 10 Mbps each,while all the other local connections are 100 Mbps. On theserver side, the OpenFlow border switch acts as a borderrouter element: it is responsible for handling connection re-quests coming from the clients, and redirecting them to theappropriate internal server. On the client side, the Open-Flow client switch is used to interconnect all clients in a star


37

Server 0

Server 1

OpenFlowborder switch

OpenFlowaggregation switch

OpenFlowclient switch

OpenFlow QoS controller

OpenFlowlearning controller

Client 0

Client N

…

100Mbps100

Mbps

10Mbps

100Mbps

10Mbps

Figure 8: The network topology for the case study scenario.

topology. Between these two switches, there is the OpenFlowaggregation switch, located at the border of the client sideand used to provide long-distance improved communication.The default learning controller is used to manage the clientswitch, whereas the new OpenFlow QoS controller is usedto manage the other two switches. The latter controller im-plements some QoS functionalities exploiting OpenFlow 1.3features, as described in the following subsections.

For this case study scenario, a total number of 4 clientnodes was used during simulations. Each client opens asingle TCP connection with one of the 2 available servers,and sends packets in uplink direction as much as possible,trying to fill the available bandwidth. TCP segment size isset to 1400 bytes and the length of the simulation is set to100 seconds. The ns-3 simulation scripts for this case studyscenario are available under the examples/qos-controller/directory at the OFSwitch13 source code.

4.2 Link AggregationThe link aggregation can be used to combine multiple net-

work connections in parallel in order to increase throughputbeyond what a single connection could sustain. To imple-ment the link aggregation, the OpenFlow group table canbe used to split the traffic.

OpenFlow groups were introduced in OpenFlow 1.1 as away to perform more complex operations on packets thatcannot be defined within a flow alone. Each group receivespackets as input and performs any OpenFlow actions onthese packets. The power of a group is that it contains sep-arate lists of actions, and each individual action list is re-ferred to as an OpenFlow bucket. There are different typesof groups, and the select group type can be used to per-form link aggregation. Each bucket in a select group hasan assigned weight, and each packet that enters the groupis sent to a single bucket. The bucket selection algorithmis undefined and is dependent on the switch’s implementa-tion (the ofsoftswitch13 library implements the weightedround robin algorithm).

In the network topology, the QoS controller configuresboth the border and the aggregation switches to perform linkaggregation over the two narrowband long-distance connec-tions, providing a 20 Mbps connection between servers andclients. Each OpenFlow bucket has the same weight in the

0

10

20

30

0 10 20 30 40 50 60 70 80 90 100

Net

wor

k th

roug

hput

(Mbp

s)

Simulation time

With link aggregationWithout link aggregation

Figure 9: Link aggregation mechanism.

select group, so the load is evenly distributed over the links.Figure 9 shows the network aggregated throughput, mea-

sured at the aggregation switch, for simulations with andwithout link aggregation. In the case of no link aggregation,only one of the two long-distance links are used, limitingthe available bandwidth to 10 Mbps. With the link aggre-gation, TCP connections can fill all the available bandwidthfor both links, coming to 20 Mbps throughput.

4.3 Load BalancingA load balancing mechanism can be used to distribute

workloads across multiple servers. Among many goals, itaims to optimize resource use and avoid overload of anysingle server. One of the most commonly used applicationsof load balancing is to provide a single Internet service frommultiple servers, sometimes known as a server farm.

In the network topology, the OpenFlow QoS controllerconfigures the border switch to listen for new requests onthe Internet Protocol (IP) and port where external clientsconnect to access the servers. The switch forwards the newrequest to the controller, which will decide which of the in-ternal servers must take care of this connection. Then, itinstall the match rules into border switch to forward thesubsequent packets from the same connection directly to the


38

0

10

20

30

0 10 20 30 40 50 60 70 80 90 100

Serv

er lo

ad th

roug

hput

(Mbp

s)

Simulation time

Server 0Server 1

Figure 10: Server load balancing mechanism.

chosen server. All this happen without the client ever know-ing about the internal separation of functions.

To implement this load balancing mechanism, the QoScontroller depends on the extensible match support intro-duced in OpenFlow 1.2. Prior versions of the OpenFlowspecification used a static fixed length structure to specifymatches, which prevents flexible expression of matches andprevents the inclusion of new match fields. The extensiblematch support allows the switch to match Address Resolu-tion Protocol (ARP) request messages looking for the serverIP address and redirect them to the controller, which willcreate the ARP reply message and send it back to the net-work. The set-field action is used by the border switch torewrite packet headers, replacing source/destinations IP ad-dresses for packets leaving/entering the server farm.

Figure 10 compares the server load balancing in termsof data arrival throughput from uplink TCP connections.In this case study, the QoS controller uses the round robinalgorithm to perform load balancing among the two availableservers, redirecting half of TCP connections to each one.The link aggregation was enabled during the simulation.

4.4 Per-Flow MetersOpenFlow meter table, introduced in OpenFlow 1.3, en-

ables the switch to implement various simple QoS opera-tions. A meter measures the rate of packets assigned to itand enables controlling the rate of those packets. The metertriggers a meter band if the packet rate or byte rate passingthrough the meter exceeds a predefined threshold. If themeter band drops the packet, it is called a rate limiter.

To illustrate the meter table usage, the OpenFlow QoScontroller can optionally limit each connection throughputto a predefined data rate threshold, installing meter rules atthe border switch along with the load balancing flow entries.

Figure 11 compares the smoothed throughput of all 4 TCPconnections for simulations with and without per-flow meterentries. The link aggregation was enabled during the sim-ulation, and all meter bands were configured to limit eachindividual connections at 1 Mbps. It is possible to observethat TCP connection throughput grows up to the availablebandwidth for simulations without per-flow meter entries(near 5 Mbps for each connection). With meter entries, thethroughput of all TCP connections is limited to 1 Mbps, re-gardless of the available bandwidth.

0

2

4

6

8

10

0 10 20 30 40 50 60 70 80 90 100

TCP

conn

ectio

n th

roug

hput

(Mbp

s)

Simulation time

With meter entriesWithout meter entries

Figure 11: Per-flow metering mechanism.

5. CONCLUSIONS AND FUTURE WORKSDN represents an important paradigm shift that will en-

able future networks to be more simple and flexible. Tar-geting scientific research in this area, this paper introducedthe OFSwitch13: a module to enhance the ns-3 simula-tor with OpenFlow 1.3 technology support. The moduledesign and implementation were presented in the paper,highlighting the available features and listing current lim-itations. The OFSwitch13 module is available as free soft-ware, and its usage requires minimal changes to the ns-3source code. Interested users can visit the project homepageat http://www.lrc.ic.unicamp.br/ofswitch13, which containslinks to the code repository and module documentation.

A case study scenario was used to illustrate some of theOpenFlow 1.3 module features: group tables used to per-form link aggregation; extensible match support used forfine-grained packet matching, server farm implementation,and load balancing solution; and meter table used for im-plementing QoS rate-limiting mechanism. The OFSwitch13

module was also used for ns-3 simulations integrating Open-Flow and Long Term Evolution (LTE) networks, which aredescribed in another work of the same authors [1].

As future work, it is intended to improve the module withnew features to overcome current limitations. Especial at-tention will be dedicated to the support of auxiliary con-nections and multiple controllers, which are considered asimportant features of OpenFlow version 1.3. In addition, itis intended to create a set of ns-3 tests to endorse the mod-ule validation, and also to evaluate its scalability in termsof the size of the simulated topology.

As OFSwitch13 is free software, contributions can also bemade by interested developers and users. Note that themodule offers support to OpenFlow 1.3 as a result of the of-softswitch13 library datapath implemented version. Oncethe library is updated to a newer OpenFlow protocol ver-sion (the latest version is 1.5.1 [18]), it would be possible toupdate de module to support the recent features.

6. ACKNOWLEDGMENTSThe authors would like to thank Vıtor Marge Eichem-

berger and Eder Leao Fernandes for their contributions tomodule design and implementation. They also would like tothank Capes and CNPq - Brazil, for the financial support(process 118198/2014-9).


39

7. REFERENCES[1] L. J. Chaves, V. M. Eichemberger, I. C. Garcia, and

E. R. M. Madeira. Integrating OpenFlow to LTE:some issues toward Software-Defined Mobile Networks.In International Conference on New Technologies,Mobility and Security (NTMS), pages 1–5, Paris,France, July 2015.

[2] E. L. Fernandes and C. E. Rothenberg. OpenFlow 1.3software switch. In Brazilian Symposium on ComputerNetworks and Distributed Systems (SBRC), pages1021–1028, Florianopolis, Brazil, May 2014.

[3] R. R. Fontes, S. Afzal, S. H. B. Brito, M. A. S. Santos,and C. E. Rothenberg. Mininet-WiFi: Emulatingsoftware-defined wireless networks. In InternationalConference on Network and Service Management(CNSM), pages 1–6, Barcelona, Spain, November2015.

[4] GSoC 2010 OpenFlow. Available at:http://www.nsnam.org/wiki/GSOC2010OpenFlow.

[5] IEEE Standard for Local and metropolitan areanetworks: Media Access Control (MAC) Bridges.IEEE Std 802.1D-2004 (Revision of IEEE Std802.1D-1998), IEEE Computer Society, 2004.

[6] Mininet: An instant virtual network on your laptop(or other PC). Available at: http://www.mininet.org.

[7] ns-3 Network Simulator. Available at:http://www.nsnam.org.

[8] OpenFlow 1.3 module for ns-3. Available at:http://www.lrc.ic.unicamp.br/ofswitch13.

[9] OpenFlow 1.3 module for ns-3 API documentation.Available at: http://www.lrc.ic.unicamp.br/ofswitch13/doc/html/index.html.

[10] OpenFlow 1.3 software switch. Available at:http://cpqd.github.io/ofsoftswitch13/.

[11] OpenFlow 1.3 software switch for ns-3. Available at:https://github.com/ljerezchaves/ofsoftswitch13.

[12] N. McKeown, T. Anderson, H. Balakrishnan,G. Parulkar, L. Peterson, J. Rexford, S. Shenker, andJ. Turner. OpenFlow: Enabling innovation in campusnetworks. ACM SIGCOMM ComputerCommunication Review, 38(2):69–74, April 2008.

[13] The NetBee library. Available at:http://www.nbee.org/doku.php.

[14] Open Networking Foundation. Software-DefinedNetworking: The new norms for networks. WhitePaper, 2012.

[15] Open Networking Foundation. OpenFlow enabledmobile and wireless networks. Solution Brief, 2013.

[16] OpenFlow 0.8.9. OpenFlow switch specification v0.8.9.ver. 0.8.9, Open Networking Foundation, 2008.

[17] OpenFlow 1.3.5. OpenFlow switch specification.OpenFlow Spec v1.3.5, Open Networking Foundation,2015.

[18] OpenFlow 1.5.1. OpenFlow switch specification.OpenFlow Spec v1.5.1, Open Networking Foundation,2015.

[19] F. Risso and M. Baldi. NetPDL: An extensibleXML-based language for packet header description.Computer Networks, 50(5):688–706, 2006.


40

Documents

OFSwitch13: Enhancing ns-3 with OpenFlow 1.3 Supportstatic.tongtianta.site/paper_pdf/c47ad942-1bd5-11e9-bccd-00163e08… · forward software tool is Mininet [6]. It is an open-source