2011 IEEE/IPSJ International Symposium on Applications and the Internet

Flexible Access Management System for Campus VLAN Based on OpenFlow

Yasuhiro YAMASAKI*

Yoshinori MIYAMOTO*

Hideaki GOTO

Junichi YAMATO

Hideaki SONE

Cyberscience Center, Tohoku University, Japan

{yasuhiro, miyamoto, hgot, sone}@isc.tohoku.ac.jp

System Platforms Research Laboratories, NEC Corporation, Japan

j-yamato@bk.jp.nec.com
packet of all communications and judges the route etc. Our
proposed system by using this feature of OpenFlow manages
a lot of virtual network group without a special field such as
VLAN tag in the packet header.
The rest of this paper is organized as follows. Section II
describes overview of campus network. Section III describes
the problems of campus network. The flexible access
management system based on OpenFlow is presented in
Section IV. The prototype system and evaluation results are
shown in Section V and Section VI.

AbstractUsing a lot of VLANs on campus networks has

become popular for deploying many logical networks over
minimal fibers/cables. A campus-wide Wi-Fi system, for
example, requires a lot of VLANs for separating the access
networks from other campus networks and for realizing a
sophisticated access control such as guest-/home-users
separation and security filtering. The requirement is high
especially when a network roaming system, such as eduroam,
is introduced. The conventional VLAN based on IEEE802.1Q
has some limitations, and the system configuration work is
laborious. In this paper, we propose a flexible campus VLAN
system based on OpenFlow to solve the problems. In addition,
we introduce a prototype system and show evaluation results.
As the results, we confirm that the proposed system can realize
flexible network configurations and sophisticated access
control with a much simplified network management work.
Keywords-component; URDPLQJ HGXURDP 2SHQ)ORZ
1HWZRUN26DFFHVVPDQDJHPHQW

I. INTRODUCTION
In the current campus networks, a lot of VLANs based
on IEEE802.1Q [1] have been generally used for deploying
many logical networks over minimal fibers/cables.
Especially, a campus-wide Wi-Fi system, such as eduroam
[2], manages networks by using a lot of VLANs for
separating the access networks from other campus networks
and for realizing a sophisticated access control such as guest/home-users separation and security filtering because various
users use the Access Points (APs).
However, using a lot of VLANs has some problems. The
first problem is the limitation of the number of VLAN IDs.
The second problem is that system configuration work
increases as the scale of the network becomes larger even if
there are enough VLAN IDs.
In this paper, we propose a flexible access management
system for campus VLAN based on OpenFlow [3] to solve
these problems. OpenFlow is a new technology attracting
peoples attentions in the field of Future Internet such as FP7
[4] in EU, NSF FIND [5] in U.S. and Akari [6] in Japan and
has the feature that the controller server receives the first
*

University
private
network

Gateway

eduroam
home user
network
eduroam
guest user
network

Current Affiliation: System Platforms Research

Laboratories, NEC Corporation, Japan.
{y-yamasaki@ay, y-miyamoto@ej.jp.nec.com}.jp.nec.com

978-0-7695-4423-6/11 $26.00 2011 IEEE

DOI 10.1109/SAINT.2011.66

II. CAMPUS NETWORKS

Use of many VLANs has become quite popular these
years in campus networks. Particularly, campus Wi-Fi
networks such as eduroam require a large number of VLAN
IDs when we want to separate and secure users
communications. The eduroam has been proposed by
TERENA (Trans-European Research and Education
Network Association) as a technology for Wireless LAN
(WLAN) roaming between research and educational
institutions. The eduroam is based on IEEE802.1X [7] and
hierarchically structured RADIUS [8] proxies. The eduroam
has already spread worldwide, and 21 institutions have
joined eduroam in Japan as of writing.
A roaming system including eduroam in campus
networks has a lot of Access Points. An Access Point has
multiple SSIDs such as for university private network,
eduroam and local area. A VLAN ID is allocated to each
SSID. In addition, more than one VLAN IDs may be
allocated to the same SSID in the case of using IEEE802.1X
dynamic VLAN for guest-/home-users such as eduroam.
Figure 1 shows a campus Wi-Fi system in which 100 VLAN
IDs are required in the case of N=25 (the number of AP is
25) and separating network segment of each AP though the
needed minimum number of VLAN for this system is four.
VLAN[N-1]: University internal user
VLAN[A-2]: eduroam
home user
VLAN[A-3]: eduroam guest user
VLAN[A-1]: University internal user
VLAN[A-4]: Local user
VLAN[A-2]: eduroam home user
etc
SSID: University
VLAN[A-3]: eduroam
guest user
VLAN[A-4]: Local user
SSID: SSID:
eduroam
etc
University
Floor A
Floor A

