Network virtualization

Transcription

1 Network virtualization Protocols for Data Networks (aka Advanced Computer Networks)

2 Lecture plan [FlowVisor] The first SDN-based network virtualization tool [NVP] VMware s network virtualization platform [OVS] Open vswitch, the software switch used in current clouds [OVX] An open-source network virtualization platform

4 Context and motivation Validating network research is problematic Simulations and emulations lack realism Building a testbed is hard and expensive, and it is hard to scale VINI and Emulab are two network testbeds that improve the status quo, but... Packet processing and forwarding is done in software by a conventional CPU, which is much slower than ASICs Hard to scale as they exist as a parallel testbed to the production network Transferring an experiment running on a network of CPUs to specialized hardware takes considerable effort In a few words: the main problem of a testbed is that it is... a testbed!

5 Proposal: FlowVisor A testbed that is embedded in the production network It automatically scales with the global network! This is achieved by slicing the network hardware Why not VLANs?

6 Motivation for VLANs Problem 1: what if a CS user moves office to Chemistry, but wants connect to the CS switch? Need to move all cabling Problem 2: one LAN = a single broadcast domain all layer-2 broadcast traffic (ARP, DHCP, unknown location of destination MAC address) must cross entire LAN; no isolation security/privacy issues, efficiency issues (hard to scale) One possibility to solve this problem would be to replace center switch with router Problem 3: inefficient use of switches If you have many groups with a small number of users each, then you will have many ports unused Computer Science Chemistry Physics Fonte: [Kurose2009] 6

7 VLANs Port-based VLAN: switch ports grouped (by switch management software) so that single physical switch 1 2 Chemistry (VLAN ports 1-8) CS (VLAN ports 9-15) operates as multiple virtual switches Chemistry (VLAN ports 1-8) CS (VLAN ports 9-16) Fonte: [Kurose2009] 7

8 Proposal: FlowVisor A testbed that is embedded in the production network It automatically scales with the global network! This is achieved by slicing the network hardware Why not VLANs? They separate classes of traffic but do not provide any means to control the forwarding plane

9 FlowVisor FlowVisor sits between the control and data planes Each experiment runs in their own slice of the network For switches it acts as a "normal" SDN controller, and for the users' SDN controllers it acts as if it were a network of OpenFlow switches

10 Slicing network resources Bandwidth Each slice has its own fraction of bandwidth on each link Per-slice queues are created, each using a fraction of the link bandwidth Forward table entries Each slice has a finite quota of forwarding rules FlowVisor uses a counter to guarantee slice does not exceed its threshold Device CPU Each slice is limited to a fraction of each device s CPU FlowVisor rate limits new flow messages (dropping packets when a threshold is exceeded) controller requests slow path forwarding (rewriting slow path rules into one-time packet forwarding event) leaving some CPU for bookkeeping If the CPU becomes overloaded, will packet forwarding continue? Yes, only the control plane (OpenFlow requests) is affected

11 Slicing network resources Flowspace Subset of traffic controlled by an experiment subset is defined by a collection of packet headers that form a well-defined subspace of possible packet headers Control All OpenFlow messages are sent through FlowVisor FlowVisor intercepts, polices, and rewrites control messages as needed Ensuring transparency and isolation Topology Each slice has its own view of the network nodes and the connectivity between them Enabled by FlowVisor intercepting all control messages

12 Evaluation: scalability and performance FlowVisor scales linearly Overheads To the data plane? None To the control plane? None To actions crossing the control and data planes? 16 ms for new flow messages (from 12ms to 28ms)

13 Evaluation: isolation Without slicing A DDoS experiment in one slice may consume all bandwidth A malicious controller can overload the switch CPU These problems do not occur with slicing

15 Context and motivation Server virtualization has become the dominant approach for managing computational infrastructures What is lacking to achieve full virtualization? Virtualizing the network What network aspects are important to virtualize? Network topology Different workloads require different topologies How has this problem been solve traditionally? Simple, build multiple physical networks Address space Virtualized workloads operate in the same address space as the physical network Problems? Cannot move VMs to arbitrary locations Cannot change addressing type (if physical is IPv4, VMs are IPv4) 15

