Hybrid SDN Controller Architecture: SYMPHONY

Fourth European Workshop on Software Defined Networks
SYMPHONY-A Controller Architecture for Hybrid
Software Defined Networks
Vijaya Durga Chemalamarri
Priyadarsi Nanda and Karla Felix Navarro
School of Computing and Communications
Faculty of Engineering and Information Technology
University of Technology Sydney, Australia
[email protected]
School of Computing and Communications
Faculty of Engineering and Information Technology
University of Technology Sydney, Australia
{Priyadarsi.Nanda, Karla.FelixNavarro}@uts.edu.au
OpenFlow (OF) enabled data-plane but does not exercise any
control on the legacy networks. Moreover, other models
proposed for brownfield deployments operate at Layer 2 (L2),
and do not address the integration with the control plane at
Layer 3 (L3).
Thus, the framework proposed in this paper focuses on the
specific problem of bridging legacy control plane with the
SDN control plane at Layer 3. To do so, we use OSPF as
communication protocol between legacy plane and SDN
controller. In particular, the proposed architecture,
SYMPHONY, establishes communication between the legacy
network and the SDN domain through a Legacy Route Server
(LRS) connected to the SDN controller. The LRS acts as
central repository and stores topology information of the legacy
network. The controller prototype, operation and the
preliminary tests performed to verify interoperability between
legacy and OpenFlow domains are described in the following
sections of this paper.
The succeeding sections of this paper discuss about existing
frameworks for Hybrid SDNs (Section II), requirements and
challenges involved in building hybrid SDN controller (Section
III & IV), our proposal for building such a controller (Section
V), the prototype design and its operational overview (Section
VI), functional use case for preliminary testing (Section VII)
and lastly the conclusion.
Abstract— As enterprises migrate to SDN, a brownfield network
transitional state is inevitable, where both Software Defined and
Legacy networks coexist. The aim of this work is to further the
knowledge in the area of Hybrid Software Defined Network
(SDN) networks, by investigating requirements and challenges
involved in building such networks. This work proposes a Hybrid
SDN controller architecture to establish, control and interdomain communication between the legacy and SDN domains.
Keywords—Hybrid SDN; SDN migration; OSPF; OpenFlow.
I.
INTRODUCTION
Current networks are IP and Ethernet based deployments.
Migrating these networks to Software Defined Networks
(SDN) would need a complete overhaul of existing network
devices or upgrading the firmware to support OpenFlow
devices. This paper looks into the possibility of building and
operating brownfield networks, or networks in transition from
existing infrastructure, where both SDN and legacy devices can
coexist. Such coexistence demands an interoperability and
integration between IP control plane of legacy networks and
control plane of SDN networks.
Interoperability between legacy IP and SDN control planes
opens up a variety of opportunities for various stakeholders and
to the network in general. For example, an integrated control
plane makes network planning, configuration and management
effortless for the network engineers by providing a single plane
of operation. Also, ‘tying’ critical IP devices with OpenFlow
devices provides the traditional devices with a new data-plane,
which can be configured centrally, thus attaining SDN-like
control over traditional network devices. Also, investment in
new equipment can be drastically reduced by not having to do
a complete overhaul of the existing legacy network.
By focusing on IP and SDN integration, IP specific
functionalities, especially policy configuration such as traffic
policing, ACLs, and policy based routing, could be integrated
into networks in a more flexible and easier to manage
centralized fashion. These policies can then be transformed into
OpenFlow flow table entries and be applied to the data plane,
thus eliminating per box policy configuration.
Much of the existing work in SDN focuses on greenfield
deployments where an OpenFlow controller controls
978-1-5090-0180-4/15 $31.00 © 2015 IEEE
DOI 10.1109/EWSDN.2015.61
10.1109/.20
II.
EXISTING SOLUTIONS
Some of the most predominant Hybrid SDN frameworks
proposed are RouteFlow [3], LegacyFlow [4], Panopticon [10],
Cardigan [13], HybNET [8] and I2RS [1]. RouteFlow
virtualizes all OpenFlow enabled nodes as L3 devices and thus
bridges legacy and SDN domains. Some of the posed
limitations are the added complexity, multiple points of failure
and complete isolation of the OpenFlow domain in case the
RouteFlow (RF) server goes down. The I2RS framework uses
ForCES [15] as communication protocol between the control
and data planes; hence the adoption of a yet another
communication protocol (ForCES) is a key challenge. The
Cardigan framework is an implementation of RouteFlow in one
of the operational modes and hence similar challenges as
RouteFlow apply. Panopticon integrates SDN and legacy
networks at layer 2 by using VLANS and policy enforcement
55
and allow network engineers to perform tests on active
network 'maps' to analyse the effect of changes. Through
seamless incorporation of SDN into a legacy network domain,
the controller can simply be cloned into a test environment
and relevant changes/upgrades can be performed, conflicts in
policy can be verified, rectified and deployed on the main
controller.
such as application of ACLs is still done in the traditional
manner on a per box basis. LegacyFlow currently addresses
concerns at Layer 2, hence it is unclear if other legacy devices
such as routers will have their LegacyFlow datapath
configured. HybNET integrates at L2 layer but the number of
VLANs that can be created (max. 4096) imposes a restriction
on the number of slices that can be used. SUMA [19] on the
other hand is a unified monitoring middle-box, which unifies
Legacy NMS, SDN controller, and OpenFlow switches. This
framework does not suggest intercommunication between
legacy and SDN networks. Other recent works in the area such
as [23] aims to enhance existing legacy network by dividing it
into domains and establishing communication within the OSPF
domains by controlling OF devices.
III.
D. Simplified policy
A centralized controller should simplify the task of network
management and SDN controller manages only OpenFlow
(OF) enabled nodes. A centralized hybrid SDN controller
should manage policies through out the network by perceiving
the Autonomous System (AS) as one single logical
homogenous domain. Any prevalent anomalies within the
policy computation such as conflicting routing policies, ACLs,
and Policy Based routing (PBR) rules should be either
highlighted to the network engineer for further action or
handled proactively by the controller. The controller should be
capable of offering improved operation, administration and
management (including policy dispatching) capabilities in
terms of traffic engineering, and QoS adherence among others.
REQUIREMENTS FOR BUILDING A HYBRID SDN
CONTROLLER
SDN control-data plane interaction mechanisms do not
apply to traditional networks and vice versa. Also, given that
SDN centralizes the network control whereas a legacy
network control is distributed in nature, there is a need to
revisit some of the fundamental networking requirements such
as reachability and reliability of routes within the realm of a
hybrid SDN. This section highlights some key requirements
for building hybrid SDN.
IV.
CHALLENGES TO BE ADDRESSED
This section highlights the challenges to be addressed while
building a framework for Hybrid SDN. The challenges can be
broadly categorized as 1) control plane challenges and 2)
management plane challenges. As a guideline for discussing
control plane challenges, this work refers to routing
pathologies highlighted by V. Paxson in 1996 [17] and more
recently by others authors [18]. Control plane challenges
affect functions of path computation, routing states
maintenance, and routing protocols operation among others.
Communication and synchronization between the SDN control
plane and legacy control plane needs to be accomplished by
addressing these challenges. For sake of clarity, we will be
referring Legacy routers as routers and OpenFlow enabled
switches as OFswitch and boundary nodes separating both the
domains as Edge node.
A. Route validity and path visibility
In the context of hybrid SDN, a route can be considered to
be valid if there is a consistent path between any two hosts and
the path terminates at a desired destination, which implies that
consistent paths need to exist between the hosts in the legacy
network and hosts in SDN. The controller plays a vital role in
propagating valid routes across the two domains, thus
providing path visibility.
B. Fault tolerance, detection and rectification
Any link failure or congestion within the network (either in
the traditional or the SDN domains) should prompt the
controller to compute alternate paths and update flow tables
accordingly. The convergence time of a hybrid network in
such cases should be at least the same as in traditional
networks. Also, controller redundancy, and its placement
should be given a comprehensive thought in this context.
A. Legacy control traffic
As depicted in Figure 1, routers 1 and 2 run OSPF routing
protocol to form an adjacency. For these routers to become
neighbours it is important that the route signalling packets
pass through OFswitches 1, 3, 2. The routing protocol control
messages between routers1, 2 are forwarded by OFswitches 1,
3, and 2 to the controller for processing, followed by the
installation of flow table entries by the controller. Exchange of
control packets (OSPF LSAs) should complete within the
timers set for legacy protocols for routers to become
neighbours. Any delays in OSPF hello packets exchange
process could prevent legacy routers from forming OSPF
adjacencies. Thus, the controller should handle legacy control
traffic appropriately.
C. Planning, testing, deployment and active network
management to benefit the existing legacy networks
Current network deployment models leave much of the
network planning, configuration and validation activities to
the network engineer. Instead, in a hybrid network
environment the SDN controller, which stores topology and
policy information about the entire network, should be
leveraged to simplify the planning-to-deployment cycle and
improve the success rate of any network implementation.
Moreover, network-monitoring tools should be more dynamic
56
B. Inefficient policy configuration (non-optimal path routes)
Consider a communication instance between a host in an
OF domain and a host in a legacy network. Both inefficient
and inconsistent policy configuration can lead to the packet
taking a longer and inefficient route. Hence, the controller
needs to perform complete traffic engineering for efficient
routing. For example, in an equal cost network, the
communication between the hosts connected to OFswitch4 to
remote network 3.3.3.3 should typically use path via
OFswitches 4, 1 and not via OFswitches 4, 3 ,2 .
C. Invalid Routes due to routing loops caused by inconsistent
policy configuration
Fig. 1. Hybrid Network
B. Invalid Routes due to choice of inappropriate egress nodes
in the legacy network domain
As in any legacy network, forwarding loops can be caused
by either physical or logical misconfiguration. For example,
packets from router1 can be rerouted back to router1 due to
inconsistent policies configured on multiple nodes.
In the case of a topology based hybrid architecture [14], if
only one link connects SDN to the legacy network, a static
route can be used to bridge both domains. Contrastingly, in the
presence of multiple edge OF nodes (OFswitch1, OFswitch2)
as in Fig.1, the controller should not only compute the best
path within the OF domain but also have visibility over how
packets are handled in the legacy network. For instance, as
depicted in Fig.1 within the OF domain, the controller
determines OFswitch2 as the best edge node for a flow
originating from host (11.11.11.102) and destined to a remote
host in the legacy domain, but within the legacy domain,
router1 has the best route to said remote host. Thus, the
controller needs to deem OFswitch1 as the suitable edge node
instead of OFswitch2.
V.
PROPOSED HYBRID SDN CONTROLLER ARCHITECTURE
The purpose of the proposed hybrid SDN controller is to
allow seamless data communication between legacy domain
and SDN domain by bridging the control planes of SDN and
legacy domains. The remainder of this section details the
architecture and components of the prototyped hybrid SDN
controller aiming to bridge the control planes of legacy and
OF devices. The hybrid SDN controller orchestrates legacy
and SDN control domains, hence the name -SYMPHONY.
One of the driving factors behind the architecture is to allow
the controller to install flows proactively on the data plane to
avoid the delays caused by reactive flow computation and
installation. Thus, SYMPHONY consists of two main
components - Legacy Routing Server (LRS) and a Packet
forwarder module to compute the path between the source and
destination hosts and install flow table entries on the OF
switches constituting the path.
The following subsection contains some of the main
challenges that affect path/route management plane functions
such as configuration of policies for traffic engineering,
ACLs, and network availability monitoring. These challenges
can be addressed only when the controller maintains a global,
unified view of the hybrid network.
A. Invalid Routes due to ill-transformed policies between
centralized and distributed domains
While Packet Forwarder, Path Finder, LLDP, and Next Hop
components reside within controller, the LRS is a legacy route
repository. The Packet Forwarder along with LRS is referred
to as the Hybrid SDN controller. In addition to the above,
other passive components include files such as Hosts.txt,
Switches.txt and Edges.txt to store topology information used
by the controller to proactively install flows on the determined
set of OF switches. The architecture of the controller is
illustrated in Fig. 2. The destination OF switch is either a
switch directly connected to the destination or an edge node
connecting to a legacy router. While the destination OF switch
is referred to as target switch, the OF switches which
constitute the path are referred as intermediate OF switches.
The following subsections briefly discuss each of
SYMPHONY’s modules in more detail.
As mentioned earlier, the centralized controller can only
control OF-enabled devices, and has no visibility over the
policies running on traditional nodes. Consider that router1 is
configured with an ACL to deny traffic on the interface
connecting to OFswitch1. The controller on the other hand,
might determine OFswitch1 as the edge node and install flow
table entries on OFswitch1 resulting which, OFswitch1
forwards packets to router1 and router1 dropping all the
packets that match the ACL deny statement. Since the
controller is unaware of any policies configured in the legacy
domain, the controller has no way to quarantine this path and
use OFswitch2 as the exit link, unless a rule is set in the
controller manually.
57
Fig. 3. Architecture of SYMPHONY
switches to forward the packets. The controller then installs
appropriate flow table entries on the determined OFswitches
leading to the destination node.
Fig. 2. Interaction between LRS and Legacy Network
Other passive components such as Switches, Hosts and Edges
files assist the controller to compute and install flows
proactively on OF switches. In the absence of these files, the
controller should compute and install flows reactively, a
situation that can cause latency in large networks. Thus, by
storing the topology information in specific files makes the
information readily available to the controller and enables the
controller to install flows proactively.
A. Packet Forwarder:
The Packet Forwarder component performs the main
controller processes, by listening to OF events raised by the
data-plane. The Packet Forwarder module is a sequence of
decision making statements that is executed when an OF event
is raised on the controller. In this functional prototype the
Packet Forwarder module listens and handles ConnectionUp,
PacketIn and PortStatus type of OF events.
VI.
IMPLEMENTATION AND OPERATION
As mentioned earlier, SYMPHONY handles PacketIn,
ConnectionUp and PortStatus OF messages only. In future,
the authors recommend expanding this feature by building
handlers for other event types. Upon listening to a
ConnectionUp event the controller uses LLDP based discovery
process to discover OF switches and update the Switches file
accordingly.
B. Legacy Routing Server:
The Legacy Routing Server (LRS) module is a Linux
container that runs Quagga [22] routing engine. By
establishing OSPF neighbouring relationships with legacy
network, LRS maintains a logical view of the legacy network.
The controller consults LRS to choose the next best hop for a
remote destination host residing in the legacy domain. The
neighbouring relationship between LRS and edge routers is
illustrated in Fig. 3.
The Packet Forwarder module replicates the behaviour of a
legacy L3 router while handling OF events from data plane.
While executing functions such as IP unicast, and IP multicast
to handle legacy unicast and multicast packets, the module
also performs OF related activities such as queuing packets to
data planes, inserting flows and removing flows through
various OF messages such as ofp_flow_mod, ofp_packet_out.
The controller processes an incoming packet by verifying the
packet payload and determines the course of action for
handling the packet. For example, if the incoming packet’s
payload is a routing control multicast packet (OSPF hello
packets), the controller determines a set of target OF switches
(typically edge OF switches) to queue the packet to; along
with the target OF switches, the controller queues the packet
to the OVS bridge, connecting to the Legacy Routing Server
(LRS) module. Thus, LRS also receives OSPF updates from the
legacy L3 network and establishes a neighbour relation with
the edge routers. On instances where the packet is destined to
a specific destination, the controller evokes the unicast
component, resulting in a path discovery process between the
source and destination, followed by proactive installation of
C. Path-Finder:
As the name suggests the Path-Finder module assists the
controller to find optimal paths within the OF domain by
running Dijikstra’s Shortest Path First (SPF) algorithm using
the switches.txt as input. Switches.txt is a network graph built
with the aid of the LLDP module. The Path-Finder component
returns a set of OF switches to install flows between source
and destination nodes.
D. Next-Hop:
The Next Hop module queries the LRS and returns the best
edge router to reach a remote destination. The PacketForwarder module then, nominates the corresponding edge
OF switch connected to the edge router as target (or
destination) OF switch , followed by the compiling of a set of
intermediate switches between the source and destination OF
58
Fig. 4. LRS Routing Table
flow table entries on all the intermediate OF switches. Upon
link failures, the controller chooses best alternative path to
route the packets. The Quagga routing engine running on LRS
listens to OSPF routing updates (on the interface eth1 of LRS)
to form OSPF adjacencies with all the edge L3 routers and
builds a legacy topology table. Finally, the Edges file stores
details of edge OF switches and the corresponding connected
edge L3 routers. The above functionality can be juxtaposed to
OSPF neighbouring relationships establishment over a LAN
setup.
Fig. 5. Path computation and installation of flows
source OF switch and the target OF switch and flows are
proactively installed on all the intermediate OF switches.
Similarly, if the packet is destined to multiple destinations, a
set of affected target switches is chosen. For example, in case
the packet is an OSPF multicast packet, edge OF switches are
determined as target switches. For other L2 broadcast packets,
all the switches and access ports of them connecting to hosts
are chosen as target switches and target ports to forward the
packet on.
A. Communication between POX and LRS
The SDN controller (POX) [20] controls or manages OF
switches while LRS is deployed in a Linux container within
the same server running the SDN controller (Fig. 3). The LRS
and POX controller communicate over a Linux inbuilt OF
enabled OpenVSwitch (OVS), thus allowing POX to interact
with LRS as with any other host connected to an OF switch.
As such, the interface eth0 on LRS communicates with the
host machine via a Linux Bridge, whereas the interface eth1 of
the LRS connects to the OVS, which is controlled by the SDN
controller (fig.2.).
The Edges file here acts as a cache for the SDN controller
to query before referring to the LRS module. This feature is
advantageous for time bound packet-processing activity such
as the establishment of OSPF neighbouring relationships. If
the destination IP is not found in Edges, the controller then
refers to the LRS module to find a valid next hop for the
destination IP. The controller then acquires the next-hop router
details from LRS and determines the corresponding edge OF
switch via the Edges file.
B. Data handling mechanism:
The following subsection explains SYMPHONY’s IP
packet handling mechanism in detail. Upon the completion of
the packet handling, the process installs flows on a set of OF
switches leading to the destination. Based on the packet
destination, the target OF switch and set of intermediate OF
switches are chosen. For example in case of a unicast packet,
the target switch is a single OF switch. All the OF switches
which constitute the path between source and destination OF
switches are deemed as a intermediate switches. With the aid
of the Hosts file, it can be determined if the destination
address belongs to a node connected to an OF switch. If the
host is configured within the OF domain, the OF switch
connected to the host is nominated as target switch and a path
is computed. In case the destination node is not configured
within OF domain, the controller performs a look-up on Edges
file to determine if the packet is destined to an edge router. If
the packet is destined to an edge router, the controller
determines the connecting OFswitch as target switch. If the
destination node is neither connected to an OF switch nor to
an edge router is when POX refers to the LRS module to
determine if the address is located in the legacy network, in
which case a suitable next-hop edge router and the
corresponding connecting edge OF switch (target OF switch)
are determined. The preferred path is computed between the
It has to be noted that the controller at no point broadcasts
any packets. In order to ensure this, broadcast packets (such as
ARP) are not forwarded onto the switch interfaces connecting
other switches, but only on those interfaces connecting to end
hosts. This simple validation avoids L2 looping and broadcast
storms in the network. Moreover, in case the packet is
destined to the legacy network, the controller updates the
packet with the appropriate edge router details, thus ensuring
that a best and valid path is chosen.
VII.
PRELIMINARY TESTS
SYMPHONY’s preliminary testing is based on the three
data communication cases that can arise based upon the source
and destination details. The communication can be between
any 1) two hosts in a legacy network 2) two hosts in an
OpenFlow network and 3) between a legacy host and an
OpenFlow host.
The authors emulated a topology Fig. 5 where an OF island
resides within a legacy network using Mininet [21] and
miniNExT
[7].
Initial
tests
indicated
successful
communication between any hosts. Fig. 4 illustrates LRS
59
routing table, which is now populated with all the legacy
networks. For communication within OF domain (such as
between h3 and h4) the controller doesn’t refer to LRS. For
routing OSPF packets the controller refers to Edges file and
for all the inter-domain communication such as the packets
destined to remote legacy network 200.200.200.2 from host at
11.11.11.101, controller refers to LRS. In this use case, the
controller determines router2 and OFswitch2 as edge nodes to
reach remote network 200.200.20.0. With source OF switch as
OFswitch4, target OF switch as OFswitch2, the controller
installs flows on OFswitch4, OFswitch3 and OFswitch2 to
route the packets. Upon the failure of link OFswitch3,
OFswitch2 an alternate path via OFswitch5 was computed. As
can be observed, the flows are installed proactively only on a
set of switches which constitute the path between source and
destination.
[5]
VIII. CONCLUSION
[11]
[12]
[6]
[7]
[8]
[9]
[10]
Hybrid SDN networks are the natural state for networks
transitioning from legacy network towards SDN. To address
the challenges and requirements for maintaining such hybrid
networks as discussed in Section III, this work proposed and
described the operation of a hybrid SDN controller
architecture to integrate the control planes of Legacy and
Software Defined Networks. This work allows for the
coexistence of legacy and OF enabled networks, and opens up
exciting opportunities towards the building of a management
platform, or a centralised policy engine for Hybrid Networks.
The architecture consists of two main components, a POX
based Packet Forwarder and a Legacy Routing Server (LRS)
module acting as a legacy topology database. POX along with
the LRS module enables communication between legacy and
OF domains. The architecture succeeds in choosing: a)
optimal paths between any two hosts, b) best edge legacy
router to communicate with legacy networks and c)
recomputed paths in case of link failures. Future work in this
area will focus on further investigating and testing the
feasibility of hybrid SDN networks as a prospective
deployment model or merely as temporary stage during
migration.
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
REFERENCES
[1]
[2]
[3]
[4]
A. Atlas, T. Nadeau and D. Ward, "Interface to the Routing System
Problem Statement draft-ietf-i2rs-problem-statement-04," .
R. Bennesby, P. Fonseca, E. Mota and A. Passito, "An inter-AS routing
component for software-defined networks," Network Operations and
Management Symposium (NOMS), 2012 IEEE, pp. 138-145, 2012.
C. E. Rothenberg, M. R. Nascimento, M. R. Salvador, C. N. A. Corrêa,
S. Lucena C. de and R. Raszuk, "Revisiting Routing Control Platforms
with the Eyes and Muscles of Software-Defined Networking," .
F. Farias, J. Salvatti, P. Victor and A. Abelem, "Integrating legacy
forwarding environment to OpenFlow/SDN control plane," Network
Operations and Management Symposium (APNOMS), 2013 15th AsiaPacific, pp. 1-3, 2013.
[21]
[22]
[23]
[24]
60
N. Feamster, H. Balakrishnan, J. Rexford, A. Shaikh and J. v. d. Merwe,
"The Case for Separating Routing from Routers," FDNA '04
Proceedings of the ACM SIGCOMM Workshop on Future Directions in
Network Architecture, pp. 5-12, 2004.
N. Feamster, J. Rexford, A. Shaikh and J. v. d. Merwe, " Route Control
Platform Architecture and Practical Concerns " .
A. Gupta, L. Vanbever, M. Shahbaz, Donovan,P.,Schlinker,B., N.
Feamster, J. Rexford, S. Shenker, R. Clark and E. Katz-Bassett, "SDX:
A Software Defined Internet Exchange," .
L. Hui, N. Arora, Z. Hui, C. Lumezanu, J. Rhee and J. Guofei,
"HybNET: Network Manager for a Hybrid Network Infrastructure,"
Middleware Industry '13 Proceedings of the Industrial Track of the 13th
ACM/IFIP/USENIX International Middleware Conference, 13.
S. Jain , A. Kumar , S. Mandal , O. Joon , L. Poutievski, A. Singh , V.
Subbaiah , J. Wanderer , Z. Junlan , Z. Min, J. Zolla , U. Hölzle , S.
Stuart and A. Vahdat , "B4: Experience with a Globally-Deployed
Software Defined WAN," .
[D. Levin, M. Canini, S. Schmid and A. Feldmann, "Incremental SDN
deployment in enterprise networks," SIGCOMM '13 Proceedings of the
ACM SIGCOMM 2013 Conference on SIGCOMM, pp. 473, 2013.
Migration Working Group, "Migration Use Cases and Methods," .
S. Salsano, P. L. Ventre, L. Prete, G. Siracusano, M. Gerola and E.
Salvadori, "OSHI - Open Source Hybrid IP/SDN networking (and its
emulation on Mininet and on distributed SDN testbeds)," EWSDN
2014,3rd European Workshop on Software Defined Networks, 2014.
J. P. Stringer , F. Qiang, C. Lorier, R. Nelson and C. E. Rothenberg,
"Cardigan: Deploying a Distributed Routing Fabric," HotSDN '13
Proceedings of the Second ACM SIGCOMM Workshop on Hot Topics
in Software Defined Networking, pp. 169-170, 2013.
S. Vissicchio, L. Vanbever and O. Bonaventure, "Opportunities and
research challenges of hybrid software defined networks," ACM
SIGCOMM Computer Communication Review, vol. 44, 2014.
L. Yang, R. Dantu, T. Anderson and R. Gopal, "Forwarding and Control
Element Separation (ForCES) Framework - rfc3746," 2004.
[16] N. McKeown, G. Parulkar, T. Anderson, L. Peterson, H.
Balakrishnan and J. Rexford, "OpenFlow-Enabling Innovation in
Campus Networks ", ACM SIGCOMM Computer Communication
V. Paxson, " End-to-End Routing Behavior in the Internet " SIGCOMM
'96 Conference Proceedings on Applications, Technologies,
Architectures, and Protocols for Computer Communications, pp. 25-38,
1996.
J. Rexford, A. Greenberg, G. Hjalmtysson, D. A. Maltz, A. Myers,
G.Xie, J. Zhan, and H. Zhang, “Network-wide decision making:
Towarda wafer-thin control plane,” presented at the HotNets, Nov. 2004.
C. Taesang, S. Sejun, H. Park , Y. Sangsik and Y. Sunhee, "SUMA:
Software-defined Unified Monitoring Agent for SDN," Network
Operations and Management Symposium (NOMS), 2014 IEEE, pp. 1-5,
may, 2014.
POX(2015):[Online].
Available:https://openflow.stanford.edu/display/ONL/POX+Wiki
[Accessed: Jun, 12, 2015].
Mininet (2015):[Online].Available:http://mininet.org [Accessed: Jun, 12,
2015].
GNU Quagga Project. http://www.nongnu.org/quagga/. [Accessed: Jun,
12,2015]
Caria, Marcel; Das, Tamal; Jukan, Admela, "Divide and conquer:
Partitioning OSPF networks with SDN," Integrated Network
Management (IM), 2015 IFIP/IEEE International Symposium on , vol.,
no., pp.467,474, 11-15 May 2015
S. Vissicchio , L. Vanbever and J. Rexford, " Sweet Little Lies: Fake
Topologies for Flexible Routing " HotNets-XIII Proceedings of the 13th
ACM
Workshop
on
Hot
Topics
in
Networks,
2014.