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.
