invited survey paper a survey on openflow technologies

IEICE TRANS. COMMUN., VOL.E97–B, NO.2 FEBRUARY 2014375

INVITED SURVEY PAPER

A Survey on OpenFlow Technologies

Kazuya SUZUKI†a), Member, Kentaro SONODA††, Nobuyuki TOMIZAWA†, Yutaka YAKUWA†,Terutaka UCHIDA†††, Yuta HIGUCHI†††, Nonmembers, Toshio TONOUCHI†,

and Hideyuki SHIMONISHI†, Members

SUMMARY The paper presents a survey on OpenFlow related tech-nologies that have been proposed as a means for researchers, network ser-vice creators, and others to easily design, test, and deploy their innovativeideas in experimental or production networks to accelerate research activi-ties on network technologies. Rather than having programmability withineach network node, separated OpenFlow controllers provide network con-trol through pluggable software modules; thus, it is easy to develop newnetwork control functions in executable form and test them in productionnetworks. The emergence of OpenFlow has started various research activi-ties. The paper surveys these activities and their results.key words: OpenFlow, software-defined networking, network virtualiza-tion

1. Introduction

The Internet has evolved to accommodate a variety of ser-vices, including real-time voice communications (IP tele-phony), IP-TV, on-line banking, sensor networking, andcontent delivery, as well as computer-to-computer commu-nication. These services impose very diverse demands onnetworks. For example, real-time video delivery requireshigh bandwidth and a low packet loss rate, whereas non-real-time video delivery requires best-effort performanceand high network bandwidth. This diversity strains the cur-rent network paradigm especially when it comes to the pro-vision of quality of service (QoS), mobility, security, andtraceability.

Indeed, traditional network technologies, such as Eth-ernet or IP, face a challenge that makes it hard for them toevolve or accommodate new services and technologies, andmuch effort has been made to accelerate the development ofinnovative network technologies. This new era of networkresearch has already seen the creation of a number of initia-tives focused on the “Future Internet”. The main motivationof these initiatives is to give researchers, network servicecreators, network operators, equipment vendors, and othersa way of easily developing, testing, and deploying their in-novative ideas in a large network infrastructure. These ini-tiatives include the National Science Foundation’s Future

Manuscript received June 25, 2013.Manuscript revised October 19, 2013.†The authors are with the Knowledge Discovery Research Lab-

oratories, NEC Corporation, Kawasaki-shi, 211-8666 Japan.††The author is with the Cloud System Research Laboratories,

NEC Corporation, Kawasaki-shi, 211-8666 Japan.†††The authors are with the Optical IP Development Division,

NEC Corporation of America, California, USA.a) E-mail: [email protected]

DOI: 10.1587/transcom.E97.B.375

Internet Design (FIND) [1] and Future Internet Architecture(FIA) [2], as well as the European Commission’s SeventhFramework Programme (FP7) [3]. Large-scale testbed fa-cilities have also been funded to accelerate the related re-search. They include the Global Environment for NetworkInnovations (GENI) [4] project sponsored by the NationalScience Foundation and the Japan Gigabit Network (JGN-X) [5] testbed sponsored by the National Institute of Infor-mation and Communications Technology.

Network virtualization technologies, such as the slice-based facility architecture [6], have enabled researchers toshare testbeds at the same time. Rather than a single unifiednetwork substrate having a common set of control mecha-nisms applied to all applications or users that share the net-work substrate, this technology aims at creating multiplenetwork “slices” having different control mechanisms fordifferent users or applications. Virtualization technologiesenable an evolutionary cycle in which a variety of virtualnetworks are easily created, some of which will soon dis-appear and some of which will be widely used. This birth-and-death and natural selection process help to ensure thecontinuous evolution of network architectures.

To accelerate this process, technologies that separatecontrol and forwarding have been proposed [7]–[9]. Theyprovide programmability in separate controllers rather thanwithin each network node. This has enabled the controlplane to independently evolve; the resulting short evolution-ary cycle has led to a wide variety of control algorithms be-ing developed. In contrast, the data plane has a relativelylong evolutionary cycle and its developments are aimed atfaster packet delivery. OpenFlow is the most popular ofthese technologies and is used in large network testbeds likeGENI and JGN-X.

OpenFlow defines atomic operations of an OpenFlow-enabled switch to handle flows and an interface for instruct-ing such operations from a separate controller. As Open-Flow defines a flow as a set of arbitrary combinations ofpacket header fields, it can be applied to flow-based fine-grained control as well as to aggregated control using a des-tination address or tunnel label. Researchers can easily de-sign, test, and deploy their innovative ideas in experimen-tal or production networks with these OpenFlow features.Programming at a (possibly centralized) controller improvessuch research productivity. Network research that exploitsOpenFlow can be found everywhere. For example, we pro-posed a new network architecture based on OpenFlow [10].

Copyright c© 2014 The Institute of Electronics, Information and Communication Engineers

376IEICE TRANS. COMMUN., VOL.E97–B, NO.2 FEBRUARY 2014

There has also been a lot of research on applying OpenFlowto data center networks, enterprise networks, besides carriernetworks.

This paper surveys various research projects on Open-Flow technologies. The standardized OpenFlow specifica-tions are presented in Sect. 2. After that, a survey of re-search is presented on applying OpenFlow to data centernetworks (Sect. 3), carrier networks (Sect. 4), and networksecurity (Sect. 5). Section 6 presents platforms and frame-works for developing OpenFlow controllers, and surveys re-search on verifying, testing, and debugging the developedcontrollers. Section 7 concludes the paper.

2. Overview of OpenFlow

2.1 OpenFlow Specification

Here, we explain the standardized OpenFlow specifica-tions [11], which mainly define the behavior of Open-Flow switches and the OpenFlow protocol that controlsthese OpenFlow switches. We briefly introduce OpenFlowswitches and the OpenFlow protocol.

OpenFlow switches separate the forwarding elementfrom the control element, whereas conventional switcheshave both control and forwarding elements (Fig. 1). Theseparated control element is called an OpenFlow controller.An OpenFlow controller connects OpenFlow switches withTCP or the transport layer security (TLS) [12].

An OpenFlow switch has a flow table for storing a setof flow entries; each flow entry consists of header fields,counters, and a set of actions to apply to matching pack-ets. Header fields, which consist of the 12-tuples listedin Table 1, are used for matching packets. A header fieldcan also be specified as a wildcard, in which case the otherfields are only used for matching. For example, the “incom-ing port number is 1, and the destination MAC address isFF:FF:FF:FF:FF:FF” and the “L4 protocol is TCP, and thedestination port number is 80” can be specified as headerfields. Actions specify the operations to be applied to pack-ets that match header fields. The specifications define the ac-tions in Table 2. A flow entry can include multiple actions,e.g., “after rewriting the source IP address, output from aspecified port” and “after outputting from a specified port,and output from another port”.

As outlined in Fig. 1, the OpenFlow protocol is usedby the controller to control switches. The OpenFlow proto-col utilizes the messages summarized in Table 3. The mostdistinctive messages are explained below.

Packet In This message is used for sending a packet re-ceived by the switch to the controller, when there is nomatch in the flow table for that packet. The controllercan use this message to create flow entries based on apacket received by the switch.

Packet Out This message is used for sending a packet fromthe controller to the switch. For example, a controlleruses this message when it wants to output a packet cre-ated by itself from the switch, or when a packet in a

Fig. 1 Separation of forwarding and control.

Table 1 Header fields.

FieldIngress portEthernet source addressEthernet destination addressEthernet typeVLAN IDVLAN priorityIP source addressIP destination addressIP protocol numberIP ToS bitsTransport source port/ICMP typeTransport destination port/ICMP code

