Software-defined networks (SDNs) hold considerable. Software-Defined Networks: Incremental Deployment with Panopticon



Similar documents
Panopticon: Reaping the benefits of Incremental SDN Deployment in Enterprise Networks

Panopticon: Incremental SDN Deployment in Enterprise Networks

Logical SDNs: Reaping Software-Defined Networking Benefits Through Incremental Deployment

Panopticon: Reaping the Benefits of Incremental SDN Deployment in Enterprise Networks

Augmented reality (AR) user interfaces have

Auto-Configuration of SDN Switches in SDN/Non-SDN Hybrid Network

OVERLAYING VIRTUALIZED LAYER 2 NETWORKS OVER LAYER 3 NETWORKS

OpenFlow and Onix. OpenFlow: Enabling Innovation in Campus Networks. The Problem. We also want. How to run experiments in campus networks?

SDN Architecture Overview. Version 1.1 November, 2014 ONF TR-504

Wireless network traffic is dominated by

SDN AND SECURITY: Why Take Over the Hosts When You Can Take Over the Network

Ethernet-based Software Defined Network (SDN) Cloud Computing Research Center for Mobile Applications (CCMA), ITRI 雲 端 運 算 行 動 應 用 研 究 中 心

Software-Defined Networks Powered by VellOS

A Coordinated. Enterprise Networks Software Defined. and Application Fluent Programmable Networks

Opportunities and Research Challenges of Hybrid Software Defined Networks

Virtualization, SDN and NFV

Network Virtualization Solutions - A Practical Solution

CS6204 Advanced Topics in Networking

Central Control over Distributed Routing fibbing.net

Software Defined Network Application in Hospital

Improving Network Management with Software Defined Networking

Scaling 10Gb/s Clustering at Wire-Speed

Distributed Software-Defined Networking: The ACM PODC 2014 Workshop DSDN

A Presentation at DGI 2014 Government Cloud Computing and Data Center Conference & Expo, Washington, DC. September 18, 2014.

Network Virtualization

SDN Interfaces and Performance Analysis of SDN components

SDN and NFV in the WAN

Network Virtualization Network Admission Control Deployment Guide

White Paper. SDN 101: An Introduction to Software Defined Networking. citrix.com

ethernet services for multi-site connectivity security, performance, ip transparency

Leveraging SDN and NFV in the WAN

Virtual PortChannels: Building Networks without Spanning Tree Protocol

Transform Your Business and Protect Your Cisco Nexus Investment While Adopting Cisco Application Centric Infrastructure

Testing Network Virtualization For Data Center and Cloud VERYX TECHNOLOGIES

What is VLAN Routing?

Comparisons of SDN OpenFlow Controllers over EstiNet: Ryu vs. NOX

Software Defined Networking and OpenFlow: a Concise Review

Vocia MS-1 Network Considerations for VoIP. Vocia MS-1 and Network Port Configuration. VoIP Network Switch. Control Network Switch

SOFTWARE-DEFINED NETWORKING AND OPENFLOW

INTERNATIONAL JOURNAL OF PURE AND APPLIED RESEARCH IN ENGINEERING AND TECHNOLOGY

The Many Faces of SDN: An Industry Perspective

Cloud Computing Security: What Changes with Software-Defined Networking?

Formal Specification and Programming for SDN

OpenFlow/SDN for IaaS Providers

Applications of Software-Defined Networking (SDN) in Power System Communication Infrastructure: Benefits and Challenges

SOFTWARE-DEFINED NETWORKING AND OPENFLOW

Making Architecture Visible to Improve Flow Management in Lean Software Development

Introduction. The Inherent Unpredictability of IP Networks # $# #

Chapter 2 Addendum (More on Virtualization)

Facility Usage Scenarios

Mobility Management Framework in Software Defined Networks

Tutorial: OpenFlow in GENI

A Study on Software Defined Networking

Data Center Infrastructure of the future. Alexei Agueev, Systems Engineer

SOFTWARE-DEFINED NETWORKS

Operationalizing the Network: SDN

SDN Software Defined Networks

SDN, a New Definition of Next-Generation Campus Network

B4: Experience with a Globally-Deployed Software Defined WAN TO APPEAR IN SIGCOMM 13

