1. SPARC – Split Architecture Virtualization Pontus Sköldström

2. OpenAccess model – Share the cost of installing fibre – Service providers lease fibre and provide their own equipment – Network owner – network operator – service operator 2 Use-case – Multi-tenant access/aggregation.

3. “Network as a Service” model – Share the cost of the equipment as well – Service providers lease complete networks, virtualized – Complete network can be accessed via abstraction if less control is wanted – Reduced cost, reduced energy consumption, flexible management 3 Use-case – Multi-tenant access/aggregation.

4. Physical network 4 Network owner

5. Network owner creates a Virtual Network 5 Network owner

6. Customer controller connects to Virtual Network 6 Service provider

7. Add an abstraction system in between 7 Service providerNetwork owner

8. Multi-tenancy – Strict isolation of traffic, no traffic leaks unless previously agreed – Strict bandwidth isolation requirements, no tenant should be able to “steal” bandwidth Minimize administrative interdependence – Maximum flexibility in terms of allowed protocols, available switch functionality such as QoS functions – Flexibility in mapping incoming traffic to the virtual networks, allow overlapping address-spaces – Applications designed for physical network should work on virtual as well High-availability – The system should be robust to equipment failures 8 Requirements for a carrier-grade virtualization.

9. Translation unit / hypervisor – Translate and hide elements from the real to the virtual view – Hide CPUs, memory, emulate devices etc. – Real port number virtual port number Link isolation – How to share a link – Address space separation - FlowVisor – Tagging / encapsulation Node isolation – How to share a node – Address space separation - FlowVisor – Multiple tables – Physical or logical 9 Main parts of a virtualization system.

10. Centralized-> Decentralized -> More isolation -> Special HW 10 Design options.

11. 14.11.2012 SPARC – Final Review, Virtualization11 Implementation for OpenFlow 1.1.

12. 12 Performance Experiment. StatisticBaseVLANPWEVLAN-QPWE-Q 1st quartile103 µs108 µs111 µs110 µs115 µs Median105 µs110 µs114 µs117 µs118 µs 3rd quartile111 µs115 µs120 µs124 µs 95th percentile126 µs128 µs132 µs140 µs137 µs Measurable increase 5 to 13 µs per hop depending on scenario Conclusion Probably not even measurable in a real scenario

13. Implementation fulfils requirements – Strict isolation of traffic and bandwidth – Fully flexible address space, easy to map traffic to VNs – Not relying on a single point of failure – (Almost) no impact on performance All while maintaining OpenFlow compatibility – Fully compatible for Service providers – Requires minimal changes for the Network owner Can be made even more robust with Pseudowires and OAM – Extensions made in SPARC Implementation for OpenFlow 1.1. 13

14. Network owner has a running OpenFlow network 14 Network owner

15. Tunnel manager creates Ethernet Pseudowires 15 Network owner

16. OAM manager adds 30 ms active and backup paths 16 Network owner

17. Until all links are protected 17 Network owner

18. Virtualization manager steps in 18 Network owner

19. Various service operators connect 19 Network owner

20. Link failures are rerouted without affecting virtual topologies 20 Network owner