Table 2 Actions.

Action DescriptionForward Forward a packet to a given portEnqueue Forward a packet through a given queueDrop Drop a packetModify-Field Rewrite header fields

“Packet In” message wants to be resent to an actualdestination.

Flow Mod This message is used for sending flow entriescreated by the controller to the switch. The flow en-tries contain two timers for hard timeout and idle time-out. A flow entry with a hard timeout is removed aftera specified time elapses from its installation. A flowentry with an idle timeout is removed if the flow entrywas not referred for the specified time.

Flow Removed The switch informs the controller when aflow entry is removed from its flow table for some rea-son. The message includes statistical information, e.g.,the reference counter and lifetime of the removed flowentry.

Barrier Request/Reply Switches that received a “FlowMod” or “Packet Out” message do not report the com-pletion of their operations to the controller. If the con-troller needs to know whether they are complete, itsends a “Barrier Request” message to the switch. Af-ter receiving a “Barrier Request” message, the switchcompletes the pending operations, which it receivedbefore the message, and then sends a “Barrier Reply”message.

SUZUKI et al.: A SURVEY ON OPENFLOW TECHNOLOGIES377

Table 3 OpenFlow messages.

Message DescriptionMessages sent from controller to switchPacket Out Send packets for output from given portFlow Mod Send flow entries for setting flow table in switchPort Mod Change state of given portSet Config Set configuration parameters in switchMessages to request from controller and reply by switchFeatures Request/Reply Retrieve capabilities supported by switchStats Request/Reply Collect statistics in switchGet Config Request/Reply Query configuration parameters in switchBarrier Request/Reply Confirm completion of operations requested by controllerQueue Get Config Request/Reply Query queue configurationsMessages sent from switch to controllerPacket In Send packets received by switchFlow Removed Inform that flow entry expiredPort Status Inform change in port statusMessages sent from both controller and switchHello For connection setupEcho Request/Reply Confirm liveness of controller-switch connectionError Inform of any errorsVendor For vendor-defined uses

2.2 Design Variations

The OpenFlow specifications are flexible enough to supportmany design variations in the behavioral model.

The OpenFlow protocol supports the programming ofvarious switch behaviors at the flow level. A flow, on whicha control is based, can be flexibly defined using arbitraryparts of a packet header, whereas classical switches androuters only use specific parts of the header. A flow can befine grained by defining a flow with a combination of multi-ple parts of a header, or aggregated by defining a flow withonly a specific part of a header. For example, a flow can bedefined as a TCP/IP session or a tunnel. Various behaviorscan be defined for a flow, e.g., sending its packets to specificports, discarding its packets, and modifying specific headerfields. Therefore, the behaviors of OpenFlow switches arenot limited by the classical layered architecture and can bemade up of arbitrary combinations of flow definitions andbehavioral definitions. For example, a flow having a spe-cific destination IP address can be destined to a specific portafter rewriting the source and destination MAC headers. Inthis case, the switch behaves like an IP routers for the flow.Another example is defining a flow to be a specific TCP/IPsession and instructing its packets to be discarded. In thiscase, the switch behaves like a router with ACLs (AccessControl Lists) or a firewall.

As can be seen in Fig. 2, user programs on the con-troller can perform various network control tasks, includ-ing routing, path management, and access control, and theyadd flow entries to the flow tables in the switches. When apacket arrives at a switch, the switch searches for a flow en-try matching the packet and performs the actions specifiedby the entry. This behavior can be reactive, i.e., dynamicallyinjecting flow entries when a new flow arrives at the switch,or proactive, i.e., statically injecting flow entries in advanceinto the arriving packets.

Fig. 2 OpenFlow architecture

Fig. 3 Multiple controllers

An OpenFlow controller can be centralized by havinga control server control all the switches, as shown in Fig. 2.Otherwise, multiple controllers can be deployed to coopera-tively control the network for scalability, as shown in Fig. 3.


3. Data Center Networks

Data centers are used in various network services. However,data center networks built with conventional technologiesare confronted with many problems, e.g., limits on scala-bility, virtualization, and configurability. Many researchershave undertaken studies in the hopes of solving these prob-lems by using OpenFlow. This section introduces this re-search.

3.1 Topology

The fat tree in Fig. 4 is an attractive topology for data centernetworks. Conventional ethernet networks require loop-freetopologies like trees. Tree topologies have characteristicsthat most traffic is concentrated at core switches, and thesecore switches require high capacity. Al-Fares et al. [13] ap-plied the fat tree topology to data center networks. Sincefat trees involve a multi-rooted topology, they can make thetraffic share multiple core switches that are composed oflow-capacity commodity hardware. The fat tree topologyincludes loop paths, and this requires a forwarding methodthat differs from the learning-based forwarding method ofthe conventional ethernet. Some researchers [14], [15] haveproposed forwarding methods that use OpenFlow.

Portland [14] is a loop-free forwarding method on thefat tree topology using OpenFlow. The method for loop-freeforwarding creates a pseudo-address encoding a forwardingpath, which is called a pseudo-MAC (PMAC) address, andembeds it into the MAC address field in the packet. How-ever, modifying MAC addresses forces end hosts to changetheir MAC addresses. To avoid this, the method makes edgeswitches translate between an actual MAC (AMAC) addressand a PMAC address.

A forwarding method that requires the switch to havea large forwarding state capacity limits the scale of an L2network. Portland relaxes this limitation by using PMACaddresses, which have hierarchical location information en-coded into their prefixes. Encoding is designed to enablemembership testing of an address to a switch subtree byprefix matching with a switch ID. Loop-free forwarding can

Fig. 4 Fat tree topology

then be implemented by forwarding packets up toward theroot until they become members of the switch subtree andstart forwarding down to the end host. PMAC forwardingcan only be implemented using forwarding states that areproportional to the number of ports on a switch.

Portland places a manager, which intercepts all ARPrequests and responds to them. To enable switches to for-ward packets with PMAC addresses instead of AMAC ad-dresses, the manager replies with a PMAC address. Thesender host sends a packet whose destination address is thereplied PMAC address, and the switches forward the packetto an edge switch connected to the actual destination host.To ensure that the destination host remains unaware that theMAC address of the packet differs from the actual addressof the host, the edge switch rewrites the destination MACaddress of the packet from a PMAC address to an AMACaddress and sends the packet to the destination host. Themanager is implemented as part of the OpenFlow controller.

Tavakoli et al. [15] estimated the number of flow en-tries installed in the switches in data center networks thatuse Portland. In their study targeting data center networkswith 10K servers in 5000 racks, core switches needed 5000entries (the most of all switches of the network). Be-cause Portland uses location-based forwarding, the numberof flow entries in the core switches is at most the numberof top-of-rack (ToR) switches. The authors explained that,since this number is not much different from the number ofaccess control lists supported by commodity conventionalswitches, Portland is applicable to large-scale data centers.

Heller et al. [16] proposed ElasticTree, which is a man-agement method to reduce energy consumption in data cen-ter networks. It manages power consumption by dynami-cally turning switches on or off in response to changes innetwork usage. It determines whether switches are turnedon or off by referring to multiple parameters such as topol-ogy, traffic, power models of switches, and fault toleranceproperties. OpenFlow controllers install flow entries intothe turned-on switches according to the results.

3.2 Scalability

Pries et al. [17] evaluated the performance of controllersthat manage data center networks by using flow inter-arrivaltimes measured by Benson et al. [18] at actual data centers.Their evaluations demonstrated that a centralized controllercould control not only campus-wide networks but also datacenter networks. Since data center networks need to han-dle a huge number of flows over the processing capacity ofthe centralized controller, this causes data losses and longsojourn times in the controller.