SDN MIGRATION STRATEGIES The Case for Transitioning to an SDN-enabled Network

Introduction to Software Defined Networking (SDN) and how it will change the inside of your DataCentre

The Value of Open vswitch, Fabric Connect and Fabric Attach in Enterprise Data Centers

Network Functions Virtualization in Home Networks

The Promise and the Reality of a Software Defined Data Center

基 於 SDN 與 可 程 式 化 硬 體 架 構 之 雲 端 網 路 系 統 交 換 器

Testing Challenges for Modern Networks Built Using SDN and OpenFlow

Traffic Engineering for Multiple Spanning Tree Protocol in Large Data Centers

Software Defined Networking for Telecom Operators: Architecture and Applications

Solving Scale and Mobility in the Data Center A New Simplified Approach

SDN/Virtualization and Cloud Computing

How To Make A Vpc More Secure With A Cloud Network Overlay (Network) On A Vlan) On An Openstack Vlan On A Server On A Network On A 2D (Vlan) (Vpn) On Your Vlan

Why ISPs need SDN: SDN-based Network Service Chaining and Software-defined Multicast

Ethernet-based Software Defined Network (SDN)

Cisco Secure Network Container: Multi-Tenant Cloud Computing

Outline. Why Neutron? What is Neutron? API Abstractions Plugin Architecture

Software-Defined Networking Architecture Framework for Multi-Tenant Enterprise Cloud Environments

A Migration Path to Software-Defined Networking (SDN) in an Enterprise Network

SOFTWARE DEFINED NETWORKING: A PATH TO PROGRAMMABLE NETWORKS. Jason Kleeh September 27, 2012

Transactional Support for SDN Control Planes "

Network Virtualization: A Tutorial

software networking Jithesh TJ, Santhosh Karipur QuEST Global

How the Emergence of OpenFlow and SDN will Change the Networking Landscape

Analysis of Network Segmentation Techniques in Cloud Data Centers

SINGLE-TOUCH ORCHESTRATION FOR PROVISIONING, END-TO-END VISIBILITY AND MORE CONTROL IN THE DATA CENTER

Hypothesis Testing for Network Security

Enabling Practical SDN Security Applications with OFX (The OpenFlow extension Framework)

What is SDN? And Why Should I Care? Jim Metzler Vice President Ashton Metzler & Associates

Software Defined Networking

How To Understand and Configure Your Network for IntraVUE

Hyper-V Network Virtualization Gateways - Fundamental Building Blocks of the Private Cloud

Qualifying SDN/OpenFlow Enabled Networks

Simplifying Data Data Center Center Network Management Leveraging SDN SDN

Transcription:

Software-Defined Networks: Incremental Deployment with Panopticon Marco Canini, Université catholique de Louvain Anja Feldmann, Dan Levin, and Fabian Schaffert, Technische Universität Berlin Stefan Schmid, Telekom Innovation Labs, Technische Universität Berlin Practically speaking, most enterprises migrating to a software-defined network (SDN) must do so incrementally. Panopticon offers an approach for designing and operating an interim hybrid network that combines both traditional and SDN switches by exposing a logical SDN abstraction. Software-defined networks (SDNs) hold considerable promise for automating and radically simplifying computer network management a manual, error-prone task today. However, an immediate shift from existing network architectures to SDNs is unlikely on a broad scale because, despite some notable real-world deployments such as Google s softwaredefined WAN, 1 for most organizations, software-defined networking remains a largely experimental technology. Consequently, enterprises increasingly view hybrid networks those that combine an SDN with traditional network devices as a transitional step toward full SDN adoption. Yet despite their importance from a practical standpoint 2 and the challenges they likely pose over the long term, research focusing on such hybrid environments has so far been modest. From the outset, transition to an SDN should meet several specific goals: Provide clear and immediate benefits. Users will want to see an SDN s advantages with the first deployed switch. By contrast, Google s software-defined WAN required years to fully deploy, and benefits were realized only after the network switching infrastructure was completely overhauled. Most enterprises would find such a situation unthinkable. The earlier its return on investment, the more appealing SDN adoption will be viewed, and the more readily it will be accepted. Minimize disruption while establishing confidence. Even if existing switches already support SDN programmability, it is generally risky and undesirable for an enterprise to replace all production control protocols with an SDN control plane as a single flag day event. Rather, to increase chances for successful adoption, network operators must be able to deploy SDN technology incrementally, familiarizing users with its operation and building confidence in its reliability. This means starting with a small initial deployment 56 COMPUTER Published by the IEEE Computer Society 0018-9162/14/$31.00 2014 IEEE r11sch.indd 56

