Abstract-Currently, there is a philosophical problem that arises between the real need for current support to OpenFlow and legacy network infrastructure. Among ...
Integrating Legacy Forwarding Environment to OpenFlow/SDN Control Plane Fernando Farias, Joao Salvatti, Pedro Victor, Antonio Abelem
Research Group on Computer Networks and Multimedia Communications - GERCOM Federal University of Para - UFPA Belem, Para, Brazil Email: {fernnf.salvatti.victor.abelem}@ufpa.br Abstract-Currently, there is a philosophical problem that arises between the real need for current support to OpenFlow and legacy network infrastructure. Among them, the legacy networking has not been compatible with OpenFlow network, and for that, it needs to be replaced or a few cases upgraded, as a consequence there are additional spending with new equipment OpenFlow-based. This paper introduces a proposal of hybrid SDN
solution based on OpenFlow protocol and called of LegacyFlow, which is able to control Legacy equipment
(non-OpenFlow)
through OpenFlow protocol 1.0. Results show that it is possible
used the LegacyFlow together with OpenFlow switches keeping a good performance time with OpenFlow application.
I.
The paper is divided into more 3 sections. Section 2 offers a view of the architecture of LegacyFlow as well as a detailed description of its components.. In Section 3 show results of evaluation using Openflow and Legacy switches. Finally, Section 4 presents the conclusions of paper and future work related to solution.
INTRODUCTION
An issue about OpenFlow is the use of virtualized net working, which it is an essential tool to the experimentation environments. Similar to the computer virtualization, it seeks to improve resource allocation allowing operators to create check points for their network before making changes, and ensures that competing customers can share the same equipment in a controlled and isolated way. It also allows a set of switches to be shared among multiple logical networks, each one with the same distinct forwarding logic and using the same hardware forwarding plane [1], which today are the main features on Future Internet (PI) environments. Nevertheless, today both the PI experimentation facilities and OpenFlow networks currently face a big challenge: how can they integrate these environments with hybrid network environments (i.e. OpenFlow and Legacy Network)? Initially, it is necessary to conceptualize the "Legacy Network they are networks with equipment used by non-OpenFlow (e.g. the current Internet network) or technologies that are not supported by OpenFlow (e.g. Layer 1 and Layer 0 circuit technologies). Some of the challenges for OpenFlow networks are relate to the compatibility and requirements to integration with legacy network environments. Another issue, the OpenFlow is not able to handle or manage legacy equipment by OpenFlow protocol, and as a result, it is extremely difficult to allocate resource in legacy networks to connect two-OpenFlow environments. Besides other problematic that arises during rollout is a practical problem-involving legacy switches that it does not support the OpenFlow protocol and they need to be replaced or upgraded. The aim of this paper is to introduce a new solution, called LegacyFlow, for bringing OpenFlow-based network to the legacy network environments. The proposed approach previously set up out an architecture that accommodates legacy equipment and its technologies into an OpenFlow network. The
Copyright 2013 IEICE
solution still provides a new OpenFlow datapath (i.e. Lega cyFlow datapath), representing legacy devices and translating a set of OpenFlow actions into vendor-specific configurations for Ethernet switches, which are able to interact with non OpenFlow legacy equipment using OpenFlow protocol, and thus creating a new approach of hybrid OpenFlow networks.
II. A.
LEGACY ARCHITECTURE
The LegacyFlow Design
At present, if you want to integrate OpenFlow domains, the use of legacy networks is mandatory, unless a private infras tructure is being used with all the OpenFlow-based equipment. It becomes a problem because the OpenFlow protocols are not compatibles with legacy protocol, which is impossible to integrate them or allocate resource network on both networks, because they use different control planes. Therefore, the process of adapting of OpenFlow involves replacing legacy switches with OpenFlow switches. This might be a weakness, because some infrastructures are not prepared to make the necessary financial investment, such as covering the administrative costs involved in replacing them. Despite being a costly proposition, not every switch can be replaced, because they are primal on production network and there is not equivalent OpenFlow equipment similar to, for instance, a legacy core packet switch with the highest throughput performance or expensive ROADM optical switch or good legacy switches without making it possible to install OpenFlow. For this, The LegacyFlow design has the purpose of integrate both, on horizontal way, control planes OpenFlow and Legacy. The LegacyFlow solution creates a path to trans late OpenFlow action, coming from controller, in forwarding configuration into legacy equipment. This is possible through configuration interfaces available on computer network, such as WebService, SNMP or CLI. Basically, The OpenFlow software switch has extensions for data handling of the actions for remove flow information. These information are variables to create a forwarding config uration that it is apply to legacy switch. After that, the flow
is enabling on switch, according to the characteristics sent by controller. On OpenFlow network, when a packet is recognized by datapath, it is checked if there is a flow entry on datapath, for example, if a flow should be forwarded to a certain egress point or drop. But if no match is found, the packet is sent to the controller, and then, an action is applied on the switch to treat upcoming packets associated with the flow. The same rule is applied to other switches, which are required to forward flow to destination. However, there is a limitation on the LegacyFlow, on proposal is not able to read information of packet flows that are arriving in the box. Thus, these switches are generally used on the network core that connects the OpenFlow switches for the ingress or egress of network. In other words, the LegacyFlow do not replace completely the functions of OpenFlow switch, although it can be possible if we think in a reactive manage ment of legacy switch. But, the objective of the LegacyFlow is to help an infrastructure on moving to OpenFlow/SDN, in addition, to handle with equipment that it cannot be replaced.
B. The LegacyFlow Datapath
The Legacy Datapath (LD) is the main feature of the proposal that introduces new extensions in Openflow software switch component, which establishes a link between OpenFlow and the Legacy network. Shortly, it is located in server virtualized environment that connects to switch by an out-of band channel. Its development is based in standard datapath of framework, similar to Type 1 or 0, and interacts as much as Controller than Legacy equipment, and it is based on messages of OpenFlow protocol version 1.0.
�===;:==� =:::
. '�_I1,!,,_·_�!!Ii"J_sn.t!'l'_________________________________________
0i
_________________ AppIiesswitth
. )
o '=:�n�::�b
Fig. 1.
The data handling diagram in LegacyFlow solution
The Figure 1 introduces the process of data handling of the OpenFlow messages from controller to legacy switch. In 1) the OpenFlow send action by secure channel using OpenFlow protocol to LegacyFlow Datapath, 2) & 3) The action is processed and information of flow (e.g. port in, vlan id, ethertype and other) are removed of OpenFlow message that they are sent to switch control server, 4) the switch control server receives the information and build a correct settings for legacy switch vendor, and 5) with specific settings, they are applied on switch using network configuration interface (e.g. SNMP, CLI or WebService).
Copyright 2013 IElCE
C. Switch Control Server
The Switch Control Server (SCS) is the place where the configuration modules, for each legacy equipment (e.g. switch, router or optical switch), are located, your development it will depend on manufacturer and the common protocol for access this features are WebService, TelnetiCLI and SNMP. The communication between LD and SCS is based on IPC (Inter-Process Communication). In this way, the development of new clients interface conununication to real switch between LD and SCS is independent. Between the SCS and legacy equipment, there is an out of-band control channel, which is responsible for sending configuration commands that in this case are used as the port management to establish this communication. In addition, there is a possibility that this communication will be in-band, but it cannot be assessed in term of its performance and effectiveness within the system. D. The LegacyFlow Controller
The LegacyFlow Controller Components (LCC) solution is structured on a set of applications integrated to the OpenFlow controller. These components are necessary for keep transpar ent the combination between OpenFlow and legacy network. Currently, the components are developed using NOX API and their operation is modular, which allow them to become more flexible and expandable to new extensions. The LCC is divided in three parts: LegacyFlow API; Lega cyFlow Application; and LegacyFlow Manager. The Lega cyFlow API is responsible for offering access interfaces of the LegacyFlow actions. These new actions are only recog nized and executed on appropriate LD. Since, the LegacyFlow Manager (LM) is a component developed to the management of communication with other elements such as web graphical interface, helper applications or another LegacyFlow controller. It has three subcomponents, Web manager API coordinates the integration and interaction with graphical user application (e.g. WEB GUI), where the data communication is base on protocol HTTP+JSON. Application manager API are helper interfaces application that helps in decisions of LegacyFlow as routes, topology, monitoring and etc.lnter-LegacyFlow Communication Manager API manages the conununication between LCC located in other openflow domains as resource allocation, topology exchange or update resource. The LegacyFlow Application is the container of application to LCC, which will assist on decisions such as policies, routes or topology, in other words, they are applications developed by administrator. Currently, there are the following applica tions: Route monitoring, for monitoring the circuit or path created; Path computation, which is responsible for compute a route between openflow switch of source and destination; and Topology discover which is a module to discovery of topology among legacy switches. III.
RESULTS
For evaluation, the aim is not measure if the LegacyFlow is better than OpenFlow, but how much the proposal performance is approaching the OpenFlow performance, this way decides if it is possible to use them and which interface is better to communicate to legacy switch.
In testbed, there are four kinds of switches, one openflow and three legacy, which the legacy are two extreme X450 and one Cisco catalyst 3560e. The Openflow switch is based on model Netgear GSM7352S0 using a firmware of Indigo project. The cOlmnunication interface between switches is based on WebService for X450 and SNMP for 3560e. A NOX network controller is used as control plane of the network. The first evaluation, we compare the latency time for applying actions using FLOW_MOD message, such as add, delete and modify actions. Each action is applied 100 times to 100 tests, the mean latency time is plotted in chart. The results are presented on Figure 4.
OF
OF LegacyFlow
LegacyFlow
. . . . . · · · · · · · ·s�;t}:::::��;I.PI'"�W�'h::�:�;;;· · · · · · l·�;·� · __
lC;M�___________________
10.16.1.50 NoteBook A
Fig. 3.
10.16.1.52 NoteBook B
The circuit scenario used to evaluation.
OpenFlow X LegacyFlow Peformance
LegacyFlow Circuit Application
roO-
700 600
.s. ·
....
[
Leg3cyFIow
�
I""
-
500
:--
·
�.
400
·
300 200
C
c:
tOO
0 Number of Switches
Fig. 2.
Latency time to apply atctions on both switches legacy and open flow. Fig. 4.
As expected, the FLOW_MOD on OpenFlow-based is more fast, but on LegacyFlow the results demonstrate that WebService interface has a performance as closely as possible to OpenFlow results with average discrepancy between both switches of 61 ms (milliseconds) that we believe to be an acceptable difference. In other hand, the SNMP has not a good performance, because of its behavior to apply the settings on switches that requires many interactions as opposed to WebService, which is able to do several operations with a simple interaction. This result suggests that LegacyFlow, in comparison to the OpenFlow, can be an alternative to management and usage the legacy infrastructure to OpenFlow protocol and with performance satisfactory. In second evolution, we use a controller application to create Layer 2 circuit among switches OpenFlow and Lega cyFlow. W hen the new flow get into OpenFlow switch a packet-in is sent to a controller that configures a path using the legacy switch, the average time to configure path is plotting on chart. The tests are done with 2, 3 and 4 switch respectively. The Figure 3 shows scenario used to evaluation. The notebook A, in each test, is connected to the Extreme switch and the administrator registers the destination on circuit application, where the computation module calculates a path to notebook B. In Figure 4, the results show an growth in configuration time when topology increase from 2 to 3 switches, due to confirmation of the legacy switch configuration. But after 3 switches, the configuration time has no relevant increment, with 30 ms of difference among configuration time. In general, the LegacyFlow solution reports a good perfor mance for configuration of switches on legacy environment. In addition, in evaluations the WebService shows a better interface for applying configuration using legacy equipment,
Copyright 2013 IEICE
The average configuration time by number of switches
and besides, the LegacyFlow allows the controller applications work together using switches OpenFlow, without the applica tion need to know kind of switch. IV.
CONCLUSION A ND FUTURE WORK
LegacyFlow aims at improving the gradual deployment of OpenFlow in production environments, by reusing the legacy equipment without changing the entire infrastructure. This proposal uses circuits between legacy switches, which involve using dynamic circuits. This is very much in the spirit of the GENI network stitching architecture. This work is in accordance with several activities carried out by the Slice Federation Architecture, including investigations into the interactions with FlowVisor that similarly seek to enable isolated virtual networks. The results show that it is possible to work with both the LegacyFlow and OpenFlow on same infrastructure with only a little modification on the application. The performance will depend, so hardly, of the kind of configuration interface. With regard to future work, it is recommended that mea sures could be taken to broaden tests with parts of the architecture, integrate them more closely with other features of OpenFlow framework and extend it to other technologies. In addition, it would be useful to conduct an evaluation of a FIBRE Testbed [2]. REFERENCES [1]
Rob Sherwood, and et aL Can the production network be the testbed? In. Proceedings of the 9th USENIX conference on Operating systems design and implementation (OSDrlO). 1-6. 2010.
[ 2]
FIBRE. Future Internet Tesbeds Experimentation Between Brazil and Europe [Online]. Avaliable: http://www.fibre-ict.eu/.