DIFANE [19] is an architecture for distributed flowmanagement that hierarchically distributes rules to switchesand handles all data traffic in the fast path. The rules repre-sent flow entries for forwarding or blocking specified flows.In the architecture, the OpenFlow controller makes flows hiton the OpenFlow switches as much as possible. It can han-dle wildcard rules and react quickly to network dynamics


such as changes to the network access policy or topology.Yeganeh et al. [20] proposed Kandoo, a hierarchical

method of controlling OpenFlow networks. The method de-ploys hierarchical OpenFlow controllers, local controllers,and a root controller. The local controller manages a groupof switches and links between these switches, and it pro-cesses only local events, such as the arrival of traffic frominside the group or an inside link-down of the group. Theroot controller manages all local controllers and only han-dles events necessary for processes, such as the arrival oftraffic at switches managed by different local controllers ora link-down between switches of different groups.

Macapuna et al. [21] tried to improve the scalability ofcontrollers with a bloom filter, which is a probabilistic datastructure for efficiently storing members of a set. They usedthe bloom filter to indicate a set of switches through whicha packet goes. Their method separates the control of ToRswitches from that of core switches, aggregate switches,etc., in order to achieve scalability. When a new flow ar-rives, the rack manager, which is an OpenFlow controllermanaging a ToR switch, calculates the end-to-end path andgenerates a bloom filter that includes switches along withthe path. The rack manager then installs a flow entry to em-bed the bloom filter in the MAC address fields of the arrivedpackets. Flow entries created from the relationship betweenneighboring switches and output ports are proactively in-stalled in the core and aggregate switches. A core or aggre-gate switch that has received a packet searches the bloomfilter embedded in the MAC address field for a neighboringswitch and forwards the packet to the neighboring switch.Their method makes each rack manager only control its cor-responding ToR switch. As a result, their method, which isscalable, can be applied to large-scale data centers. Similarapproaches have been taken by other researchers [14], [22].

3.3 Virtualization

Modern data centers need to accommodate large numbersof tenants that have isolated and independent networks. Vir-tual networks that are composed over physical networks areused to flexibly configure these networks of tenants. Thusfar, VLAN tagging [23] has been widely used for creatingvirtual networks. However, the VLAN headers defined by[23] have a 12-bit tag field for identifying virtual networks,and so only 4094 networks can be created. However, virtualnetworks that overcome these limitations can be created byOpenFlow [24]. Because an OpenFlow controller can lookin a “Packet In” message including a received packet, it candecide which virtual network the packet belongs to by in-coming port or MAC address of the packet. Therefore, theOpenFlow controller can create virtual networks without us-ing VLAN tagging.

The above research [24] could only be applied tonetworks consisting of OpenFlow switches. Barabash etal. [25] proposed a virtualized method by using an overlay-ing approach that utilizes tunnels between edge switchesthat connect virtual machines on a server with a physical

network in order to achieve virtualization on existing physi-cal networks. Packets forwarded to tunnels are encapsulatedinto tunnel headers and delivered over the underlying phys-ical network. Their approach can be applied to an existingnetwork without having to deploy any new facilities.

OpenFlow is useful (but not necessary) in the overlayapproach. Pettit et al. [26] stated the importance of edgeswitching. The overlay approach is required to manage therelationship between overlay networks composed of tunnelsand virtual machines that act on multiple servers at a datacenter. Their research revealed that a centralized OpenFlowcontroller can manage the relationship by controlling theedge switches on each server.

It is important to monitor virtual networks. Becausemore than one virtual network can be set up over one phys-ical network, the performance of one virtual network willinfluence the others. In order to manage their performance,they need to be monitored. Monitoring is especially im-portant in a data center network in which virtual networksare assigned to different customers. Argyropoulos et al. [27]proposed PaFloMon, a method of monitoring traffic throughvirtual networks. The monitoring database server is de-ployed in the OpenFlow network, and it collects monitor-ing data by using various protocols, i.e., sFlow, SNMP, andOpenFlow.

4. Carrier Networks

Some research projects have started to apply OpenFlow tocarrier networks. Most carrier networks use IP and multi-protocol label switching (MPLS) [28] to forward traffic totheir customers. Any new technologies for carrier networksare required to be able to work along with these forward-ing mechanisms. Much of the OpenFlow research on car-rier networks has focused on practical uses of MPLS/IPnetworks. This section surveys the OpenFlow research onMPLS and IP networks.

4.1 MPLS

Das et al. [29] tried to simplify the control of MPLS net-works by using OpenFlow. Since conventional MPLS net-works are large autonomous distributed systems, they re-quire many control protocols. For example, each node ina MPLS network utilizes OSPF [30] to collect topology andbandwidth information about the network. When a labelswitch path is created, MPLS nodes use the signaling pro-tocol, e.g., LDP [31] or RSVP-TE [32]. Das et al. claimedthat a centralized control plane attained by OpenFlow makesthese protocols unnecessary.

Early work on OpenFlow MPLS [33] involved extend-ing OpenFlow specifications to MPLS nodes. OpenFlowversion 1.0 specifications that target data center networksdo not support MPLS. Kempf et al. proposed that three ex-tensions are needed for this purpose.

1. Extending header fields to identify MPLS labels,


2. Adding new actions to push, pop, and swap MPLSshim headers, and

3. Adding virtual ports and tables for the virtual port.

These extensions were later included in the OpenFlow ver-sion 1.1 specifications [34].

Ferkouss et al. [35] proposed to use OpenFlow tochange the roles of MPLS nodes. MPLS nodes play dif-ferent roles depending on their positions in the network.

• Label edge router (LER), which is an MPLS nodeplaced on the network border, classifies a receivedpacket into a Forwarding Equivalence Class (FEC) andadds an MPLS shim header with a label assigned toeach FEC to the packet.• Label switch router (LSR), which is in the network

core, swaps labels in a received packet and forwardsit.• Egress LERs have to remove the MPLS shim header

from a received packet and to forward the packetthrough standard routing operations. In order to re-duce the load on the egress LER, the LSR positionedone hop before the LER removes MPLS shim headerfrom a received packet and sends it to the LER. Thefunction of the LSR is called Penultimate Hop Popping(PHP), and it lets the LER do only the standard routingoperations.

Ferkouss et al. stated that OpenFlow control could be usedto make an MPLS node able to assign the above roles. Thiswould make it easy to add (remove) nodes to (from) net-works and to connect two MPLS networks. For example, anMPLS node assigned to LSR could install flow entries forforwarding packets in the network. More specifically, theflow entry would consist of match fields including the MPLSlabel and actions for swapping the MPLS label, decrement-ing an MPLS-TTL value, and outputting the packet. An-other example is when an MPLS node is assigned to theingress LER. The flow entry installed to the MPLS nodes in-cludes match fields to identify the arrived packets as a flow(fine-grained or aggregated, as mentioned in 2.2) and actionsfor pushing an MPLS label and outputting the packets.

Path computation element (PCE) technology [36],which can control networks in a centralized way like Open-Flow, calculates an end-to-end path over multiple domainswithout their sharing internal topology information. PCEsdeployed in each domain calculate an internal path that ispart of the end-to-end path by using internal topology in-formation collected by routing protocols such as OSPF. OnePCE gathers the internal paths from the other PCEs and usesthat information to determine an end-to-end path. The end-to-end path is then set up by using a signaling protocol suchas RSVP-TE.