16 Alternatives Wait, but we ve had network virtualization for ages! VLANs NAT Virtualize L2 (Ethernet) networks Virtualize IP address space MPLS Virtualize physical paths 16

17 Multiprotocol label switching (MPLS) Initial goal: high-speed IP forwarding using fixed length label (instead of IP address) fast lookup using fixed length identifier (rather than longest prefix matching) borrowing ideas from Virtual Circuit (VC) approach but IP datagram still keeps IP address! PPP or Ethernet header MPLS header IP header remainder of link-layer frame label Exp S TTL Fonte: [Kurose2009] 17

18 MPLS capable routers a.k.a. label-switched router forward packets to outgoing interface based only on label value (don t inspect IP address) MPLS forwarding table distinct from IP forwarding tables flexibility: MPLS forwarding decisions can differ from those of IP e.g, use destination and source addresses to route flows to same destination differently (traffic engineering) re-route flows quickly if link fails: pre-computed backup paths Fonte: [Kurose2009] 18

19 MPLS versus IP paths IP routing: path to destination determined by destination address alone R6 R5 R4 R3 D A R2 IP router Fonte: [Kurose2009] 19

20 MPLS versus IP paths MPLS routing: path to destination can be based on source and destination address R6 R5 R4 entry router (R4) can use different MPLS routes to A based, e.g., on source address R2 R3 D A IP-only router MPLS and IP router Fonte: [Kurose2009] 20

21 Alternatives Wait, but we ve had network virtualization for ages! VLANs NAT Virtualize L2 (Ethernet) networks Virtualize IP address space MPLS Virtualize physical paths What is the problem with these solutions? VLANs don t scale Point solutions, requiring box-by-box configuration No global, unifying abstractions 21

22 Contribution NVP, a Network Virtualization Platform A complete network virtualization solution Allows the creation of virtual networks, each with independent Service models Topologies Addressing architectures over the same physical network 22

23 Network hypervisor abstractions Control abstraction Tenants define logical datapaths that are configured with their control planes Logical datapath = set of logical network elements How are logical datapaths defined? A packet forwarding pipeline (similar to forwarding ASICs) that contains a sequence of lookup tables The pipeline results in a forwarding decision How are logical datapaths implemented? In the software virtual switches Forwarding decisions are done solely on the end hosts! Advantages over ASIC implementations? More flexibility Can match over arbitrary packet header fields 23

24 Network hypervisor abstractions Packet abstraction Packets sent by endpoints are given the same treatment (switching, routing, filtering) as in the tenant s home network 24

25 Network hypervisor architecture What happens when the logical datapaths reaches a forwarding decision? The packet is tunneled over the physical network to the receiving host hypervisor Using several encapsulation mechanisms, such as GRE or STT Allowing the encapsulation of Ethernet frames inside IP packets, for example Host hypervisor decapsulates the packet and sends it to destination VM The physical network sees nothing but ordinary IP traffic 25

26 Generic Routing Encapsulation Tunneling Encapsulation with delivery header The addresses in the delivery header are the addresses of the head-end and the tail-end of the tunnel Delivery header / GRE / Private network site / tunnel /16 Public Network /16 Private network site

27 Discussion What network entity configures the software switches? An SDN controller Tunnels work for point-to-point communication. How about multicast and broadcast? A simple multicast overlay is used, adding physical forwarding elements for that purpose (service nodes) Service nodes replicate the packets received How are logical networks interconnected with physical networks? A gateway is used for this purpose 27

28 Design challenges How to accelerate software switching? How to compute all that forwarding state and disseminate it to the switches, avoiding inconsistencies? How to scale the controller cluster? 28

29 Logical datapath implementation NVP uses Open vswitch (OVS) to forward packets The NVP controller cluster configures the OVS remotely using two protocols OpenFlow to inspect and modify the flow tables OVSDB to create and manage overlay tunnels and to discover which VMs are hosted at a hypervisor How is the logical pipeline created? NVP augments the logical flow table in OVS to include a match over the packet s metadata for the logical table identifier NVP modifies each action of a flow entry to write the ID of the next logical flow table and to resubmit the packet back to the OVS flow table This creates the logical pipeline 29