RADIUS

SSID:SSID:
local Aeduroam
etc
SSID: Local A
etc

Figure 1: A typical campus Wi-Fi system

347

III.

OpenFlow controller has a feature for receiving every

first packet of communication which is the flow of
OpenFlow such as the 12-tuple [11] because there is not flow
information in forwarding entry in the switches in the case of
starting a communication.

PROBLEMS IN CAMPUS NETWORKS

Using a lot of VLANs has two major problems. The first

problem is the shortage of VLAN IDs. The second problem
is that system configuration work is laborious.

2) The Comparison with general network

Setting
VLAN
Config

tag
Check tag

VLAN
Config

tag
Check tag

New Function
Configuration

VLAN
Config

VLAN
Config

tag
Check tag

Control
New Function
Configuration

New Function
Configuration

Control
Control
Forwarding Forwarding

tag
Add tag

OpenFlow protocol
Forwarding Forwarding

Figure 2: VLAN management

General network

A. The number of VLAN

The special field such as VLAN tag is necessary in the
header of packet because the virtual network is managed by
VLAN ID. The number of VLAN ID is restricted by 4096
because the ID field of VLAN tag is 12 bit long. Although
using IEEE802.1ad [9] or IEEE802.1ah [10] can be a
workaround to increase the number of IDs, managing
multiple VLAN tags is not so easy.

OpenFlow

Figure 3: OpenFlow overview

As shown in the left part of Figure 3, general network
systems such as IP, optical transport and mobile network
consist of data forwarding plane and control plane. These
nodes are independent each other and loosely coupled i.e.
their control planes do not communicate with each other.
Therefore, classification information on the virtual network
is notified to next network node by using VLAN tag. Each
node needs to be configured independently.
On the other hand, as show in the right part of the Figure
3, OpenFlow has independent data forwarding planes and an
integrated control plane. By employing open interfaces
between the data forwarding planes and the control plane, the
mechanism of integrated control plane is reflected in all
nodes on OpenFlow network that is different from general
network system. Therefore, classification information on the
virtual network is notified to the next network node without
VLAN tag and it is enough to configure only the integrated
control plane for new configuration or new function.

B. Network managiment cost

In the VLAN-based network VLAN, edge nodes add
VLAN tag to the packet and core nodes check the VLAN
tag and judge the forwarding port. Every network nodes
need to be manually configured so they keep the VLAN
information. This system configuration work becomes
laborious according to the increase of the number of
network nodes and VLANs (see Figure 2).
IV. CAMPUS VLAN BASED ON OPENFLOW
We propose a flexible access management system for
campus VLAN based on OpenFlow. Our system is based on
OpenFlow [3,11 and 12 ] and enables easy configuration and
management of virtual networks without using a special field
for VLAN tag.

B. The proposed access management system

1) Basic Concept
Basic functionNew function (AMF)
etc

QoS

Path cal

A. OpenFlow
1) Architecture
OpenFlow network is composed of many switches
(OpenFlow switch) and one controller server (OpenFlow
controller).
OpenFlow switch has a data forwarding plane only and
the forwarding process is very simple. A forwarding entry in
the switch is referred when OpenFlow switch receives a
packet. When there is flow information of the packet in the
forwarding entry, the packet is forwarded according the
forwarding entry. When there is not any, the packet is
forwarded to OpenFlow controller.
OpenFlow controller has the integrated control plane of
all switches. In the case of forwarding the packet from a
switch, OpenFlow controller decides the forwarding port of
packet and writes it the forwarding entry of the switch by
OpenFlow protocol. Many other processes such as path
calculation, QoS control and so on are also performed.

Radius

Dst check

ACL
check

Src check

GID-DB

User-DB Tree

Network OS