Giorgetti et al. [37] compared PCE and OpenFlowtechnologies by conducting a simulation of single-domainMPLS networks. The results of the path creation timeshowed that OpenFlow can create a path faster than PCE canbecause the signaling protocol takes more time for setting up

a path calculated by PCE. On the other hand, an OpenFlowcontroller only sends flow entries directly to switches on thecalculated path.

Although Giorgetti et al. presented only advantage ofOpenFlow technologies, they have also disadvantage. Forinstance, PCE technology is designed to be utilized with ex-isting routing and signaling protocols for MPLS networks.RSVP-TE has a function to determine whether a createdpath is available or not. In contrast, if MPLS networksare to be controlled by OpenFlow, the controller itself musthave functions to collect topological information and main-tain the created paths. As the size of the network increases,the load of these functions increases. Consequently, net-work operators hoping to use an OpenFlow controller mustknow the size of the network that the OpenFlow controllercan control.

4.2 IP Networks

RouteFlow [38], previously called QuagFlow [39], is anopen source project to provide virtualized IP routing ser-vices over OpenFlow networks. An OpenFlow controllerneeds to collect route information through routing proto-cols, e.g., OSPF or BGP [40]. For this purpose, RouteFlowprepares a virtual machine (VM) to run the routing engineand relates a physical interface with an interface of the VMto enable communication between the routing engine andneighbors. It thereby conserves on the labor involved intightly integrating a routing engine into the OpenFlow con-troller. The OpenFlow controller of RouteFlow retrieves theroute information from the VM and creates flow entries forIP routing services based on the collected information.

Kotani et al. [41] proposed multicast tree managementfor reliable streaming. It takes a lot of time to reconstructmulticast trees in traditional networks when a switch fail-ure or a link failure occurs because multicast trees cannotbe reconstructed until the unicast paths are stabilized. Insuch situations, significant packet losses, and, say, degradedvideo quality, cannot be avoided. One approach to solvingthis problem is to use redundant trees, but it is very hard tocompute redundant trees in a distributed way. The proposedcontroller allows redundant multicast trees under IP multi-cast protocols. Kotani et al. devised an OpenFlow controllerthat supports IP multicast protocols; e.g., it snoops IGMPmessages to manage multicast recipient groups, and it pro-vides a method to set up multiple multicast trees for fast treeswitching.

5. Security

Network security is becoming one of the hottest topics inOpenFlow research. The research can mostly be classifiedinto two categories: network access control and attack de-tection and defense. This section introduces important re-search in these categories.


5.1 Network Access Control

Some of the research on access control uses OpenFlow tooversee network access policies. It aims at automating theisolation and configuration of complex physical and virtualnetworks. Centralized control by an OpenFlow controllerprevents unauthorized access and information from beingleaked because of misconfigurations by network adminis-trators.

Casado et al. [42] proposed Ethane, an access controlfor enterprise networks by a centralized controller. Thecontroller manages high-level global policies and translatesthem into local policies configured to individual switches.All these policies are expressed in groups and have rules.The groups are lists of users and services, e.g., http servicesof servers. The rules are permissions per service for eachgroup. These policies are described in the original descrip-tion language. Although Ethane itself does not uses Open-Flow, the following research using OpenFlow is based onthe concept of Ethane.

Kim et al. [43] proposed Lithium, a method of event-driven access control for campus and home networks. Traf-fic patterns in campus networks are subject to time consid-erations, e.g., when the semester starts. Lithium defines apolicy in four domains, i.e., time, users, flows and history,which are past traffic patterns, in order to control access ac-cording to the situation, e.g., time and traffic patterns. Themethod allows network operators to specify the policies andcontrol flows according to the situation.

Watanabe et al. [44] proposed a method of roaming be-tween campuses with flexible access control by using Open-Flow. Suppose that visitors attempt to access the networkor the system of a campus. Their system obtains an ac-cess policy defined for each user from the policy databaseof their affiliation and installs flow entries for access con-trol based on that policy. This is a flexible access control;e.g., permission could be granted for visiting researchers toaccess certain systems on campus during a conference forattendees by interworking between OpenFlow and the au-thentication system. Suenaga et al. [45] proposed a similarmethod to enable OpenFlow networks and Shibboleth [46],which is authentication system for single sign-on, to cooper-ate and make it possible for users to connect to applicationsbetween organizations.

5.2 Detection of Attacks and Defense Against Them

OpenFlow enables controllers to inspect all packets that ar-rive at networks and to make switches drop suspicious pack-ets. This feature of OpenFlow can be put to good use in de-tect and defense against attacks. This subsection describesthe research on using OpenFlow in this way.

Yao et al. [47] proposed VAVE, a method to protectagainst IP spoofing. VAVE embeds a source address val-idation module in an OpenFlow controller. The modulehooks the “Packet In” messages and checks a white list of

valid source addresses. To reduce the processing load, themethod installs filtering rules for detecting and dropping in-valid packets in the switches in advance.

Shin et al. [48] proposed CloudWatcher, anothermethod of network security that differs from VAVE. TheOpenFlow controller in their approach does not have any se-curity modules, but instead has existing security appliances,such as intrusion detection systems. The OpenFlow con-troller captures packets that arrive at the network and for-wards them into the security appliances that inspect all ofthem. CloudWatcher has a simple policy language to helpnetwork operators describe policies.

FRESCO [49] is a framework for the controller to eas-ily implement security applications. In contrast with theother frameworks described in 6.1, FRESCO provides de-velopers with an original scripting language to easily im-plement security modules for detection, protection, etc.FRESCO has a resource controller that manages flows en-tering the switches. If a flow table in which a security mod-ule has attempted to install a flow entry is full, the resourcecontroller executes garbage collection on unimportant flowentries that were not installed by security modules.

Instead of the OpenFlow controller, OpenFlowswitches can be used to inspect packets. Kumar et al. [50]proposed that OpenFlow switches be equipped with a func-tion to detect intrusions. The switches have a flow table,which differs from the usual flow tables of standard Open-Flow switches, that contains a blacklist of source IP ad-dresses and signatures of various attacks. The switchescheck ingress packets against the blacklist and signaturesbefore looking at the usual flow tables, and they drop anyanomalous packets that they discover.

6. Developing Controllers

OpenFlow is the first standard that has been accepted byboth academia and industry for programmable networks.We can automate network control and management pro-cesses by using OpenFlow technology. However, the Open-Flow protocol controls the forwarding of packets, and itslevel seems to be too low for advanced network program-ming. Although we need a more advanced, productive pro-gramming foundation for network programming, OpenFlowis at present immature in this regard. Bugs will be inevitableif networks become dynamically programmable and config-urable with software. Therefore, it is also important to pro-vide various “debugging” techniques/methods for networkoperators and network programmers to make software de-fined networking more reliable. However, the networks inuse today do not have any systematic approaches to makingthemselves more reliable.

There is, however, research on “programmable net-works” (e.g., [51], [52]). Moreover, there is research onverification of network protocols [53], network configura-tions [54], implementation of network stacks [55] and dis-covery of network security vulnerabilities [56]. Moreover,with the spread of the OpenFlow protocol, research on pro-


Table 4 Platforms of the OpenFlow controller.

Platform Language Major contributorNOX[61] C++/Python NiciraPOX[61] Python James McCauleyFloodlight[62] Java Big Switch NetworksTrema[63] Ruby/C NEC

gramming, verifying, and debugging OpenFlow-based net-works has started accelerating. For example, McKeown [57]advocated the importance of formally verifying network be-haviors and systematically identifying bugs and their rootcauses. He also introduced his own group’s research on thistopic (header space analysis [58], automatic test packet gen-eration [59], and network debugger [60]).

