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. 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 What OpenFlow is A controller OpenFlow networks Data plane; Switches forward packets according to flow tables Control plane ： A controller injects flow tables for each switch OpenFlow protocol

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 networks using 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 Issues for testbed users – Flow space: not allowed collision among distinct experiment networks – Experiment network topology: just subgraph of physical networks FlowVisor module Physical OpenFlow networks OpenFlow protocol OpenFlow controller of testbed user 1 Exp. NW 1 Exp. NW 2 OpenFlow controller of testbed user 2 Links and OpenFlow switches of subgraph Just assigned flow space Access control between slice controllers and physical switches OpenFlow protocol FlowVisor 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 Physical OpenFlow network of InP1 Middle Virtual Network (MVN) of VNP1 Virtual Network of SP 3 Virtual Network of SP 2 Virtual Network of SP 1 VNP Physical OpenFlow network of InP 2 InP SP (testbed user) Physical switches and links Resource pool with abstracted topology of physical OpenFlow networks Virtual OpenFlow network with local flow space and topology Topology and flow space mapping Resource abstraction for InP’s security

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

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

13. Proposal: Flow Space Virtualization for Testbed User Controllers Ingress Port Ether src Ether dst …IPv4 srcIPv4 dst TCP/UDP /SCTP src port TCP/UDP /SCTP dst port InP’s controller VNP SP (testbed user) 1’s OpenFlow controller Flow space allocation for SP 1 Flow space allocation for SP 2 InP divisions packet header space and allocates to each SP for management. Ingress Port Ether src Ether dst …IPv4 srcIPv4 dst TCP/UDP /SCTP src port TCP/UDP /SCTP dst port Flow space allocation information Ingre ss Port Ether src Ether dst … IPv4 src IPv4 dst TCP/ UDP/ SCTP src port TCP/ UDP/ SCTP dst port Ingre ss Port Ether src Ether dst … IPv4 src IPv4 dst TCP/ UDP/ SCTP src port TCP/ UDP/ SCTP dst port Rewriting: SP local flow space ⇔ SP allocated flow space Port and packet header in packet-in messages Port and packet header in injecting flow tables SP (testbed user) 2’s OpenFlow controller

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

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

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