1. 1 IU Campus GENI/Openflow Experience Matt Davy Quilt Meeting, July 22nd 2010

2. 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. 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. 4

5. 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. 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. 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. 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. 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. 10

11. 11

12. 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. 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. 14

15. 15

16. 16

17. 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. 18 Questions ?