This section mentions the currently available Open-Flow controller platforms of various open source projectsand reviews the following three topics of current research:

1. Higher-level programming languages and domain spe-cific languages (DSL) for OpenFlow,

2. Formal verification of OpenFlow network behaviors,and

3. Effective testing and trouble shooting techniques forOpenFlow networks.

6.1 Platform and Framework

There are various open source projects on making Open-Flow controller platforms for accelerating the developmentof controllers (Table 4).

NOX [64] is an OpenFlow controller platform support-ing C++ and Python. NOX is an early development, and itis widely used in many research projects. However, devel-opment of NOX itself has finished. A subsequent project,POX, which supports Python, is now under development.

Floodlight is a controller platform for Java languagethat has a modular architecture consisting of controller andapplication modules. The controller modules provide func-tions which a majority of applications commonly use, suchas those for discovering the network topology and control-ling switches with the OpenFlow protocol. The applicationmodules, which run with the controller modules, controlthe OpenFlow network as the user likes by giving them themeans to easily set up firewalls, learning switches, and soon. The modular architecture enables diverse applicationsto be executed simultaneously.

Unlike other OpenFlow controller platforms, Trema[65] focuses on productivity; it provides not only a platformfor OpenFlow controllers but also a modularized program-ming framework on top of it. Users can develop their ownOpenFlow controllers by combining multiple control mod-ules which they can develop themselves or obtain from oth-ers. In addition, Trema has an integrated network emulator,so that users can easily test the controllers they are develop-ing.

Section 5 presented various security research on us-ing OpenFlow. It is also important to ensure the security

of the OpenFlow controller itself. In particular, FortNOX[66] has a kernel module with its own security functions forrole-based authorization and conflict detection in flows cre-ated by NOX. The role-based authorization function strictlymanages the production of flows in compliance with rolessuch as operators, secure applications, and non-security-related OpenFlow applications. The conflict detection func-tion detects conflicts between rules defined by the admin-istrator and requests to add, delete or modify a flow fromNOX. A request is executed only if a conflict is not detected.

6.2 Higher Level Programming Language and DSL

The current mainstream OpenFlow controller platforms andframeworks (See 6.1) are based on event-driven styles thatmodel the OpenFlow protocol as an event stream. Althoughframeworks in this style that resemble early window sys-tem’s frameworks are easy to implement and enable fine-grained packet control over protocols, they are error-proneand hard to modularize except in small applications. Higherlevel programming languages or DSLs have recently beenproposed for making OpenFlow-based programming easierand modular. These are based on the programming languageconcepts of logic programming [67], [68], functional reac-tive programming [69], [70], and declarative policies [71].NetCore [72] and the hierarchical flow table (HFT) [73] arealso declarative languages for packet forwarding descrip-tions, but they focus on using formal semantics to verify thebehaviors of OpenFlow based systems.

6.3 Verification

Formal techniques are important because they can mathe-matically verify the “correctness” of OpenFlow controllerprograms and detect bugs in them. Substantial research hasbeen carried out in this direction. For example, McGeer [74]described a framework to deal with the verification problemwith OpenFlow networks as a satisfiability problem, and hediscussed its computational cost. Reitblatt et al. [75] pro-posed update mechanisms for flow tables in an OpenFlownetwork with consistency before and after updates, and theyformally proved the correctness of the mechanisms with atheorem prover called Coq. McGeer [76] proposed a sim-ilar update protocol for OpenFlow networks and manuallyproved it to be correct.

A number of tools have been developed to verify theproperties of controller programs. NICE [77] verifies aPython program executed on a NOX controller by usingmodel checking [78] (a technique for automatically verify-ing properties of a target system or software by representingthe target as a finite automaton and exhaustively exploringit) together with symbolic execution [79] (a technique foranalyzing a program to determine what inputs cause eachpart of it to execute by running the program with symbolicinputs and computing constraints to run each part). Verifi-care [80] translates a controller model written in VML, thelanguage of Verificare, into a model written in one or more


input languages of off-the-shelf model checkers and verifiesthe model with these checkers.

There are tools that collect messages passed inOpenFlow networks and that dynamically verify them.FlowChecker [81] extracts the slice policies of controllersand flow tables of switches in networks with FlowVisor,which models a state machine that encodes the entire behav-ior of switches as a binary decision diagram (BDD) and veri-fies properties written in temporal logic, e.g., computationaltree logic (CTL). VeriFlow [82] intercepts new rules sent toswitches from controllers, builds forwarding graphs basedon these rules, and explores them to check if any problemsoccur in the network after the rules are updated. Anteater[83] collects information on the network topology and de-vices’ forwarding information bases (FIBs), translates theminto a satisfiability problem (SAT) with an invariant to beverified, and checks if there are any potential bugs with anoff-the-shelf SAT solver.

Furthermore, the compilers of some of the languagesdescribed in 6.2 have been formally verified as to whetherthey generate “correct” operations. For instance, Coq hasbeen used to verify the translation rules of PANE [73], [84]’scompiler that generates operations from network policieswritten in the form of HFTs [73]. Guha et al. [85] used Coqto prove that the compiler of NetCore [72] is correct, andthey also verified the correctness of a NetCore run-time sys-tem.

6.4 Testing, Trouble Shooting and Debugging

Networks are inherently physically, geographically and or-ganizationally distributed systems of nodes and links thatface difficulties such as asynchronicity and partial failure.It is therefore hard to test, debug, and troubleshoot the net-works. In contrast, network operators and administratorsdo not have systematic techniques for accomplishing thesetasks. Although there does not seem to be any silver bul-let to solve this difficult problem, researchers have startedto develop techniques and tools for testing, troubleshooting,and debugging OpenFlow networks.

As previously noted, NICE [77] tries to verify or findbugs in controller programs. In contrast, SOFT [86] triesto test the interoperability of OpenFlow switches throughsymbolic execution, and OFTEN [87] tries to test (physical)OpenFlow switches in a test environment with a scenario-based dummy OpenFlow controller.

It is also important to generate test packets to checkwhether the physical network is working correctly. Auto-matic test packet generation (ATPG) [59] tries to minimizeautomatically generated, periodically sent test packets forphysical network testing with header space analysis [58].

Simulation is a traditional networking technique, espe-cially for traffic engineering. Jin et al. [88] tried to extendtheir discrete time network simulator testbed with virtual-machine based emulation and parallel simulation to supportOpenFlow.

It is also a hard task to troubleshoot running net-

works and large data centers. OFRewind [89] introduceda record/replay debugging mechanism into the OpenFlownetwork. The SDN trouble shooting simulator (STS) [90] isa similar trouble shooting tool that uses delta debugging tominimize ‘input’ data that reproduced invalid statuses. Thenetwork debugger (NDB) [60] enables operational Open-Flow networks to have breakpoint capabilities.

7. Conclusion

We introduced the various studies on OpenFlow technolo-gies. After presenting standardized OpenFlow specifica-tions, we surveyed research on applying OpenFlow to datacenter networks, carrier networks, and network security.Since it is important to develop controllers that effectivelyutilize OpenFlow, we presented platforms and frameworksto develop OpenFlow controllers and surveyed research onverifying, testing and debugging the developed controllers.

Although OpenFlow is a novel technology for control-ling networks and has many distinctive features, conven-tional technologies can do most of what OpenFlow can do.Therefore, it is worthless to simply replace conventionalnetworks with OpenFlow networks. It is important for re-searchers to have viewpoints as to how OpenFlow can be uti-lized to solve problems. We summarized these viewpointsand hope that this paper will be useful in future research.