that can gradually widen as it encompasses more network infrastructure and traffic. Respect budgetary constraints. For budgetary reasons, it is generally necessary for any network reengineering to occur in stages, with operators upgrading parts of the network over time. 1 2 SDN control plane A 3 One approach for dealing with these challenges is to abstract a hybrid network into a logical SDN conceptually, a programmatic interface that exposes the network as if it were a full SDN deployment providing a logically centralized control plane for the incrementally deployable SDN. Panopticon offers such a network architecture. (b) B C D E F PANOPTICON Panopticon realizes a programming interface for a hybrid network by exposing a logical SDN abstraction. Specifically, as SDN switches are incorporated gradually into an existing network over time, Panopticon allows network operators to abstract away traditional network devices and operate the network as an SDN comprised of SDN-capable switches only. With careful planning, SDN capability can ultimately be extended to every network switchport. Alternatively, because network-resource constraints may prevent the full SDN abstraction in practice, not every port needs to be controlled through the SDN interface. Architecture Panopticon s architecture works on the principle that each network packet traversing an SDN switch can be treated according to end-to-end network policies, such as access control, defined via an SDN programming interface. Moreover, traffic that traverses two or more SDN switches can be controlled at finer levels of granularity to enable further, customized forwarding (to facilitate load balancing, for example). Thus, Panopticon extends SDN capabilities to traditional switches by ensuring that all traffic to or from any operator-selected, SDN-controlled (SDNc) port is restricted to a safe end-to-end path that is, a path traversing at least one SDN switch. We call this property waypoint enforcement. Panopticon uses virtual LANs (VLANs) to restrict forwarding on traditional network devices and guarantee waypoint enforcement because VLAN capabilities are ubiquitously available on existing switches. However, because VLAN ID space is limited to 4,096 values (IEEE standard 802.1Q) and hardware often supports even fewer, we devised a scalable waypoint enforcement mechanism, the solitary confinement tree. An SCT corresponds to a spanning tree and connects an SDNc port to certain SDN switches. As such, each SCT provides a safe path between an SDNc port and every SDN switch it connects to. A single VLAN ID is assigned to each SCT, ensuring traffic isolation and providing per-destination path diversity. A (a) Figure 1. Panopticon overview. (a) In this sample eight-switch hybrid network, the green discs represent software-defined network (SDN) switches, and the blue discs represent traditional switches; overlaid are solitary confinement trees (SCTs) for the SDN-controlled (SDNc) ports A through F. Each SCT is realized by its own virtual LAN (VLAN) ID, represented via different colors. (b) In the corresponding logical SDN, the SDNc ports are virtually connected to SDN switches via pseudo-wires, indicated by broken lines. Scalability stems from the fact that VLAN IDs can be reused for disjoint SCTs that is, SCTs that do not traverse a common traditional network device. Moreover, SCTs can be pre-computed and automatically installed onto traditional switches for example, via the Simple Network Management Protocol. Re-computation is required, however, when the physical topology changes. To illustrate, consider the eight-switch hybrid network shown in Figure 1a. Here, the orange links depict the SCT for SDNc port A, the gray links depict the SCT for SDNc port D, and the SCTs for the other ports are similarly color-coded. Figure 1b shows the corresponding logical SDN for the physical hybrid network that these SCTs enable. In this logical SDN, every SDNc port is connected to at least one SDN switch via a pseudo-wire, a connection realized by its SCT. SDN implementation Panopticon enables the active burden of network management to be gradually transitioned away from legacy B C D E F NOVEMBER 2014 57 r11sch.indd 57

