Virtualization of networks

Transcription

1 Virtualization of networks Virtualization of resources: powerful abstraction in systems engineering Computing examples: Virtual memory, virtual devices Virtual machines: e.g., Java IBM VM OS from 1960 s/70 s Layering of abstractions: Don t sweat the details of the lower layer, only deal with lower layers abstractly 1

2 The Internet: Virtualizing local networks 1974: Multiple unconnected networks ARPAnet data-over-cable networks packet satellite network (Aloha) packet radio network... differing in: addressing conventions packet formats error recovery routing 2

3 Cerf & Kahn: Interconnecting two networks ARPAnet satellite net interconnection must preserve intact the internal operation of each network.... the interface between networks must play a central role in the development of any network interconnection strategy. We give a special name to this interface that performs these functions and call it a GATEWAY.... prefer that the interface be as simple and reliable as possible, and deal primarily with passing data between networks that use different packet-switching strategies address formats is a problem between networks because the local network addresses of TCP's may vary substantially in format and size. A uniform internetwork TCP address space, understood by each GATEWAY and TCP, is essential to routing and delivery of internetwork packets. 3

4 Cerf & Kahn: Interconnecting two networks Internetwork layer: Addressing: Internetwork appears as a single, uniform entity, despite underlying local network heterogeneity Network of networks Gateway: Embed internetwork packets in local packet format or extract them Route (at internetwork level) to next gateway gateway ARPAnet satellite net 4

5 Historical Aside: Proposed Internetwork packet in 1974: local header source address dest. address seq. # byte count flag field text checksum network TCP identifier

6 Cerf & Kahn s Internetwork Architecture What is virtualized? Two layers of addressing: Internetwork and local network New layer makes everything homogeneous Underlying local network technology (cable, satellite, 56K modem) is invisible at internetwork layer 6

7 Resilient Overlay Networks Overlay network: Applications, running at various sites as nodes on an application-level network Create logical links (e.g., TCP or UDP connections) pairwise between each other Each logical link: multiple physical links, routing defined by native Internet routing 7

8 Overlay network 8

9 Overlay network Focus at the application level 9

10 What s new/what s old here? Old: We re doing routing, but at application layer (e.g., can be content-specific) New names/addresses: Internet uses IP addresses (reflecting only network physical structure), overlay can use content-specific or application-specific names/addresses Virtualizing the Internet: another layer of abstraction Tradeoffs possible: can improve routing performance not just delay/throughput but application-specific measures (e.g., content that I *want* - publish/subscribe) content matters too 10

11 What s new/what s old here? (cont.) Security and anonymity: easier to add at application layer? Can be used to get around congestion/bad routing in the underlay (can route differently from underlay). Can do more complex routing but lose access to underlying measures like topology, delay, QoS: lose performance (???) but gain flexibility/functionality Overlay is a single entity that combines heterogeneous underlays to provide the homogeneous overlay New data transmission functions: broadcast and multicast can be done in overlay 11

12 Internet Routing BGP defines routes between stub networks Berkeley.net Internet 2 UMass.net C&W Mediaone UCLA Noho.net 12

13 Internet Routing BGP defines routes between stub networks Berkeley.net Internet 2 UMass.net C&W UCLA Noho-to-UMass Mediaone Noho.net 13

14 Internet Routing BGP defines routes between stub networks Berkeley.net Internet 2 UMass.net C&W UCLA Noho-to-Berkeley Mediaone Noho.net 14

15 Internet Routing Berkeley.net Congestion or failure: Noho to Berkely BGP-determined route may not change (or will change slowly) UCLA Internet 2 Noho-to-Berkeley UMass.net C&W Mediaone Noho.net 15

16 Internet Routing Berkeley.net Congestion or failure: Noho to Berkely BGP-determined route may not change (or will change slowly) Internet 2 Noho to UMass to Berkeley Route not visible or available via BGP! MediaOne can t route to Berkeley via Internet2 C&W Mediaone UMass.net UCLA Noho-to-Berkeley Noho.net 16

17 RON: Resilient Overlay Networks Premise: by building application overlay network, can increase performance, reliability of routing application-layer router Two-hop (application-level) noho-to-berkeley route 17

18 RON Experiments Measure loss, latency, and throughput with and without RON 13 hosts in the US and Europe 3 days of measurements from data collected in March minute average loss rates A 30 minute outage is very serious! Note: Experiments done with No-Internet2- for-commercial-use policy -18

19 An order-of-magnitude fewer failures Loss Rate 10% 20% 30% 50% 80% 100% 30-minute average loss rates RON No Better Change RON Worse ,825 path hours represented here" 5 path hours of essentially complete outage" 16 path hours of TCP-perceived (>=30%) outage"!ron routed around all of these!! One indirection hop provides almost all the benefit!"

20 RON Research Issues How to design overlay networks? Measurement and self-configuration Understanding performance of underlying network (when to use RON) Fast fail-over (fast switching to new RON paths) Application-sensitive (e.g., delay versus throughput) path selection Effect of RON on underlying network If everyone does RON, are we better off? 20

21 IP-Over-ATM Classic IP only 3 networks (e.g., LAN segments) MAC (802.3) and IP addresses IP over ATM Replace network (e.g., LAN segment) with ATM network ATM addresses, IP addresses ATM network Ethernet LANs Ethernet LANs 21

22 IP-Over-ATM app transport IP Eth phy Eth phy IP AAL ATM phy ATM phy ATM phy app transport IP AAL ATM phy 22

23 IP View of the world IP network ATM network 23

