1

IU Campus GENI/Openflow Experience

Matt Davy

Quilt Meeting, July 22nd 2010

2

Outline

Quick Overview of IU Campus Network

Overview of Current Openflow Deployment

Deployment Methodology

Issue Encountered

Next Steps (0-12 months)

Regional Deployments

3

IU Campus Network

8 Campuses Connected with Dark Fiber

1,500+ switches with 100,000+ switch ports

4,000+ Wireless Access Points

2 large data centers - 1,200+ VMs

Leverage/Edge/Trust - Nearly all infrastructure centrally managed

Federated network control important aspect of Openflow

4

5

Deployment Methodology

Initially Deploy Separate Switches for Openflow

Production VLAN + Openflow Production VLAN w/o Openflow Enabled

Enable Openflow and Move Users onto Openflow VLAN

Add Openflow Research VLAN

Wireless SSID Plumbed into Openflow Production VLAN

Users can opt-in and opt-out quickly and easily

Can deploy on 4,000+ APs quickly and with little to no risk

6

Issues Encountered

Early bugs in HP switch implementation

Things like slow flow setup times

Most fixed in recent code

Limitations in HP Implementation

Software switched flows - Multiple output ports, L2 only flow rules

Openflow image not built against maintenance branch

Little security on Openflow controller channel

Added ACLs upstream

7

Issues Encountered

No IPv6 Support in Openflow

Needed by network engineers - our initial test users

Static Ether-type (0x86DD) entry in SNAC

All IPv6 is flooded and software switched

DHCP Slowness

Occasionally 1-2 mins to get DHCP lease

Originally Openflow Problem - Resolved with Code Upgrade

Now have similar problem caused by wireless controllers

8

Next Steps (0-12 months)

Add Openflow Specific Monitoring to GlobalNOC Tools

Deploy Openflow SSID and Actively Recruit Users

Deploy Openflow on real production switches

Develop larger, multi-vendor Openflow lab

Develop GENI Openflow Hands-On Workshop

Research using Openflow in the WAN

9

Next Steps (0-12 months)

Fully Operationalize Openflow

Enable Researchers to Provision Slices on Our Infrastructure

Investigate Integration of Existing Tools with Openflow

Automatic Network Isolation (ANI)

Home-Grown NAC

Sherpa - Provision network “paths” with dedicated bandwidth

10

11

12

Regional Deployments

Openflow Islands Need Layer-2 Connectivity

Regional Could Just Provide Layer-2 Path from Campus to I2/NLR

Potential VLAN ID Conflicts

Why Deploy Openflow in a Regional ?

Creates More Interesting/Realistic Topologies for Researchers

Standardizes Openflow Connectivity for Members

Gain Experience with GENI/Openflow

13

Regional Deployments

What is Needed for a Regional Deployment ?

At Least 1 Openflow Capable Switch

At Least 1 Server - Preferably with Xen/VMware

For Running Flowvisor, NOX, etc

Layer-1 or Layer-2 Connectivity

Campus to Regional Openflow Switch(es)

Internet2/NLR to Regional Openflow Switch(es)

14

15

16

17

Dedicated vs Best-Effort

Experiments Must Be Repeatable !

Best-Effort May Be Sufficient as Initial Deployment (Overlay)

Plan to Transition to Dedicate Layer-1 Links Where Feasible

Plan for Dedicated Bandwidth on Shared Layer-2 Links in the Future

18

Questions ?