SPARC – Split Architecture

Virtualization

Pontus Sköldström

• 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.

• “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.

Physical network

4

Network owner

Network owner creates a Virtual Network

5

Network owner

Customer controller connects to Virtual Network

6

Service provider

Add an abstraction system in between

7

Service providerNetwork owner

• 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.

• 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.

Centralized -> Decentralized -> More isolation -> Special HW

10

Design options.

14.11.2012 SPARC – Final Review, Virtualization 11

Implementation for OpenFlow 1.1.

12

Performance Experiment.

Statistic Base VLAN PWE VLAN-Q PWE-Q

1st quartile 103 µs 108 µs 111 µs 110 µs 115 µs

Median 105 µs 110 µs 114 µs 117 µs 118 µs

3rd quartile 111 µs 115 µs 120 µs 124 µs 124 µs

95th percentile 126 µs 128 µs 132 µs 140 µs 137 µs

• Measurable increase• 5 to 13 µs per hop depending on

scenario

• Conclusion• Probably not even measurable in

a real scenario

• 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

Network owner has a running OpenFlow network

14

Network owner

Tunnel manager creates Ethernet Pseudowires

15

Network owner

OAM manager adds 30 ms active and backup paths

16

Network owner

Until all links are protected

17

Network owner

Virtualization manager steps in

18

Network owner

Various service operators connect

19

Network owner

Link failures are rerouted without affecting virtual topologies

20

Network owner