software-defined networks: incremental deployment with ... · enable sdn control over existing...

5
56 COMPUTER Published by the IEEE Computer Society 0018-9162/14/$31.00 © 2014 IEEE COVER FEATURE Practically speaking, most enterprises migrating to a software-defined network (SDN) must do so incrementally. Panopti- con offers an approach for designing and operating an interim hybrid network that combines both traditional and SDN switch- es by exposing a logical SDN abstraction. S oftware-defined networks (SDNs) hold consid- erable 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 software- defined WAN, 1 for most organizations, software-defined networking remains a largely experimental technol- ogy. 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 de- ployed switch. By contrast, Google’s software-defined WAN required years to fully deploy, and benefits were realized only after the network switching infrastruc- ture 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 program- mability, it is generally risky and undesirable for an enterprise to replace all production control proto- cols with an SDN control plane as a single “flag day” event. Rather, to increase chances for successful adop- tion, 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 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 r11sch.indd 56 10/24/14 2:04 PM

Upload: others

Post on 18-Mar-2020

11 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Software-Defined Networks: Incremental Deployment with ... · enable SDN control over existing proprietary hardware by mimicking the fine-grained control available in OpenFlow. 6

56 COMPUTER Published by the IEEE Computer Society 0018-9162/14/$31.00 © 2014 IEEE

COVER FE ATURE

Practically speaking, most enterprises migrating to a software-defined network (SDN) must do so incrementally. Panopti-con offers an approach for designing and operating an interim hybrid network that combines both traditional and SDN switch-es by exposing a logical SDN abstraction.

S oftware-defined networks (SDNs) hold consid-erable 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 software-defined WAN,1 for most organizations, software-defined networking remains a largely experimental technol-ogy. 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 standpoint2 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 de-ployed switch. By contrast, Google’s software-defined WAN required years to fully deploy, and benefits were realized only after the network switching infrastruc-ture 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 program-mability, it is generally risky and undesirable for an enterprise to replace all production control proto-cols with an SDN control plane as a single “flag day” event. Rather, to increase chances for successful adop-tion, 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

Software-Defined Networks: Incremental Deployment with PanopticonMarco 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

r11sch.indd 56 10/24/14 2:04 PM

Page 2: Software-Defined Networks: Incremental Deployment with ... · enable SDN control over existing proprietary hardware by mimicking the fine-grained control available in OpenFlow. 6

NOVEMBER 2014 57

that can gradually widen as it encompasses more net-work infrastructure and traffic.

• Respect budgetary constraints. For budgetary reasons, it is generally necessary for any network reengineer-ing to occur in stages, with operators upgrading parts of the network over time.

One approach for dealing with these challenges is to ab-stract 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 central-ized control plane for the incrementally deployable SDN. Panopticon offers such a network architecture.

PANOPTICONPanopticon realizes a programming interface for a hybrid network by exposing a logical SDN abstraction. Specifi-cally, 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. Al-ternatively, because network-resource constraints may prevent the full SDN abstraction in practice, not every port needs to be controlled through the SDN interface.

ArchitecturePanopticon’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. More-over, traffic that traverses two or more SDN switches can be controlled at finer levels of granularity to enable fur-ther, 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 for-warding on traditional network devices and guarantee waypoint enforcement because VLAN capabilities are ubiq-uitously 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 traf-fic isolation and providing per-destination path diversity.

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 tra-ditional switches—for example, via the Simple Network Management Protocol. Re-computation is required, how-ever, 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 physi-cal 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 implementationPanopticon enables the active burden of network man-agement to be gradually transitioned away from legacy

(a)

(b)

A

B

C

D

F

E

SDN control plane

App 1

App 2

App 3

B C D E F

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.

r11sch.indd 57 10/24/14 2:04 PM

Page 3: Software-Defined Networks: Incremental Deployment with ... · enable SDN control over existing proprietary hardware by mimicking the fine-grained control available in OpenFlow. 6

58 COMPUTER

COVER FE ATURE

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 combina-tion of SDN and traditional devices. This strategy should effectively limit added complexity in managing the net-work 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 reach-ability 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 Rout-ing 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 Reso-lution and Dynamic Host Configuration protocols.