30 Forwarding performance Traditional physical switches classify packets using TCAMs How can we classify packets quickly with software switches, such as OVS? What techniques are explored in NVP? Flow caching Exploits traffic locality All packets belonging to same flow (say, one VM TCP connection) traverse exactly the same set of flow entries The first packet of the flow is sent from the kernel module to userspace But userspace program installs exact-match flows into the flow table in the kernel, so future packets don t leave the kernel Use of hardware offloading techniques TCP segment offloading (TSO) allows the OS to send TCP packets larger than the physical MTU, and then the NIC takes care of the rest Large Received Offload (LRO) does the opposite (again, work offloaded to the NIC) Problem: current Ethernet NICs do not support offloading in the presence of IP encapsulation Solution: use TSS as encapsulation method Add fake TCP header, and then the NIC is capable of performing the standard offloading mechanisms 30

31 Forwarding state computation Forwarding state is computed based on vnics location info and system configuration, and is pushed to transport nodes via OpenFlow Computational model is entirely proactive Is this different from the traditional SDN model? Different, here controllers push all forwarding state down and do not process any packets Is it good or bad? Simplifies scaling of the controller cluster Failure isolation less problems if connectivity to the controller cluster is lost Full computation after every change is computationally inefficient, so incremental computation necessary Problem: very hard to code and to test Solution: they implemented nlog, a domain-specific, declarative language that allows the separation of logic specification from its implementation 31

32 Controller cluster What techniques are used to scale computation? Controllers are arranged in a two-layer hierarchy Separation of concerns eases computation and allows more parallelization What techniques are used to guarantee high availability? There are hot-standbys at both layers 32

33 Evaluation: cold start Simulates bringing the entire system back online after major datacenter disaster Takes around one hour Comments? 33

34 Evaluation: tunnel performance Why is GRE throughput so low? It is incapable of using hardware offloading STT, on the other hand, is capable of having a throughput equivalent to having no encapsulation 34

35 Discussion What were, in your opinion, the seeds of NVP s success? Make logical networks look exactly like current network configurations despite current networks many flaws, they represent a large installed base, and can be used without modification The purpose-built programming language (nlog) easing development while assuring correctness Leveraging the flexibility of software switching Software enabling much faster innovation SDN control centralization Important to have a centralized global view 35

37 Open vswitch With the proliferation of virtualization, a new network layer is emerging Within the hypervisor The authors present the design and implementation of Open vswitch (OVS), a capable virtual switch for virtualized environments A software switch that resides within the hypervisor or management domain Exports interface for fine grained control of the forwarding (via OpenFlow) and of configuration (via OVSDB: to configure queues, create/destroy switches, add/remove ports, etc.) Open-source Multi-platform 37

38 Where is Open vswitch Used? Broad support: Linux, FreeBSD, NetBSD, Windows, ESX KVM, Xen, Docker, VirtualBox, Hyper-V, OpenStack, CloudStack, OpenNebula, Widely used: Most popular OpenStack networking backend Default network stack in XenServer 1,440 hits in Google Scholar Thousands of subscribers to OVS mailing lists source: h*p://openvswitch.org/support/slides/nsdi2015-slides.pdf 38

40 OpenVirteX An open-source network virtualization platform that can provide address virtualization to keep tenant traffic separate topology virtualization to enable tenants to specify their topology, and deliver each virtual network to the tenants' controller as infrastructure on demand.

41 Lecture 2/5: network programming languages Mandatory (one of these two) N. Foster et al., Frenetic: A Network Programming Language, ICFP, 2011 The first network programming language for SDNs. C. J. Anderson et al., NetKAT: Semantic Foundations for Networks, POPL, 2014 An (even more) recent network programming language with stronger semantic foundations. [Optional] N. Foster et al., Languages for Software-Defined Networks, IEEE Communications Magazine, 2014 A very short survey of SDN programming languages C. Monsanto et al., Composing Software Defined Networks, NSDI, 2013 The follow-up work to Frenetic, proposing an imperative approach. [Student ppts] Mark Reitblatt et al. Abstractions for network update, SIGCOMM 2012 This paper introduced important abstractions for network updates. A. Gupta et al., SDX: A Software Defined Internet Exchange. SIGCOMM, 2014 An SDN-based Internet exchange that includes programming abstractions to ease participants (Autonomous Systems) configurations.