24 Classical IP-over ATM [RFC 1577] A B C D LIS 1 LIS 2 LIS 3 R1 R2 E LIS: logical IP subnet End systems in same LIS have same IP network addr LIS looks like a LAN ATM net divided into multiple LIS Intra-LIS communication via direct ATM connections How to go from IP addr to ATM addr: ATMARP resolves IP addr to ATM addr (similar to ARP) 24

25 Classical IP-over ATM [RFC 1577] Inter-LIS communication: A B C D E source, dest. in different LIS each LIS looks like a LAN hop-by hop forwarding: LIS 1 LIS 2 LIS 3 A-R1-R2-E R1 R2 25

26 NHRP (next hop resolution protocol) [RFC 2332] A NHRP server, S 1 B C D LIS 1 LIS 2 LIS 3 NHRP server, S 2 E NHRP server, S 3 Source/dest. not in same LIS: ATMARP can not provide ATM dest. address NHRP: Resolve IP-to-ATM address of remote dest. Client queries local NHRP server NHRP server routes NHRP request to next NHRP server Destination NHRP returns dest ATM address back through NHRP server chain (like routed DNS) Source can send directly to dest. using provided ATM address 26

27 Virtual Private Networks (VPN) VPNs Networks perceived as being private networks by customers using them, but built over shared infrastructure owned by service provider (SP) SP infrastructure: backbone provider edge devices Customer: customer edge devices (communicating over shared backbone) 27

28 VPN reference architecture customer edge device provider edge device 28

29 VPN: logical view virtual private network customer edge device provider edge device Part

30 Leased-line VPN PEs interconnected via static virtual channels (e.g., ATM VCs), leased lines customer site connects to provider edge 30

31 Customer premise VPN q All VPN functions implemented by customer Customer sites interconnected via tunnels q Tunnels encrypted typically q SP treats VPN packets like all other packets 31

32 Drawbacks Leased-line VPN: configuration costs, maintenance by SP: long time, much manpower CE-based VPN: expertise by customer to acquire, configure, manage VPN Network-based VPN Customer s routers connect to SP routers SP routers maintain separate (independent) IP contexts for each VPN Sites can use private addressing Traffic from one VPN can not be injected into another 32

33 Network-based Layer 3 VPNs multiple virtual routers in single provider edge device 33

34 Tunneling 34

35 VPNs: why? Security/privacy Works well with mobility: Looks like you are always at home Cost: Many forms of newer VPNs are cheaper than leased line VPN s Ability to share at lower layers Exploit multiple paths, redundancy, fault-recovery (lower layers) Need isolation mechanisms to ensure appropriate resources sharing Abstraction and manageability: All machines with addresses that are in are trusted no matter where they are 35

36 Network Virtualization: Vision Success of Node Virtualization a.k.a. end-host virtualization VMWare revamped server business VM = basic unit in datacenters hardly any physical resources! VM = flexible allocation, migration... Trend of Link Virtualization VLANs, VPNs, MPLS, OpenFlow,... Unified, fully virtualized networks (a.k.a. CloudNets) Combine networking with heterougeneous cloud resources (e.g., storage, CPU,...)! 36

37 Objectives (1) Based on layer 2: virtual network as a LAN (can experiment with new network protocols!) Today s Internet protocol stack: One size fits it all! (Narrow waist...) Not always optimal: service-tailored networks, e.g., for social networking, bulk data transfers,...? Ossification: I cannot innovate the network core! (example: introduction of IPv6, or add functionality in routers for intrusion detection systems...) Virtualization: Can migrate seamlessly (IP addresses stay!), can allocate physical resources where needed or cheap, automatic recovery and robustness,... 37

38 Objectives (2) Flexible spec, Goal focused migration Result Multi-provider driven Solution Resource oriented sharing QoS Precise guarantees On-demand, Blunt short duration Heterogeneous Challenging resources Assertive Service-tailored Innovation in Confident network core 38

39 Virtualization = Flexible Embedding CloudNet CPU, location, OS,... benefit, duration, compatibility,... Some specifications may be missing and can be optimized! bw, latency, duplex,... CPU, location, OS,... Physical Infrastructure bw, latency, duplex,... 39

40 Embedding: Example CloudNet 1: Computation Specification: 1. > 1 GFLOPS per node 2. Monday 3pm-5pm 3. multi provider ok CloudNet 2: Mobile service w/ QoS Specification: 1. close to mobile clients 2. >100 kbit/s bandwidth for synchronization CloudNet requests Provider 1 Provider 2 Physical infrastructure (e.g., accessed by mobile clients) 40

41 Use Cases VPN++ Datacenters Goal: Fully specified CloudNet mapping constraints (e.g., end-points for a telco), but with QoS guarantees (e.g., bandwidth) along links Palo Alto 1Mbit/s 1Mbit/s Berlin 1Mbit/s Tel Aviv November 22, 1pm-2pm! < 10ms > 100 MB/ s any any < 10ms > 100 MB/s < 10ms > 100 MB/s any Guaranteed resources, job deadlines met, no overhead! Cloud Bursting / Cloud Spillover/ Out-Sourcing Migration Berlin < 50ms 50 TB storage, 10 TFlops computation! Goal: Move with the sun, with the commuters, (QoS) allow for maintenance, avoiding roaming cost : e.g., SAP server, game server, small CDN server Berlin < 50ms (corporate access network) any European cloud provideer (e.g., due to legal issues?) 41

42 Prototype at TU Berlin! Contact us for more details! Joint project with Deutsche Telekom and NTT DoCoMo Project website: Based on VLAN technology (alternative would be OpenFlow) Embedding using linear programming (using CPLEX solvers) YouTube: 42