SDNc Ports (%) 100 80 60 40 20 0 1,024 VLANs 512 VLANs 256 VLANs 17 15 24 33 42 51 60 69 78 87 96 106 117 128 139 Deployed SDN switches Figure 2. Using the Panopticon approach, the number of SDNc ports accommodated as a percentage of the number of deployed SDN switches depends on how many VLAN IDs the existing system hardware supports. devices and onto the SDN control plane a transition that can be realized at individual switchport granularity. While Panopticon does not strictly mandate how the SDN control plane interacts with the existing traditional control plane, we envision that each SDNc port will first implement the same high-level policies in effect prior to the transitioning process for example, preserving the original IP subnet address allocation. Thus, all policies governing traffic that originates from or is directed to SDNc ports can be defined exclusively at the SDN switches rather than at a combination of SDN and traditional devices. This strategy should effectively limit added complexity in managing the network during its transition to the SDN. Still, both the SDN and traditional control planes must coexist during this transition. Consequently, within SCTs, Panopticon relies on standard Spanning Tree Protocol mechanisms, where necessary, to achieve loop freedom and tolerate link failures. In addition, SDNc ports must be reachable from outside the logical SDN. For simple scenarios in which addressing within the logical SDN maintains compatibility with the existing IP subnet allocation, the traditional routing control plane and logical SDN can remain oblivious to one another. More commonly, though, addressing within the logical SDN violates the IP subnet allocation. To provide reachability in these instances, the SDN control plane could establish adjacencies with existing routing protocols, or routers could be configured with static routes for the IP subnets reachable through SDN switches. However, if at least one SDN switch is deployed in each IP subnet, it is possible to use a tunneling tprotocol such as Generic Routing Encapsulation to avoid interaction with the traditional existing routing control plane while ensuring reachability across IP subnets. Finally, to provide network applications with expected local network semantics, we rely on SDN capabilities to enable in-network proxies for Address Resolution and Dynamic Host Configuration protocols. OVERHEAD AND FEASIBILITY Panopticon s logical SDN abstraction does not come without cost: waypoint enforcement through SDN switches can in some cases lead to increased path lengths and require greater link utilization. Consequently, Panopticon presents operators with some resource performance tradeoffs, particularly in determining how the scope and means of partial SDN deployment will affect traffic generally. Still, the opportunities Panopticon offers for improving network traffic control for example, by enabling multipath forwarding for load balancing when sufficient path diversity exists should not be discounted. In navigating the deployment problem space, we have evaluated the approach s feasibility as follows. We consider a deployment feasible if the SDN switches have sufficient forwarding state to support all traffic policies they must enforce, and VLAN requirements to realize SCTs are within required limits. We simulated various partial SDN deployment scenarios based on different resource constraints and traffic conditions by using a large campus network topology of roughly 1,700 switches, as we discuss in greater detail elsewhere. 3 These simulations allowed us to evaluate the feasibility space of our architecture, explore the extent to which SDN control extends to the entire network, and understand the impact that partial SDN deployment has on link utilization and path stretch. As Figure 2 illustrates, the ability to accommodate more SDNc ports with a small number of SDN switches depends largely on the number of VLAN IDs the traditional 58 COMPUTER r11sch.indd 58