Acknowledgements

This work was partly supported by the Ministry of InternalAffairs and Communications, Japan.

References

[1] “FIND (Future Internet Design).” http://www.nets-find.net/[2] “NSF Future Internet Architecture Project.” http://www.nets-fia.net[3] “Seventh Framework Programme (FP7).” http://cordis.europa.eu/

fp7/home en.html[4] “The Global Environment for Network Innovations (GENI).”

http://www.geni.net/[5] “New Generation Network Testbed JGN-X.” http://www.jgn.nict.go.

jp/english/[6] L. Peterson, S. Sevinc, J. Lepreau, R. Ricci, J. Wroclawski,

T. Faber, and S. Schwab, “Slice-based facility architecture,”Tech. Rep., http://svn.planet-lab.org/attachment/wiki/GeniWrapper/sfa.pdf, 2009.

[7] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar,L. Peterson, J. Rexford, S. Shenker, and J. Turner, “OpenFlow: En-abling innovation in campus networks,” ACM SIGCOMM Com-puter Communication Review, vol.38, no.2, pp.69–74, 2008.

[8] N. Feamster, H. Balakrishnan, J. Rexford, A. Shaikh, and J. VanDer Merwe, “The case for separating routing from routers,” Proc.ACM SIGCOMM Workshop on Future directions in network archi-tecture, pp.5–12, 2004.

[9] M. Casado, T. Garfinkel, A. Akella, M.J. Freedman, D. Boneh,N. McKeown, and S. Shenker, “SANE: A protection architecturefor enterprise networks,” USENIX Security Symposium, 2006.

[10] H. Shimonishi, S. Ishii, S. Lei, and Y. Kanaumi, “Architecture,implementation, and experiments of programmable network usingOpenFlow,” IEICE Trans. Commun., vol.E94-B, no.10, pp.2715–2722, Oct. 2011.


[11] “OpenFlow Switch Specication Version 1.0.0 (Wire Protocol 0x01).”OpenFlow Switch Consortium, 2009.

[12] T. Dierks and E. Rescorla, “The Transport Layer Security (TLS)Protocol Version 1.2,” RFC 5246, Internet Engineering Task Force,2008.

[13] M. Al-Fares, A. Loukissas, and A. Vahdat, “A scalable, commod-ity data center network architecture,” ACM SIGCOMM ComputerCommunication Review, vol.38, no.4, pp.63–74, 2008.

[14] R. Niranjan Mysore, A. Pamboris, N. Farrington, N. Huang, P. Miri,S. Radhakrishnan, V. Subramanya, and A. Vahdat, “PortLand: Ascalable fault-tolerant layer 2 data center network fabric,” ACMSIGCOMM Computer Communication Review, vol.39, no.4, pp.39–50, 2009.

[15] A. Tavakoli, M. Casado, T. Koponen, and S. Shenker, “ApplyingNOX to the datacenter,” Proc. 8th ACM Workshop on Hot Topics inNetworks (HotNets-VIII), 2009.

[16] B. Heller, S. Seetharaman, P. Mahadevan, Y. Yiakoumis, P. Sharma,S. Banerjee, and N. McKeown, “ElasticTree: Saving energy in datacenter networks,” Proc. 7th USENIX Symposium on NetworkedSystems Design and Implementation (NSDI’10), p.17, 2010.

[17] R. Pries, M. Jarschel, and S. Goll, “On the usability of OpenFlow indata center environments,” Proc. IEEE International Conference onCommunications (ICC), pp.5533–5537, 2012.

[18] T. Benson, A. Akella, and D.A. Maltz, “Network traffic characteris-tics of data centers in the wild,” Proc. 10th ACM SIGCOMM Con-ference on Internet Measurement (IMC), pp.267–280, 2010.

[19] M. Yu, J. Rexford, M.J. Freedman, and J. Wang, “Scalable flow-based networking with DIFANE,” ACM SIGCOMM ComputerCommunication Review, vol.41, no.4, pp.351–362, 2011.

[20] S.H. Yeganeh and Y. Ganjali, “Kandoo: A framework for effi-cient and scalable offloading of control applications,” Proc. ACMWorkshop on Hot Topics in Software Defined Networks (HotSDN),pp.19–24, 2012.

[21] C.A. Macapuna, C.E. Rothenberg, and M.F. Magalhaes, “In-packetBloom filter based data center networking with distributed Open-Flow controllers,” Proc. GLOBECOM Workshops, pp.584–588,2010.

[22] Y. Chiba, Y. Shinohara, and H. Shimonishi, “Source flow: Handlingmillions of flows on flow-based nodes,” ACM SIGCOMM Com-puter Communication Review, vol.40, no.4, pp.465–466, 2010.

[23] “Virtual bridged local area networks,” IEEE Std. 802.1Q, 2006.[24] L. Sun, K. Suzuki, Y. Chiba, Y. Hatano, and H. Shimonishi, “A net-

work management solution based on OpenFlow towards new chal-lenges of multitenant data center,” Proc. 9th Asia-Pacific Sympo-sium on Information and Telecommunication Technologies (AP-SITT), IEICE/IEEE, 2012.

[25] K. Barabash, R. Cohen, D. Hadas, V. Jain, R. Recio, andB. Rochwerger, “A case for overlays in DCN virtualization,” Proc.3rd Workshop on Data Center-Converged and Virtual EthernetSwitching, pp.30–37, 2011.

[26] J. Pettit, J. Gross, B. Pfaff, M. Casado, and S. Crosby, “Virtualswitching in an era of advanced edges,” Proc. Workshop on DataCenter–Converged and Virtual Ethernet Switching (DC-CAVES),2010.

[27] C. Argyropoulos, D. Kalogeras, G. Androulidakis, and V. Maglaris,“PaFloMon — A slice aware passive flow monitoring framework forOpenFlow enabled experimental facilities,” Proc. European Work-shop on Software Defined Networking (EWSDN), pp.97–102, 2012.

[28] E. Rosen, A. Viswanathan, and R. Callon, “Multiprotocol labelswitching architecture,” RFC3031, Internet Engineering Task Force,2001.

[29] S. Das, A.R. Sharafat, G. Parulkar, and N. McKeown, “MPLS witha simple OPEN control plane,” Proc. Optical Fiber CommunicationConference and Exposition, and the National Fiber Optic EngineersConference (OFC/NFOEC), 2011.

[30] J. Moy, “OSPF Version 2,” RFC 2328, Internet Engineering TaskForce, 1998.

[31] L. Andersson, I. Minei, and B. Thomas, “LDP Specification,” RFC5036, Internet Engineering Task Force, 2007.

[32] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, andG. Swallow, “RSVP-TE: Extensions to RSVP for LSP tunnels,”RFC3209, Internet Engineering Task Force, 2001.

[33] J. Kempf, S. Whyte, J. Ellithorpe, P. Kazemian, M. Haitjema,N. Beheshti, S. Stuart, and H. Green, “OpenFlow MPLS and theopen source label switched router,” Proc. 23rd International Tele-traffic Congress, pp.8–14, 2011.

[34] “OpenFlow switch specication version 1.1.0 implemented (WireProtocol 0x02),” OpenFlow Switch Consortium, 2011.

[35] O. El Ferkouss, S. Correia, R. Ben Ali, Y. Lemieux, M. Julien,M. Tatipamula, and O. Cherkaoui, “On the flexibility of MPLS ap-plications over an OpenFlow-enabled network,” Proc. Global Com-munications Conference (GLOBECOM), 2011.

