Flow Space Virtualization on Shared Physical OpenFlow Networks

1. Flow Space Virtualization on Shared Physical OpenFlow Networks Hiroaki Yamanaka, Shuji Ishii, Eiji Kawai (NICT), Masayoshi Shimamura, Katsuyoshi Iida (TITECH), and Masato Tsuru (Kyutech)

2. Background • Diverse requirements to networks for application services • Network resources for application-specific performance • Functions of in-network processing • Clean-slate network technology design • Network programmability • Testbed for spiral development • OpenFlow is one of key technologies for flexible routing

3. What OpenFlow is • Decoupling control and data planes • Flexible routing • Flow is defined using flow space, ingress port and L2-L4 packet headers (flow space). • Dynamic path setting for arbitrary fine-grained flows Data plane; Switches forward packets according to flow tables Control plane： A controller injects flow tables for each switch OpenFlow protocol A controller OpenFlow networks

4. OpenFlow Testbed • Testbed users’ OpenFlow-enabled networks for experiments • Connecting testbed user’s end-hosts to the network • Controlling the network by a testbed user’s controller • Resources of the experiments networks are provided by testbed infrastructure providers, e.g., JGN-X, GENI, and OFELLIA .

5. Virtual OpenFlow Networks • Requirements • Testbed infrastructure providers: Efficient use of physical resources • Testbed users: Use of customized experiment networks • Building experiment networks as virtual OpenFlow networks on physical OpenFlow networks • Sharing physical resources by multi-testbed users→efficiency • Software defined networks→customization

6. The Gap between Virtual and Physical OpenFlow Networks • Virtual OpenFlow networks: customizable for testbed users • Local flow space • Local addressing in virtual OpenFlow networks • Content centric networksusing IP address as a name of content • Local network topology • Easy-to-manage topology for a testbed user’s experiments • Physical OpenFlow networks: manageability for testbed infrastructure providers • Regulated flow space • Physical network addressing for easy-to-operate • E.g., in-network processing hosts’ IP addresses • Physical topology • Depending on physical configuration gap

7. Existent Virtualization Mechanism • Links and OpenFlow switches of subgraph • Just assigned flow space • FlowVisor • Issues for testbed users • Flow space: not allowed collisionamong distinct experiment networks • Experiment network topology: just subgraph of physical networks Exp. NW 2 Exp. NW 1 OpenFlow controller of testbed user 1 OpenFlow controller of testbed user 2 OpenFlow protocol Access control between slice controllers and physical switches OpenFlow protocol Physical OpenFlownetworks FlowVisor module The customizability for testbed users is limited.

8. Proposal • Supporting virtual OpenFlow network topology independent from physical OpenFlow networks • Name space mapping (data path id, link id) • Links aggregation, nodes integration • Allowing collision of flow space among virtual OpenFlow networks • Rewriting flow space for controllers and end-hosts of virtual OpenFlow networks

9. Reference Providers Model • 3 providers model • Testbed user: Service Provider (SP) • Testbed infrastructure provider: Infrastructure Provider (InP) • Mediator: Virtual Network Provider (VNP) • The VNP’s functions: • Resource brokering between SPs and InPs • Conflict of resources requests from SPs are adjusted by a VNP. • Mapping resources between physical networks and virtual networks • Providing interfaces for both SPs and InPs • Applicable to: • Cross-domain testbed federation • Network virtualization on the Internet with heterogenous SPs and InPs Our proposal : An implementation for customizable virtual OpenFlow networks

10. Data Plane Model Virtual Network of SP 2 SP (testbed user) Virtual OpenFlow network with local flow space and topology Virtual Network of SP 1 Virtual Network of SP 3 VNP Resource pool with abstracted topology of physical OpenFlow networks Topology and flow space mapping Middle Virtual Network (MVN) of VNP1 Resource abstraction for InP’s security InP Physical switches and links Physical OpenFlow network of InP1 Physical OpenFlow network of InP 2

11. Control Plane Model • Flow tables for logical OpenFlow switches in the logical OpenFlow network • Referencing the local flow space and the topology SP (testbed user)’s controller Control messages, packet-in, statistics for a virtual OpenFlow network VNP’s controller • Transforming the message from SP to fit the MVN • The mapping between the slice and the MVN is referenced. Control messages, packet-in, statistics for the MVN InP’ controller • Transforming the message from VNP to fit the physical OpenFlow network • Mapping between MVN and physical OpenFlow network is references. OpenFlow protocol Physical OpenFlow switches

12. Proposal: Independent Topology of Virtual OpenFlow Networks SP (testbed user) SP’s OpenFlow controller Virtual OpenFlow networks Interface to control virtual OpenFlow networks nodes and links VNP Managing the topology mapping* between MVN and virtual OpenFlow network VNP’s controller MVN Interface to control MVN nodes and links InP Managing the topology mapping* between physical OpenFlow network and MVN InP’s controller Physical OpenFlow networks • * All possible mappings (hiding, aggregation, slicing) are supported.

13. Proposal: Flow Space Virtualization for Testbed User Controllers SP (testbed user) 1’s OpenFlow controller SP (testbed user) 2’s OpenFlow controller • Rewriting: SP local flow space⇔SP allocated flow space • Port and packet header in packet-inmessages • Port and packet headerin injecting flow tables VNP Flow space allocation information Flow space allocation for SP 1 InP’s controller Flow space allocation for SP 2 InP divisions packet header space and allocates to each SP for management.

14. Proposal: Flow Space Virtualization for End-hosts SP1’s virtual OpenFlow network SP SP 2’s virtual OpenFlow network VNP Always sending packets with SP1-local headers An edge switch InP • Identifying the end-host’s belonging SP by the ingress port or the MAC address • Rewriting to be the allocated header on physical networks

15. An Initial Prototype An SP’s OpenFlow controller An SP (testbed user) can control his/her customized slice by only referencing the slice. OpenFlow protocol A module for SP (testbed user) A Virtual OpenFlow network OpenFlow message for the virtual OpenFlow network Mapping the topologies and packet-header MVN and SPs’ virtual OpenFlow networks DB A module of VNP An end-host only uses SP-local packet-headers. OpenFlow message for MVN MVN DB Mapping the topologies of InP and VNP A module of InP OpenFlow protocol An switch for end-hosts packet headers rewriting An InP can manage flow space easily though SPs’ customization. An end-host Physical OpenFlow network

16. Future Plan • Detailed design of flow space allocation management • Demonstration experiments on JGN-X

17. Summary • An OpenFlow testbed is important for clean-slate network architecture design. • Proposal of customized virtual OpenFlow networks on shared physical OpenFlow networks • Enabling virtual OpenFlow network-local topology and flow space • An initial prototype

18. Thank you! Q&A