OpenFlow Controller

Radius

OpenFlow Network

Figure 4: Proposed system

The proposed system manages virtual network groups
equivalent to the conventional VLAN by using the feature of
OpenFlow. This is achieved by adding the access
management function (AMF) to OpenFlow with basic
functions. AMF has databases of virtual group IDs (GIDs),
check functions of source-/destination-address and ACL
check function. GID and address such as MAC, IP and port
are pairs of the record in GID DBs.

348

When user starts communication, the edge OpenFlow

switch forwards the first packet of the communication to
OpenFlow controller. OpenFlow controller executes AMF
before basic functions. First, GID of source address is
checked referring to GID DBs. Next, GID of destination
address is checked in a similar way. Finally, GID of source
address is compared with GID of destination. If it is the
combination from which GID of source address and
destination are accepted, and OpenFlow controller executes
basic functions. If it is not so, the communication is rejected
and OpenFlow controller executes nothing.
In this mechanism, the number of ID is hardly restricted
because group ID is managed by not VLAN tag of 12 bits in
the header of packet but GID of free size in databases of
OpenFlow. In addition, the system configuration work
becomes lighter because the configuration of switches need
not be changed even if GID is changed.

User-DB

GID-DB

User : yamasaki
GID : Tohoku Univ.
MAC:
A

GID : Tohoku Univ.

MAC :
A

OpenFlow
Controller

DHCP

eduroam JP
Reporting Radius
(MAC&GID)

RADIUS
(including Calling Station ID)
IP:Y

EAP

MAC:A
yamasaki

Figure 5: Authentication & Reporting

User-DB

GID-DB

User : yamasaki
GID : Tohoku Univ.
MAC:
A

GID : Tohoku Univ.

MAC :
A

2) Eduroam access network using OpenFlow

In this section, as a concrete example, we introduce an
application of the proposed system to eduroam access
network. As source of Address information in GID DBs,
various forms are possible in general. For example, static
MAC/IP/port addresses list or dynamic IP address from
DHCP and so on. In the case of eduroam, the source of
Address information is User-DB of RADIUS server. User
DB of the RADIUS server is enhanced, so it can store GID
(static information) and MAC (dynamic information) address
besides user name (static information). For pre-configuration
of GID DBs, three communications for RADIUS packet,
reporting packet between RADIUS server and OpenFlow
controller and DHCP packet are set to accept.

eduroam JP

OpenFlow
Controller

DHCP

Radius

Request IP
IP:Y

IP:X

MAC:A
yamasaki

Figure 6: DHCP
Compare
Source GID
Destination GID

Step1. Authentication
When user connects the network, the user node sends
EAP packets to an AP. The AP sends RADIUS AccessRequest packets including Calling Station ID (= user MAC
address) to RADIUS server. If the authentication succeeds,
Calling Station ID is saved in User DB as MAC address (see
Figure 5).

DHCP

User-DB

GID-DB

User : yamasaki
GID : Tohoku Univ.
MAC:
A

GID : Tohoku Univ.

MAC:
A

eduroam JP

OpenFlow
Controller

Radius
inquiry
OpenFlow Protocol
First packet

IP:Y

IP:X

MAC:A
yamasaki

Step2. Reporting
After MAC address is saved in User DB, the RADIUS
server sends a report such as MAC address and GID of the
user to OpenFlow controller. OpenFlow controller saves
these information in GID DBs. After this, RADIUS server
sends RADIUS Access-Accept packet to the AP. Then, user
node can be accepted the network.

Figure 7: Access management

GID-DB
GID : Tohoku Univ.
MAC:
A

DHCP

Step3. DHCP
User node does not have IP address immediately after
accepted. Then, user node sends DHCP Request. This packet
is sent to OpenFlow controller since it is the first packet of a
communication. AMF in OpenFlow controller accepts the
communication because DHCP packet is set to accept by
pre-configuration. Therefore, user node gets IP address (see
Figure 6).

OpenFlow
Controller

User-DB
User : yamasaki
GID : Tohoku Univ.
MAC:
A

eduroam JP
Radius
results

OpenFlow Protocol
IP:Y

IP:X

yamasaki

Figure 8: Communications

349

Table 1: Specification (OpenFlow controller)