[36] A. Farrel, J.P. Vasseur, and J. Ash, “A path computation element(PCE)-based architecture,” RFC 4655, Internet Engineering TaskForce, 2006.

[37] A. Giorgetti, F. Cugini, F. Paolucci, and P. Castoldi, “Openflow andPCE architectures in wavelength switched optical networks,” Proc.16th International Conference on Optical Network Design and Mod-eling (ONDM), 2012.

[38] “The RouteFlow Project Web Site.” https://sites.google.com/site/routeflow/

[39] M. Nascimento, C. Rothenberg, M. Salvador, and M. Magalhaes,“Quagflow: Partnering quagga with openflow,” ACM SIGCOMMComputer Communication Review, vol.40, pp.441–442, 2010.

[40] Y. Rekhter, T. Li, and S. Hares, “A border gateway protocol 4 (BGP-4),” RFC 4271, Internet Engineering Task Force, 2006.

[41] D. Kotani, K. Suzuki, and H. Shimonishi, “A design and implemen-tation of OpenFlow controller handling IP multicast with fast treeswitching,” Proc. International Symposium on Applications and theInternet (SAINT), pp.60–67, 2012.

[42] M. Casado, M.J. Freedman, J. Pettit, J. Luo, N. McKeown, andS. Shenker, “Ethane: Taking control of the enterprise,” ACM SIG-COMM Computer Communication Review, vol.37, no.4, pp.1–12,2007.

[43] H. Kim, A. Voellmy, S. Burnett, N. Feamster, and R. Clark,“Lithium: Event-driven network control,” Technical Report GT-CS-12-03, Georgia Institute of Technology, 2012.

[44] T. Watanabe, S. Kinoshita, J. Yamato, H. Goto, and H. Sone, “Flex-ible access control framework considering IdP-Side’s authorizationpolicy in roaming environment,” Proc. Computer Software and Ap-plications Conference Workshops (COMPSACW), pp.76–81, 2012.

[45] M. Suenaga, M. Otani, H. Tanaka, and K. Watanabe, “Opengateon OpenFlow: System outline,” Proc. 4th International Confer-ence on Intelligent Networking and Collaborative Systems (INCoS),pp.491–492, 2012.

[46] “Shibboleth.” http://shibboleth.net/[47] G. Yao, J. Bi, and P. Xiao, “Source address validation solution

with OpenFlow/NOX architecture,” Proc. International Conferenceon Network Protocols (ICNP), pp.7–12, 2011.

[48] S. Shin and G. Gu, “CloudWatcher: Network security monitoringusing OpenFlow in dynamic cloud networks,” Proc. InternationalConference on Network Protocols (ICNP), 2012.

[49] S. Shin, P. Porras, V. Yegneswaran, M. Fong, G. Gu, and M. Tyson,“FRESCO: Modular composable security services for software-defined networks,” Proc. ISOC Network and Distributed System Se-curity Symposium, 2013.

[50] S. Kumar, T. Kumar, G. Singh, and M.S. Nehra, “Open flow switchwith intrusion detection system,” International J. Schientific Re-search Engineering & Techonology (IJSRET), vol.1, pp.1–4, 2012.

[51] A.T. Campbell, H.G. De Meer, M.E. Kounavis, K. Miki, J.B.Vicente, and D. Villela, “A survey of programmable networks,”ACM SIGCOMM Computer Communication Review, vol.29, no.2,pp.7–23, April 1999.

[52] P. Lin, J. Bi, H. Hu, T. Feng, and X. Jiang, “A quick survey on


selected approaches for preparing programmable networks,” Proc.Asian Internet Engineering Conference (AINTEC), pp.160–163,2011.

[53] G.J. Holzmann, Design and validation of computer protocols,Prentice-Hall, 1991.

[54] K. Bhargavan, D. Obradovic, and C.A. Gunter, “Formal verificationof standards for distance vector routing protocols,” J. ACM, vol.49,no.4, pp.538–576, 2002.

[55] M. Musuvathi and D.R. Engler, “Model checking large network pro-tocol implementations,” Proc. USENIX Symposium on NetworkedSystems Design and Implementation(NSDI), pp.12–12, 2004.

[56] R.W. Ritchey and P. Ammann, “Using model checking to analyzenetwork vulnerabilities,” Proc. IEEE Symposium on Security andPrivacy, pp.156–165, 2000.

[57] N. McKeown, “Making SDNs Work.” Invited talk at Open Network-ing Summit, 2012. Slide and talk video are available at http://tiny-tera.stanford.edu/˜nickm/talks/index.html

[58] P. Kazemian, G. Varghese, and N. McKeown, “Header space anal-ysis: Static checking for networks,” Proc. USENIX Symposium onNetworked Systems Design and Implementation (NSDI), p.9, 2012.

[59] H. Zeng, P. Kazemian, G. Varghese, and N. McKeown, “Automatictest packet generation,” Proc. International Conference on Emerg-ing Networking Experiments and Technologies (CoNEXT), pp.241–252, 2012.

[60] N. Handigol, B. Heller, V. Jeyakumar, D. Mazieres, andN. McKeown, “Where is the debugger for my software-defined net-work?,” Proc. ACM Workshop on Hot Topics in Software DefinedNetworks (HotSDN), pp.55–60, 2012.

[61] “NOX/POX Web Site.” http://www.noxrepo.org/[62] “Floodlight OpenFlow controller — Project floodlight.” http://

www.projectfloodlight.org/floodlight/[63] “Trema: Full-Stack OpenFlow framework in ruby and C,”

http://trema.github.io/trema/[64] N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown,

and S. Shenker, “NOX: Towards an operating system for networks,”ACM SIGCOMM Computer Communication Review, vol.38, no.3,pp.105–110, 2008.

[65] H. Shimonishi, Y. Takamiya, Y. Chiba, K. Sugyo, Y. Hatano,K. Sonoda, K. Suzuki, D. Kotani, and I. Akiyoshi, “Programmablenetwork using OpenFlow for network researches and experiments,”Proc. 6th International Conference on Mobile Computing and Ubiq-uitous Networking (ICMU 2012), pp.164–171, 2012.

[66] P. Porras, S. Shin, V. Yegneswaran, M. Fong, M. Tyson, andG. Gu, “A security enforcement kernel for OpenFlow networks,”Proc. ACM Workshop on Hot Topics in Software Defined Networks(HotSDN), pp.121–126, 2012.

[67] T.L. Hinrichs, N.S. Gude, M. Casado, J.C. Mitchell, and S. Shenker,“Practical declarative network management,” Proc. ACM Workshopon Research on Enterprise Networking (WREN), pp.1–10, 2009.

[68] N. Praveen Katta, J. Rexford, and D. Walker, “Logic programmingfor software defined networks,” Proc. International Workshop onCross-model Language Design and Implementation, 2012.

[69] N. Foster, R. Harrison, M.J. Freedman, C. Monsanto, J. Rexford,A. Story, and D. Walker, “Frenetic: A network programming lan-guage,” Proc. ACM SIGPLAN International Conference on Func-tional Programming (ICFP), pp.279–291, 2011.

[70] A. Voellmy and P. Hudak, “Nettle: Taking the sting out of pro-gramming network routers,” in Practical Aspects of Declarative Lan-guages, pp.235–249, Springer, 2011.

[71] A. Voellmy, H. Kim, and N. Feamster, “Procera: A language forhigh-level reactive network control,” Proc. ACM Workshop on HotTopics in Software Defined Networks (HotSDN), pp.43–48, 2012.