existing hardware supports for use. Under favorable conditions, with 1,024 VLANs, full SDNc port feasibility requires as few as 33 SDN switches. However, VLAN ID availability is necessary to construct SCTs: when traditional switches support at most 256 VLANs, more than 140 SDN switches must be deployed before full SDNc port feasibility can be achieved. To complement our simulation-based testing and further investigate the consequences Panopticon has for traffic, we also conducted a series of emulation-based experiments on portions of an actual enterprise network topology and further demonstrated the approach s systemlevel feasibility with a test-bed prototype. 3 RECENT RELATED WORK Our work contributes to a field that is attracting increasing attention from other researchers. Sugam Agarwal, Murali Kodialam, and T.V. Laksham, for example, have demonstrated effective engineering for traffic that crosses at least one SDN switch in a partial deployment. 4 Panopticon is an architecture that enforces this condition for all SDNc ports. In a paper on software-controlled routing protocols presented at the 2014 Open Networking Summit, Laurent Vanbever and Stefano Vissicchio described mechanisms to enable an SDN controller to indirectly program L3 routers by carefully crafting routing messages. 5 We view this work as complementary to ours in that it could be useful to increase control over traffic whose paths include IP routers. Ryan Hand and Eric Keller proposed an alternate approach to ours that they call ClosedFlow, which aims to enable SDN control over existing proprietary hardware by mimicking the fine-grained control available in OpenFlow. 6 Finally, Vissicchio, Vanbever, and Olivier Bonaventure have discussed certain tradeoffs that arise within a diverse set of hybrid SDN models and argue that hybrid SDN architectures deserve more attention from the scientific community. 7 We agree. We view Panopticon as a concrete step toward systematic, incremental deployment for SDNs. Accordingly, we have presented the approach at the Internet Research Task Force Working Group on SDN, and we plan to contribute our results to the ongoing discussions at the Open Networking Foundation s Migration Working Group. We hope that our work will offer a helpful reference point for practical hybrid software-defined networking and contribute to ongoing standardization efforts. PURPOSE: The IEEE Computer Society is the world s largest association of computing professionals and is the leading provider of technical information in the field. MEMBERSHIP: Members receive the monthly magazine Computer, discounts, and opportunities to serve (all activities are led by volunteer members). Membership is open to all IEEE members, affiliate society members, and others interested in the computer field. COMPUTER SOCIETY WEBSITE: www.computer.org Next Board Meeting: 26 30 January 2015, Long Beach, CA, USA EXECUTIVE COMMITTEE President: Dejan S. Milojicic President-Elect: Thomas M. Conte; Past President: David Alan Grier; Secretary: David S. Ebert; Treasurer: Charlene ( Chuck ) J. Walrad; VP, Educational Activities: Phillip Laplante; VP, Member & Geographic Activities: Elizabeth L. Burd; VP, Publications: Jean-Luc Gaudiot; VP, Professional Activities: Donald F. Shafer; VP, Standards Activities: James W. Moore; VP, Technical & Conference Activities: Cecilia Metra; 2014 IEEE Director & Delegate Division VIII: Roger U. Fujii; 2014 IEEE Director & Delegate Division V: Susan K. (Kathy) Land; 2014 IEEE Director-Elect & Delegate Division VIII: John W. Walz BOARD OF GOVERNORS Term Expiring 2014: Jose Ignacio Castillo Velazquez, David S. Ebert, Hakan Erdogmus, Gargi Keeni, Fabrizio Lombardi, Hironori Kasahara, Arnold N. Pears Term Expiring 2015: Ann DeMarle, Cecilia Metra, Nita Patel, Diomidis Spinellis, Phillip Laplante, Jean-Luc Gaudiot, Stefano Zanero Term Expriring 2016: David A. Bader, Pierre Bourque, Dennis Frailey, Jill I. Gostin, Atsuhiro Goto, Rob Reilly, Christina M. Schober EXECUTIVE STAFF Executive Director: Angela R. Burgess; Associate Executive Director & Director, Governance: Anne Marie Kelly; Director, Finance & Accounting: John Miller; Director, Information Technology & Services: Ray Kahn; Director, Membership Development: Eric Berkowitz; Director, Products & Services: Evan Butterfield; Director, Sales & Marketing: Chris Jensen COMPUTER SOCIETY OFFICES Washington, D.C.: 2001 L St., Ste. 700, Washington, D.C. 20036-4928 Phone: +1 202 371 0101 Fax: +1 202 728 9614 Email: hq.ofc@computer.org Los Alamitos: 10662 Los Vaqueros Circle, Los Alamitos, CA 90720 Phone: +1 714 821 8380 Email: help@computer.org MEMBERSHIP & PUBLICATION ORDERS Phone: +1 800 272 6657 Fax: +1 714 821 4641 Email: help@computer.org Asia/Pacific: Watanabe Building, 1-4-2 Minami-Aoyama, Minato-ku, Tokyo 107-0062, Japan Phone: +81 3 3408 3118 Fax: +81 3 3408 3553 Email: tokyo.ofc@computer.org IEEE BOARD OF DIRECTORS President: J. Roberto de Marca; President-Elect: Howard E. Michel; Past President: Peter W. Staecker; Secretary: Marko Delimar; Treasurer: John T. Barr; Director & President, IEEE-USA: Gary L. Blank; Director & President, Standards Association: Karen Bartleson; Director & VP, Educational Activities: Saurabh Sinha; Director & VP, Membership and Geographic Activities: Ralph M. Ford; Director & VP, Publication Services and Products: Gianluca Setti; Director & VP, Technical Activities: Jacek M. Zurada; Director & Delegate Division V: Susan K. (Kathy) Land; Director & Delegate Division VIII: Roger U. Fujii revised 23 October 2014 NOVEMBER 2014 59 r11sch.indd 59