Step4. Access management

When new communication such as HTTP, FTP and so on
begins, an edge OpenFlow switch sends the first packet to
OpenFlow controller. Then, AMF checks GIDs of source
address and destination address in the OpenFlow controller.
Acceptance or rejection is judged from GIDs (see Figure 7).

Hardware
CPU

NEC Express5800/GT110b-s
Intel Core i3-540 3.07GHz

M emory
OS

3GB
Ubuntu 10.10

Software

Step5. Communications
If the communication is accepted, basic functions such as
path calculation are executed. Then, next forwarding port is
written in forwarding entry of each OpenFlow switch on the
communication path (see Figure 8).

NEC Express5800/110Ek
Intel Xeon 3040 1.86GHz

M emory

1GB

OS

CentOS 5.5
FreeRADIUS 2.1.9

Software

DHCP

In table 1 and table 2, specs of our proposed system on a

test-bed are described.
VI. EVALUATIONS
We have evaluated our proposed system using the testbed. In this section, we show evaluation results.
A. The access management function
In the first evaluation, we have evaluated the access
management function of the prototype system.
Two contents servers are connected to the test-bed
system. One is GID = A. The other is GID = B. We
confirmed accesses when the user logs in the network with
ID of GID A. In the case, the communication from the users
node to the contents server of GID A succeeded and the
communication from the users node to the contents server of
GID B failed. We confirmed that the system can manage
virtual network groups by conducting in similar experiments.
In addition, similar access management experiments
were done when we registered 10,000 GID in GID-DB and
the same results as assumption were obtained. We have
confirmed the prototype system can deal with much more
virtual networks than the conventional VLAN tagging.

NECs OpenFlow Controller

+ Access management function
FreeRadius2.1.9
+ Reporting function
DHCP server
AT-TQ2403

User
(GID=A)

PostgreSQL 8.4.7

Table 2: Specification (RADIUS/DHCP)

Hardware
CPU

V. PROTOTYPE SYSTEM
We have implemented the proposed system for eduroam
and have also built a test-bed system for evaluations (see
Figure 9). This system is utilizing NECs OpenFlow
controller [13] and FreeRADIUS on Linux operating system.
As our OpenFlow controller, we have implemented AMF
on NECs OpenFlow controller and use PostgreSQL for
GID-DB. In our prototype system, there is hardly a limitation
in the number of GID because ID field of GID-DB is
64Bytes (see Figure 10).
As our RADIUS server, we have implemented reporting
function (RF) on FreeRADIUS to notify OpenFlow of MAC
address and GID and have enhanced User DB for RADIUS
to treat MAC address and GID.
Flexible Access Management System

reject
accept

NEC's OpenFlow Controller

GID=B

NECs OpenFlow Switch

(1Gbps24ports+10Gbps2ports)
GID=A
Contents Server

B. The times for comminications

In the second evaluation, we have evaluated the response
times for communications such as pings, authentication and
data retrieval. The purpose of this evaluation is to evaluate
the processing times of new functions such as AMF of
OpenFlow and RF of FreeRADIUS.

Figure 9: a test-bed system

1) The time for ICMP Echo

In this evaluation, the time for ping of proposed system
(proposed OFC) is compared with the time for ping of
normal NECs OpenFlow controller (Basic OFC) and
general network. The time for ping is the time from ICMP
Echo request packet to ICMP Echo Reply packet. In the case
of the first packet, OpenFlow controller executes functions
including AMF. On the other hand, in the cases of pings
beyond the second ping, OpenFlow controller executes
nothing because the flow information has already been

Figure 10: Information of GID in our Open Flow controller

350

written in the forwarding entry in OpenFlow switches at the

first ping. Therefore, we have evaluated the times for the first
ping and the second ping, respectively. Evaluation results are
shown in table 3.
Following two results are clarified from the time for the
first ping.1) the processing time of basic functions of NECs
OpenFlow controller is 8.9ms.2) the processing time of our
new function AMF is also 8.5ms. From the time for the
second ping, it is clarified that forwarding time for packet in
the case of executing nothing in OpenFlow controller is
almost the same as general network.