[72] C. Monsanto, N. Foster, R. Harrison, and D. Walker, “A compilerand run-time system for network programming languages,” Proc.ACM SIGPLAN-SIGACT Symposium on Principles of Program-ming Languages (POPL), pp.217–230, 2012.

[73] A.D. Ferguson, A. Guha, C. Liang, R. Fonseca, and S. Krishnamurthi,

“Hierarchical policies for software defined networks,” Proc. ACMWorkshop on Hot Topics in Software Defined Networks (HotSDN),pp.37–42, 2012.

[74] R. McGeer, “Verification of switching network properties using sat-isfiability,” Proc. IEEE International Conference on Communica-tions (ICC), pp.6638–6644, 2012.

[75] M. Reitblatt, N. Foster, J. Rexford, C. Schlesinger, and D. Walker,“Abstractions for network update,” Proc. ACM SIGCOMM Confer-ence, pp.323–334, 2012.

[76] R. McGeer, “A safe, efficient update protocol for OpenFlow net-works,” Proc. ACM Workshop on Hot Topics in Software DefinedNetworks (HotSDN), pp.61–66, 2012.

[77] M. Canini, D. Venzano, P. Peresni, D. Kostic, and J. Rexford,“A NICE way to test OpenFlow applications,” Tech. Rep. EPFL-REPORT-169211, Ecole Polytechnique Federale de Lausanne,2011.

[78] C. Baier and J.P. Katoen, Principles of Model Checking (Represen-tation and Mind Series), The MIT Press, 2008.

[79] C. Cadar and K. Sen, “Symbolic execution for software testing:three decades later,” Commun. ACM, vol.56, no.2, pp.82–90, Feb.2013.

[80] R.W. Skowyra, A. Lapets, A. Bestavros, and A. Kfoury, “Verifiably-safe software-defined networks for CPS,” Proc. ACM InternationalConference on High Confidence Networked Systems, pp.101–110,2013.

[81] E. Al-Shaer and S. Al-Haj, “FlowChecker: Configuration analysisand verification of federated openflow infrastructures,” Proc. ACMWorkshop on Assurable and Usable Security configuration, pp.37–44, 2010.

[82] A. Khurshid, W. Zhou, M. Caesar, and P.B. Godfrey, “VeriFlow:Verifying network-wide invariants in real time,” ACM SIGCOMMComputer Communication Review, vol.42, no.4, pp.467–472, Sept.2012.

[83] H. Mai, A. Khurshid, R. Agarwal, M. Caesar, P.B. Godfrey, and S.T.King, “Debugging the data plane with anteater,” ACM SIGCOMMComputer Communication Review, vol.41, no.4, pp.290–301, Aug.2011.

[84] A.D. Ferguson, A. Guha, J. Place, R. Fonseca, and S. Krishnamurthi,“Participatory networking,” Proc. USENIX Conference on Hot Top-ics in Management of Internet, Cloud, and Enterprise Networks andServices (Hot-ICE), 2012.

[85] A. Guha, M. Reitblatt, and F. Nate, “Machine-verified network con-trollers,” Proc. Annual ACM SIGPLAN Conference on Program-ming Language Design and Implementation (PLDI), pp.217–230,2012.

[86] M. Kuzniar, P. Peresini, M. Canini, D. Venzano, and D. Kostic, “ASOFT way for openflow switch interoperability testing,” Proc. In-ternational Conference on Emerging Networking Experiments andTechnologies (CoNEXT), pp.265–276, 2012.

[87] M. Kuzniar, M. Canini, and D. Kostic, “OFTEN testing OpenFlownetworks,” Proc. European Workshop on Software Defined Net-working (EWSDN), pp.54–60, 2012.

[88] D. Jin and D.M. Nicol, “Parallel simulation of software defined net-works,” Proc. ACM SIGSIM Conference on Principles of AdvancedDiscrete Simulation, pp.91–102, 2013.

[89] A. Wundsam, D. Levin, S. Seetharaman, and A. Feldmann,“OFRewind: Enabling record and replay troubleshooting for net-works,” Proc. USENIX Annual Technical Conference, pp.29–29,2011.

[90] C. Scott, A. Wundsam, S. Whitlock, A. Or, E. Huang, K. Zarifis,and S. Shenker, “How did we get into this mess? Isolating fault-inducing inputs to SDN control software,” Tech. Rep. UCB/EECS-2013-8, Electrical Engineering and Computer Sciences, Universityof California, Berkeley, Feb. 2013.


Kazuya Suzuki received the M.E. degree inElectrical Engineering from Tokyo Metropoli-tan University in 1997 and Ph.D. degree inSystems Management from the University ofTsukuba in 2011. He joined NEC Corporationin 1997, where he has been developing networkequipment. He is currently with the KnowledgeDiscovery Research Laboratories, NEC Corpo-ration. His research interests include improvingavailability in unicast and multicast routing andsoftware-defined networking.

Kentaro Sonoda received the B.S. degree incomputer science and engineering from Univer-sity of Aizu, Japan, in 2000. From 2000 to 2005,he was with a systems integration company andworked in corporate & business development onsecurity technologies & solutions. After that hejoined NEC Corporation in 2005. Currently heworks in Cloud System Research Labs., NEC,and has been engaged in research on technolo-gies for a security with Software-Defined Net-working.

Nobuyuki Tomizawa received his M.S. de-gree in Information Science from Tokyo Insti-tute of Technology in 1994. He joined NECCorporation in 1994. He now works in NEC’sKnowledge Discovery Research Laboratoriesand is engaged in research on software-basedtechnologies for reliable Software-Defined Net-working.

Yutaka Yakuwa received his M. Engi-neering degree from Waseda University in 2009.He joined NEC Corporation in 2009 and hasbeen undertaking research on formal methods.He now works in NEC’s Knowledge Discov-ery Research Laboratories and is engaged in re-search on software-based technologies for reli-able Software-Defined Networking.

Terutaka Uchida received the Bachelor’sdegree in Commerce from Meiji University, To-kyo, Japan. He is currently a researcher in theOptical IP Development Division, NEC Corpo-ration of America. His research interests includenetworking and business communication soft-ware.

Yuta Higuchi received the Master’s degreein Information Science from Nagoya University.He joined NEC Corporation in 2007, where hehas been undertaking development of a platformframework for operation management softwarestacks. He is currently with the Optical IP De-velopment Division, NEC Corporation of Amer-ica. His research interests include architecturedesign of scalable frameworks for Software-Dened Networking using OpenFlow and other pro-tocols.

Toshio Tonouchi is working in NEC Cor-poration. He received a master degree in De-partment of Information Science, Faculty of Sci-ence, University of Tokyo, and a Ph.D. fromGraduate School of Information Science andTechnology, Osaka University. He worked forOSI management platforms and developmentprocess and tools of the platforms. He was avisitor of Department of Computing, ImperialCollege, UK in 2000–2001, and he studied thepolicy-based management, there. He won Ya-

mashita memorial award, IPSJ and ICM research award, IEICE. His re-search interest is how to develop reliable SDN networks efficiently.

Hideyuki Shimonishi received the M.E.and Ph.D. degrees from the Graduate School ofEngineering Science, Osaka University, Osaka,Japan, in 1996 and 2002. He joined NEC Cor-poration in 1996 and has been engaged in re-search on traffic management in high-speed net-works, switch and router architectures, and traf-fic control protocols. As a visiting scholar in theComputer Science Department at the Universityof California at Los Angeles, he studied next-generation transport protocols. He now works

in NEC’s Knowledge Discovery Research Laboratories and is engaged inresearch on technologies for future Internet architectures including Open-Flow. He is a member of the IEICE.

invited survey paper a survey on openflow technologies

Documents