OVERHEAD AND FEASIBILITYPanopticon’s logical SDN abstraction does not come with-out cost: waypoint enforcement through SDN switches can in some cases lead to increased path lengths and require greater link utilization. Consequently, Panopticon pres-ents 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 for-warding 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 condi-tions 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

100

80

60

40

20

0

17 15 24 33 42 51 60 69 78 87 96 106 117 128 139

Deployed SDN switches

SDNc

Ports

(%)

1,024–VLANs

512–VLANs

256–VLANs

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.

r11sch.indd 58 10/24/14 2:04 PM

Page 4: Software-Defined Networks: Incremental Deployment with ... · enable SDN control over existing proprietary hardware by mimicking the fine-grained control available in OpenFlow. 6

NOVEMBER 2014 59

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 tradi-tional 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 fur-ther investigate the consequences Panopticon has for traffic, we also conducted a series of emulation-based ex-periments on portions of an actual enterprise network topology and further demonstrated the approach’s system-level feasibility with a test-bed prototype.3

RECENT RELATED WORKOur 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 in-crease control over traffic whose paths include IP routers.

Ryan Hand and Eric Keller proposed an alternate ap-proach 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 di-verse set of hybrid SDN models and argue that hybrid SDN architectures deserve more attention from the scientific community.7 We agree.

W e 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 dis-cussions 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 COMMITTEEPresident: Dejan S. MilojicicPresident-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 GOVERNORSTerm Expiring 2014: Jose Ignacio Castillo Velazquez, David S. Ebert, Hakan Erdogmus, Gargi Keeni, Fabrizio Lombardi, Hironori Kasahara, Arnold N. PearsTerm Expiring 2015: Ann DeMarle, Cecilia Metra, Nita Patel, Diomidis Spinellis, Phillip Laplante, Jean-Luc Gaudiot, Stefano ZaneroTerm Expriring 2016: David A. Bader, Pierre Bourque, Dennis Frailey, Jill I. Gostin, Atsuhiro Goto, Rob Reilly, Christina M. Schober

EXECUTIVE STAFFExecutive 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 OFFICESWashington, D.C.: 2001 L St., Ste. 700, Washington, D.C. 20036-4928Phone: +1 202 371 0101 • Fax: +1 202 728 9614Email: [email protected] Alamitos: 10662 Los Vaqueros Circle, Los Alamitos, CA 90720Phone: +1 714 821 8380 • Email: [email protected]

MEMBERSHIP & PUBLICATION ORDERSPhone: +1 800 272 6657 • Fax: +1 714 821 4641 • Email: [email protected]/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: [email protected]

IEEE BOARD OF DIRECTORSPresident: 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

r11sch.indd 59 10/24/14 2:04 PM

Page 5: Software-Defined Networks: Incremental Deployment with ... · enable SDN control over existing proprietary hardware by mimicking the fine-grained control available in OpenFlow. 6

60 COMPUTER

COVER FE ATURE

References1. 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 Applied Mathematics (ICTEAM) at Université catholique de Louvain, Belgium. His research interests include soft-ware-defined networking and large-scale and distributed cloud computing. Canini received a PhD in computer sci-ence and engineering from the University of Genoa. He is a member of IEEE and ACM. Contact him at [email protected].

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 com-puter science from Carnegie Mellon University. In 2011, she was awarded the Gottfried-Wilhelm-Leibniz-Preis and the Berliner Wissenschaftspreis. Contact her at [email protected]

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 deploy-ment won first prize in the ACM graduate student research competition at SIGCOMM 2013. Formerly a software de-veloper at Andeen Hagerling, Levin is a member of ACM. Contact him at [email protected].

Fabian Schaffert received an MS in computer engineer-ing from TU Berlin in 2014. His research interests include hybrid deployment of software-defined networks. Contact him at [email protected].

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 re-ceived a PhD in computer science from ETH Zürich. Contact him at [email protected].

• 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

IEEE Open Access

IEEE offers a variety of open access (OA) publications:

Discover top-quality articles, chosen by the IEEE peer-review standard of excellence.

Unrestricted access to today’s groundbreaking research

via the IEEE Xplore® digital library

Learn more about IEEE Open Access

www.ieee.org/open-access

12-TA-0424-Open Access 3.25x4.75 Final .indd 1 9/24/12 10:06 AM

Selected CS articles and columns are available for free at http://ComputingNow.computer.org.

r11sch.indd 60 10/24/14 2:04 PM