References 1. S. Jain et al., B4: Experience with a Globally-Deployed Software Defined WAN, Proc. 2013 Annual Conf. ACM Special Interest Group Data Communication (SIGCOMM 13), 2013; http://conferences.sigcomm.org/sigcomm/2013/ papers/sigcomm/p3.pdf. 2. Migration Use Cases and Methods, Migration Working Group, Open Networking Foundation, 2014; www. opennetworking.org/images/stories/downloads/ sdn-resources/use-cases/migration-wg-use-cases.pdf. 3. D. Levin et al., Panopticon: Reaping the Benefits of Incremental SDN Deployment in Enterprise Networks, Proc. 2014 Usenix Annual Technical Conf., 2014, pp. 333 345; www.usenix.org/sites/default/files/atc14_full _proceedings.pdf. 4. S. Agarwal, M. Kodialam, and T.V. Lakshman, Traffic Engineering in Software Defined Networks, Proc. 32nd IEEE Int l Conf. Computer Communications (INFOCOM 13), 2013, pp. 2211 2219. 5. L. Vanbever and S. Vissicchio, Enabling SDN in Old School Networks with Software-Controlled Routing Protocols, Proc. 2014 Opening Networking Summit (ONS 14), 2014; http://vanbever.eu/pdfs/vanbever_hybrid_sdn _ons_2014.pdf. 6. R. Hand and E. Keller, ClosedFlow: OpenFlow-like Control over Proprietary Devices, Proc. ACM SIGCOMM Hot Topics in Software-Defined Networking (HotSDN 14), 2014, pp. 7 12. 7. S. Vissicchio, L. Vanbever, and O. Bonaventure, Opportunities and Research Challenges of Hybrid Software Defined Networks, ACM Computer Communication Rev., vol. 44, no. 2, 2014, pp. 70 75. Marco Canini is an assistant professor in the Institute of Information and Communication Technologies, Electronics, and lied Mathematics (ICTEAM) at Université catholique de Louvain, Belgium. His research interests include software-defined networking and large-scale and distributed cloud computing. Canini received a PhD in computer science and engineering from the University of Genoa. He is a member of IEEE and ACM. Contact him at marco.canini@ uclouvain.be. Anja Feldmann is a professor and dean of faculty in the Department of Engineering and Computer Sciences at Technische Universität (TU) Berlin. Her research interests include Internet routing and traffic analysis for network performance debugging. Feldman received a PhD in computer science from Carnegie Mellon University. In 2011, she was awarded the Gottfried-Wilhelm-Leibniz-Preis and the Berliner Wissenschaftspreis. Contact her at anja@inet. tu-berlin.de IEEE Open Access Unrestricted access to today s groundbreaking research via the IEEE Xplore digital library IEEE offers a variety of open access (OA) publications: Hybrid journals known for their established impact factors New fully open access journals in many technical areas A multidisciplinary open access mega journal spanning all IEEE fields of interest Discover top-quality articles, chosen by the IEEE peer-review standard of excellence. Dan Levin received a PhD in computer science in 2014 from TU Berlin, where his research focused on software-defined networking. His work on hybrid incremental SDN deployment won first prize in the ACM graduate student research competition at SIGCOMM 2013. Formerly a software developer at Andeen Hagerling, Levin is a member of ACM. Contact him at dan@badpacket.in. Fabian Schaffert received an MS in computer engineering from TU Berlin in 2014. His research interests include hybrid deployment of software-defined networks. Contact him at fabian@badpacket.in. Stefan Schmid is a senior research scientist with Telekom Innovation Labs at TU Berlin, as well as a visiting professor at Centre National de la Recherche Scientifique, France. His research interests include distributed systems, especially the design of robust and dynamic networks. Schmid received a PhD in computer science from ETH Zürich. Contact him at stefan.schmid@tu-berlin.de. Learn more about IEEE Open Access www.ieee.org/open-access Selected CS articles and columns are available for free at http://computingnow.computer.org. 60 COMPUTER 12-TA-0424-Open Access 3.25x4.75 Final.indd 1 9/24/12 10:06 AM r11sch.indd 60