VII. CONCLUSION
In this paper, we have proposed a flexible access
management system based on OpenFlow. The system
manages communication access by virtual group ID (GID)
managed in OpenFlow controller instead of VLAN. The
number of ID is hardly restricted and even if GID is changed,
the configuration of switches need not be changed because
GID is only used in OpenFlow controller.
We have also built a prototype system having two useful
functions. The first function is the access management
function equivalent to the authentication VLAN based on
NECs OpenFlow controller. The Second function is
Reporting function of the authentication information based
on FreeRADIUS.
In evaluation results of the system, we have shown the
time for authentication and pings, data retrieval. The times
for authentication and pings are about 10ms longer than
basic OpenFlow controller. However, they are practicable
times.
System evaluations using a real campus network are
included in our future work.

Table 3: The time for pings

First ping(ms) Second ping(ms)

Proposed OFC
Basic OFC
General Network

18.9
10.4
1.5

2.3
2.2
1.6

2) The time for authentication

In this evaluation, to analyze the time for authentication
in detail, times for RADIUS, Node, and DHCP were
investigated. Times for RADIUS, Node and DHCP are the
following meanings respectively. RADIUS is the time from
RADIUS Access-Request packet to RADIUS Access-Accept
packet. Node is the time from RADIUS Access-Accept
packet to DHCP Request packet. DHCP is the time from
DHCP Request packet to DHCP ACK packet. Evaluation
results are shown in table 4.
The reason for 20% longer time for RADIUS
authentication in the proposed OFC is probably because of
the OpenFlow and RF overheads. In DHCP, the time of
proposed OFC is 12.7ms longer than basic OFC because it is
the first packet of a communication (see section IV-B-2 step
3).

REFERENCES
[1] IEEE802.1Q, http://www.ieee802.org/1/pages/802.1Q.html.
[2] L.Florio, K. Wierenga, Eduroam, providing mobility for
roaming users, EUNIS, June 2005.
[3] N. Mckeown, T. Anderson, H. Balakrishnan, G. Parulkar, L.
Peterson, J. Rexford, S.Shenker, and J. Turner, Openflow:
Enabling Innovation in Campus Networks, ACM
SIGCOMM Computer Communication Review, vol.38, 2008,
pp.69-74.
[4] The Seventh Framework Programme (FP7),
http://cordis.europa.eu/fp7/dc/index.cfm
[5] NSF NeTS FIND Initiative, http://www.nets-find.net/
[6] AKARI, http://akari-project.nict.go.jp/
[7] IEEE802.1X, http://www.ieee802.org/1/pages/802.1x.html.
[8] C. Rigney, S. Willens, A. Rubens, and W. Simpson,

Table 4: The time for authentication

RADIUS(ms)

Proposed OFC
Basic OFC
General Network

644.6
656.3
540.3

Node(ms)

DHCP(ms)

65.6
60.5
57.3

33.1
20.7
7.5

Total(ms)

743.3
737.5
605.0

Remote Authentication Dial In User Service (RADIUS),

IETF RFC2865, June 2000.
[9] IEEE802.1ad, http://www.ieee802.org/1/pages/802.1ad.html
[10] IEEE802.1ah, http://www.ieee802.org/1/pages/802.1ah.html
[11] The OpenFlow Switch Consortium. 2009. OpenFlow Switch
Specification Version 1.0.0,
http://www.openflowswitch.org/documents/openflow-specv1.0.0.pdf, December, 2009.
[12] Open vSwitch An Open Virtual Switch,
http://openvswitch.org/
[13] Hideyuki Shimonishi, Shuji Ishii,"Virtualized network
infrastructure using OpenFlow" in proc. of IFIP/IEEE BcN
2010 Workshop, April, 2010

3) The time for data retrieval

In this evaluation, to analyze the time of AMF in detail,
the times for data retrieval such as check functions of source/destination-address and ACL check function in PostgreSQL
were investigated. Evaluation results are shown in table 5.
The time for data retrieval is about 5ms.In the case of two
ways communication such as the first ping, this time is about
10ms because there are two first packet which is ICMP Echo
request packet and ICMP Echo Reply packet. It is clarified
that the time for retrieval is predominant at the time of AMF.
Table 5: The time for data retrieval
Average (ms)

Src check
Dst check
ACL check

3.0
0.5
1.1

351