Programmable Networks and GENI

1. Programmable Networks and GENI Marshall Brinn, GPO GEC15 0830-1000 October 25, 2012

2. Outline • Introduction • Presentations • DenizGurkan (Houston) • KiranNagaraja (Winlab Rutgers) • Prasad Calyam (OSU) • AshishVullmiri (Illinois) • Panel Discussion

3. Introduction The goal of the session is to review, from the perspective of an experimenter, how one CAN and how one SHOULD control network operations on the GENI-provided data plane.

4. Data Plane Schematic: Custom Virtual Topology Embedded in Resource Topology GENI has a (growing) set of compute and network resources. These are managed by aggregates who can provide slivers (real or virtual resources or resource bundles) in response to AM API requests which can be stitched together into segregated custom topologies.

5. GENI-provided data plane The data plane that GENI provides to experimenters is custom, segregated, Layer 2 linked and deeply programmable • Custom: • Generated based on experimenter’s request RSpec (Resource Specification) • Mixtures of virtual and ‘bare-metal’ compute nodes • Embedded in available topology of aggregates and network connections. • “Stitched” across aggregates as requested and possible • ‘Custom’ may include dimensions of geography, physical connectivity, network type (wired/wireless)

6. GENI-provided data plane [2] The data plane that GENI provides to experimenters is custom, segregated, Layer 2 linked and deeply programmable • Segregated: • Traffic between topologies (slices) are kept separate • Your slice’s traffic can’t enter my slice and vice versa, except by special mutual arrangement. • We expect to use VLAN tags as the segregation mechanism • May require some VLAN translation, management of limited VLAN tag resources at different aggregates • May impose limitations on experimenter (VLAN tag in header) • GENI does not make performance isolation assurances in general • But there are some resources that do provide such assurances

7. GENI-provided data plane [3] The data plane that GENI provides to experimenters is custom, segregated, and Layer 2 linked and deeply programmable. • Layer 2 Linked: • Provides Layer 2 ‘data plane’ network between compute nodes, as specified in request RSpec • Not necessarily one broadcast domain. • Also provides Layer 3 ‘control plane’ access to compute nodes either by public IP address or aggregate-provided SSH proxy.

8. GENI-provided data plane [4] The data plane that GENI provides to experimenters is custom, segregated, and Layer 2 linked and deeply programmable. • Deeply Programmable: • Allows for programming all details of network operations on the data plane • Ranging from routing decisions to frame edits to completely new L3 protocols. This aspect is the focus of this session.

9. Loci of Deep Programmability There are many potential sites of network programming in a GENI data plane topology • Physical Switch • All GENI racks (at campus, regional, backbone) are expected to contain an OF switch. • Uneven OpenFlow support across vendors. • Some provide ‘hybrid’ (OF or non-OF per-port) mode. • Software Switch • OVS is provided standard in most recent Linux distributions • Within OVS, experimenters can: • Can write own modules, protocols • OF switch support is provided with OVS, so it can provide controller for networking at each node • New ‘GENI-in-a-Box’ capability uses OVS to construct its topologies • XORP and Click are other popular S/W switches

10. Domains of Network Programmability • Any of these network control approaches (and others) can be effected at different locations: e.g. OF controllers, in custom network drivers, in OVS modules • Rule-based frame handling • Setting Flowspace rules (in FlowVisor) • Setting routing rules in kernel tables • Setting flow_mod rules in OF switch • In-the-loop frame handling • OF Controller can do this, providing fine-grained (though inefficient) per-frame control • Encapsulation, Tunneling approaches • Implementation of non-IP L3 protocols

11. Data Plane: Experimenter View • To the experimenter, their topology should SEEM like a LAN (albeit, in fact, ‘wide area’) • Or a series of LAN’s • Each node may have multiple interfaces: complex topologies dictate which nodes communicate over which interfaces • Can’t see intermediate hops that aren’t visible to GENI (tunneled, e.g.) • There may be hops that aren’t GENI nodes • There are likely to be some restrictions on L2 headers (specifically changing VLAN tags) • May be limits on L2 broadcast (vice P2P).

12. Questions for speakers and discussion • What have experimenters been able to do in terms of network programming on GENI data planes? • What has been easy, what has been difficult? • What future capabilities would experimenters like to see delivered to support them in their network programming efforts? • Perhaps graphical tools? Topology or path services? • GENI provides a lot of capabilities beyond data plane provisioning (e.gAuthN, AuthZ, Logging, Monitoring). • Is there anything from the federation or GMOC level that would help with deep network programmability?

13. Speakers / Panel • DenizGurkan (Houston) • KiranNagaraja (Winlab Rutgers) • Prasad Calyam (OSU) • AshishVullmiri (Illinois)

14. Panel Discussion