Font Size: SmallerFont Size: DefaultFont Size: Larger
  • 日本語トップ

New Method of Freely Controlling OpenFlow Network by a Multitude of Controllers

  • Print this page
April 26, 2013

The National Institute of Information and Communications Technology (NICT, President: Dr. Masao Sakauchi) has implemented a new method of freely controlling an OpenFlow network by a multitude of controllers, which has been difficult by using existing methods. The feature of the method for OpenFlow, which is drawing attention as a SDN technology, is that it makes use of a function of OpenFlow itself. By utilizing its function, not only makes it easy to introduce it in the existing OpenFlow infrastructure, but also keep the processing overhead lower by utilizing a hardware function of OpenFlow equipment. It is expected that when the practical use of this method is available, it becomes possible to provide a cloud-like network service that assigns a designated network to each user, or optimized individual network protocols to PCs, smart phones or even to each application and service on those devices. We had demonstrated the developed method in “ONS 2013” held in Santa Clara, LA, USA from Apr 15th to 17th, 2013.


In recent years, cases of implementing OpenFlow as a SDN technology are increasing. To enable multi-tenancy in OpenFlow networks like a cloud system, it is necessary to enable controlling from multiple controllers. There are some existing methods, for example: Pre-adjustment to avoid overlapping from multiple controllers (e.g. FlowVisor) and individually build an OpenFlow Network for each controller (e.g. OFIAS). However, all those existing methods had some limitations of scalability, which made it difficult to apply on a large scaled environment with a multitude of controllers.

Figure 1: Concept of Multi-Tenancy OpenFlow

This time, NICT has developed a method of converting packet of data and controls automatically inside an OpenFlow Network, to avoid overlapping of controls from multiple controllers. With this method, a large-scaled multi-tenancy OpenFlow network will be available. The user terminal and application can have its own control method for optimization with its designated OpenFlow network (Figure 1). This method looks similar to the previously mentioned FlowVisor. However, with automatic conversion, the new method does not require pre-adjustment among each tenant, which makes it easy to expand a network scale. Moreover, as it is using a function of OpenFlow itself, there is no need for adding new equipment, or new additional functions in OpenFlow. The method easily accelerates the speed by utilizing hardware functions of OpenFlow switches.

Future prospects

JGN-X, a new generation network testbed by NICT, is operating a testbed for SDN and OpenFlow technologies called “RISE”. With applying this method, NICT plans a significant capacity improvement of RISE in the sense of a number of users. Also, toward practical use of this technology, NICT aims to implement it into end-user environments like cellular phones, and realize collaboration with actual services.


Details of the developed mechanism

The feature of SDN is that it enables flexible network control from outside. On the other hand, the more larger-scaled, the more number of users can share the network. In this meaning, to fully utilize the feature of SDN in a large-scaled network, it is important to make it possible for the users to control the network freely. For this reason, our research aimed to achieve flexible network control from each user by a highly practical method. Each controller does not need to consider the flow space that may be or shouldn’t be controlled. We call this mechanism as “Complete logical virtualization of OpenFlow”.

The following 2 functions form the mechanism of our development this time (Figure 2):

Figure 2: Overview of the proposed mechanism
Figure 2: Overview of the proposed mechanism

1. Converting contents of control

Like FlowVisor, set a function of automated conversion not to overlap multiple controls from different controllers between switches and controllers. The conversion function checks flow space that is used by each control message. It converts MAC address, the address of Layer2, to make each flow space unique. By this conversion, flow space of each controller is logically virtualized, and it avoids overlap in actual flow space used by OpenFlow switch (physical flow space). This makes it possible to share one OpenFlow network among multiple controllers.

2. Converting data packets

Set a function of automated conversion of data packets to match conversion that is done in flow space between switches and controllers (it is possible to build it into OpenFlow switch or the end node.). By having this function, even though there are overlapping flow spaces on the edge node side, it can treat those flow spaces separately inside the OpenFlow network. The packet conversion is done by using OpenFlow mechanisms, which means you do not need to add any additional functions into OpenFlow itself. Also you can easily implement it in an existing OpenFlow infrastructure. Moreover, since the MAC address conversion used in the conversion is already a built-in in most of OpenFlow-adopted switches as a hardware function, you can keep processing overhead to an extremely lower level.

The thing we took most effort was to keep it compatible with the OpenFlow control. This method uses the MAC address area for conversion. When a wildcard (that represents ANY address) is specified in the rules that using MAC address, multiple MAC address can be matched with the rule. In that case, if you simply rewrite those MAC address to some other unique MAC address, you cannot retrieve the original MAC address after the packet goes through OpenFlow network and arrives the receiving node. So this method records those control messages that contains wildcards as unconverted messages. When an actual matching packet is received, it creates a unique rewriting rule for the MAC address (Figure 3).

Since the process does not happen again after the relation of MAC address and flow entry is registered, the overhead of this process won’t be a big problem. Also, in the environment that uses large amount of logical network interfaces, like recent cloud infrastructure does, the uniqueness of MAC address is not guaranteed and overlap in MAC address may happen. Even in those cases, the proposed method works without any problem with using different physical port connected to OpenFlow network.

 Figure 3: How to treat MAC address with a wildcard
Figure 3: How to treat MAC address with a wildcard



One of SDN technologies that currently Open Networking Foundation (ONF) is working toward standardization in the industry. A lot of adopted equipment is already released. The network control in OpenFlow is done by an external controller that sends information called ‘flow entry’ to the switches. Each switch decides packet processing based on this information. In the flow entry, there is information described to specify the target packet to control (physical port that the packet received, and header information of the packet) and how the packet should be processed (header modification, or sending from a specific physical port).

SDN (Software Defined Networking)

A generic name of technologies which makes the network control method programmable from software outside from the network equipment, unlike the traditional method that is implemented in the same unit. SDN is marked as a method which makes it possible to provide customized network control for each service, or other totally new networking methods.

ONS 2013

It was held in Santa Clara in USA from April 15th to 17th, 2013.


A method to provide individually separated services to multiple users (tenants), but shares the actual equipment, software, database among those multiple users. Compares to ‘single tenant’ that prepares a designated system for each user, the method enables lower cost for resources and operations, and enables lower price of services.


A method developed by Stanford University. It enables controlling one single OpenFlow network by multiple controllers in parallel. FlowVisor acts as a transparent proxy between OpenFlow switches and controllers. It binds those controls from multiple controllers, as if those are controls from one controller, before forwarding it to switches. Pre-adjustment of assignment is required when you use FlowVisor, not to overlap flow space (set of packet information to be controlled) for each controller.

OFIAS (OpenFlow In A Slice)

A method jointly developed by NICT and The University of Tokyo. It is a technology that creates an individual OpenFlow environment by accommodating an OpenFlow network to a virtualized network called “slice”. There is a need to build individual OpenFlow networks for each slice.


A new testbed network environment, to achieve and deploy new generation network technologies. NICT has been operating JGN-X since April 2011. It is widely open to the public for research and development.


A testbed environment for SDN and OpenFlow technologies over JGN-X. NICT has been providing the service since October 2011. It is widely open to the public same as JGN-X.

Technical Contact

Eiji Kawai, Hiroaki Yamanaka
Network Testbed Research and Development Promotion Center
Tel: +81-3-3272-3060

Media Contact

Sachiko Hirota
Public Relations Department
Tel: +81-42-327-6923