Virtualization Stefan Schmid - 1
Virtualization and Benefits What is virtualization? An abstraction Used where and (dis)advantages? Java virtual machine, virtual memory, VPN, abstraction = simpler and less details? (but less efficient?) more flexible and efficient use of resources? isolation Stefan Schmid - 2
Virtualization of Networks Virtualization of resources: more efficient use of hardware memory, hiding fragmentation, no relative addressing, isolation of processes... powerful abstraction in systems engineering Computing examples: virtual memory, virtual devices e.g., /dev/null OS abstracting hardware (Intel vs AMD vs GPU, etc.) Virtual machines: e.g., Java IBM VM OS from 1960 s/70 s virtual machine executes platform independent bytecode, secure executions,... Layering of abstractions: don t sweat the details of the lower layer, only deal with lower layers abstractly Mainframes; hypervisor runs on hardware and creates the virtual environment Stefan Schmid - 3
The Internet: Virtualizing Local Networks The entire Internet is based on the idea of abstraction! Abstracting different networks... 1974: multiple unconnected networks ARPAnet (MIT & US Dept. Defense) data-over-cable networks packet satellite network (Aloha) packet radio network.. differing in: addressing conventions packet formats error recovery routing protocols How to unite?? Gateways... Introduces gateways, a TCP with flow-control, ports and multiplexing, etc. Stefan Schmid - 4
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 packetswitching 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. Stefan Schmid - 5
Cerf & Kahn: Interconnecting two networks Internetwork layer: addressing: internetwork appears as a single, uniform entity, despite underlying local network heterogeneity network of networks Gateway: talks both languages embed internetwork packets in local packet format or extract them route (at internetwork level) to next gateway fragmentation (but not reassembly), etc. gateway TCP enabled... ARPAnet satellite net Stefan Schmid - 6
Historical Aside: Proposed Internetwork packet in 1974: 2-level addressing local header source address dest. address seq. # byte count flag field text checksum network TCP identifier 8 16 translated into local address at final gateway encapsulation: header (and maybe tail) are proprietary 256 networks sufficient for forseeable future (used to find next gateway) Stefan Schmid - 7
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 Stefan Schmid - 8
Overlay Networks Abstracting networks even more, on higher layers: Nodes, links? Examples and purpose? Nodes: applications, running at various sites as nodes on an application-level network Links: 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 Examples of overlay networks? E.g., peer-to-peer networks such as BitTorrent, Gnutella, etc., or typically CDNs, Internet itself was overlay over telephone system... Use of overlay networks? E.g., robust routing Stefan Schmid - 9
Overlay Network Connect applications directly via virtual links! abstraction Stefan Schmid - 10
Overlay Network Focus at the application level Stefan Schmid - 11
What s new/what s old here? Old: we re doing routing, but at application layer (e.g., can be contentspecific) 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* - efficient publish/subscribe) content matters too; but maybe overhead 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 (unlike IP multicast, easy also across multiple providers) Stefan Schmid - 12
Use of Overlays: Internet Routing BGP defines routes between stub networks Internet 2 Berkeley.net UMass.net C&W Mediaone UCLA Noho.net E.g., Noho has BGP routes to UMass and Berkeley! Stefan Schmid - 13
Use of Overlays: Internet Routing BGP defines routes between stub networks Internet 2 Berkeley.net UMass.net C&W Mediaone UCLA Noho-to-UMass Noho.net Stefan Schmid - 14
Internet Routing BGP defines routes between stub networks Internet 2 Berkeley.net UMass.net C&W Mediaone UCLA Noho-to-Berkeley Noho.net Stefan Schmid - 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 Stefan Schmid - 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 Stefan Schmid - 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 Stefan Schmid - 18
RON: Resilient Overlay Networks Why RON, and why does it work? The Internet offers a high redundancy of paths! BGP must focus on scalability Much aggregation, damps route changes,...: makes things slow In BGP, only /19 block or larger updates accepted! How to make access to my company robust otherwise? E.g., multihoming (small company behind many ISPs), or even use multiple addresses?! Application can choose its metric! (latency vs bandwidth, etc.) Stefan Schmid - 19
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 2001 30-minute average loss rates A 30 minute outage is very serious! Note: Experiments done with No-Internet2-forcommercial-use policy (Internet2 routes are often more stable, but not always visible) Stefan Schmid - 20
An order-of-magnitude fewer failures Table: for how many samples of duration 30min was the loss rate larger than p%? RON win = loss in Internet was >p and RON lower no change = the same; RON worse = Internet better for this example. Loss Rate 10% 20% 30% 50% 80% 100% RON was below 50% in all the 32 samples when Internet was above. RON Better 479 127 32 20 14 10 No Change 57 6,825 path hours represented here 12 path hours of essentially complete outage 76 path hours of TCP outage 4 0 0 0 0 RON Worse 47 15 0 0 0 0 Stefan Schmid - 21
An order-of-magnitude fewer failures Difficult to define outage : TCP only 2-10 minutes; here larger scale... Loss Rate 10% 20% 30% 50% 80% 100% This implies that outage was never on edge! The higher the loss rate, the fewer samples for which Internet bad; RON loss never above 30%. 30-minute average loss rates RON Better 479 127 32 20 14 10 No Change 57 4 0 0 0 0 RON Worse 47 15 6,825 path hours represented here 12 path hours of essentially complete outage 76 path hours of TCP outage RON routed around all of these! (Implication?) One indirection hop provides almost all the benefit! 0 0 0 0 Stefan Schmid - 22
RON Research Issues How to design overlay networks? Measurement (active) and self-configuration Understanding performance of underlying net ( reality matters ) Fast fail-over Sophisticated metrics (latency vs bandwidth: what is needed?) application-sensitive (e.g., delay versus throughput) path selection Effect of RON on underlying network If everyone does RON, are we better off? Experiments were small-scale Stability?... Stefan Schmid - 23
IP-over-ATM IP-over-ATM virtualization: give the illusion of a different network (why? IP services...) ATM = Asynchronous Transfer Mode: Properties? Goal, e.g., real-time audio and video transmission Virtual circuit-switched Explicit set up of virtual channel (VC) needed Several layers Application layer: ATM Adaption Layer Different services... IP vs ATM? ATM connection oriented, has QoS concepts,... How to offer IP services over ATM? IP-over-ATM! Make it look like an IP network... (Alternative: peer-to-peer, like internet, less popular...) Idea overlay approach : view ATM as link layer protocol... Stefan Schmid - 24
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 Stefan Schmid - 25
IP-Over-ATM app transport IP Eth phy IP AAL Eth ATM phy phy ATM adaption layer: transport layer (only at end systems): e.g., error detection, segmentation,... ATM phy ATM phy app transport IP AAL ATM phy Stefan Schmid - 26
IP View of the world ATM is encapsulated... IP network ATM network Stefan Schmid - 27
Classical IP-over-ATM [RFC 1577] IP-over-ATM network can support usual IP subnetting... divide ATM net in IP prefix subnets: A B C D LIS 1 LIS 2 LIS 3 R1 R2 Why subnets? - Given address space, divide into different domains (e.g. users on site vs other department) s.t. communication goes via router, security,... - Efficiency: smaller broadcast domains E LIS: logical IP subnet End systems in same LIS have same IP network prefix 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) Stefan Schmid - 28
Classical IP-over-ATM [RFC 1577] A B C D E Inter-LIS communication: source, dest. in different LIS each LIS looks like a LAN LIS 1 LIS 2 LIS 3 hop-by hop forwarding via routers: R1 R2 A-R1-R2-B Traffic between different logical subnets goes via routers, although it s the same ATM network! This is quite an overhead (latency, bw bottleneck etc.), and there are sometimes short-cut approaches! How could they look like?? Stefan Schmid - 29
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 Stefan Schmid - 30
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) Why virtualization here? private over shared infrastructure yields efficient resource sharing: looks like private but cheaper, no own line has to be built! (shared backbone) How does the VPN architecture look like? SP infrastructure: backbone provider edge devices Customer: customer edge devices (communicating over shared backbone) Stefan Schmid - 31
VPN: logical view virtual private network Two customer historical types: provider edge - device leased lines edge device - customer-premises-based Stefan Schmid - 32
VPNs: benefits? Privacy & security CE-CE encryption vs PE-PE encryption? Or both? (E.g., IPsec) Support for 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), that do not exist in leased line VPN s 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 Stefan Schmid - 33
VPN reference architecture customer edge device provider edge device customer sites of VPN2 Stefan Schmid - 34
Leased-line VPN customer sites interconnected via static virtual channels (e.g., ATM VCs on layer 2), leased lines Expensive: connection-oriented, dedicated channels, etc. customer site connects to provider edge Stefan Schmid - 35
Customer premise VPN All VPN functions (e.g., over IP!) implemented by customer customer sites interconnected via tunnels tunnels typically encrypted SP treats VPN packets like all other packets! But configuration of expensive VPN gateways at customer Stefan Schmid - 36
Customer premise VPN IP-based: IP over IP Stefan Schmid - 37
Drawbacks? Leased-line VPN: configuration costs, maintainence by SP: long time, much manpower CPE-based VPN: expertise by customer to acquire, configure, manage VPN, IPSec tunnel for each CE pair of same VPN The new wave : Network-based VPN IP-based VPNs offered by SP (often together with other services such as firewalls, QoS,...) over its shared IP backbone Customer s routers connect to SP routers Less burden at customer: no need to implement VPN functions such as tunneling SP routers maintain separate (independent) IP contexts for each VPN sites can use private addressing (e.g., different VPNs with same IP addresses) traffic from one VPN can not be injected into another Stefan Schmid - 38
Network-based Layer 3 VPNs PE s are IP routers that maintain separate IP contexts (routing and forwarding tables) for every supported VPN, and ensure IP reachability between distant sites of same VPN How to realize? Concept of virtual routers (VR) IP-encapsulation and backbone tunnels between PE routers Stefan Schmid - 39
Network-based Layer 3 VPNs multiple virtual routers in single provider edge device tunnels (over IP network) only between PEs (and not CEs); backbone routers do not need to be aware of different contexts (inner IP headers) Stefan Schmid - 40
Network-based Layer 3 VPNs Realization: Virtual Router (VR) per VPN in each PE E.g., each VR has different IP address Backbone tunnels between PEs (backbone routers need not process inner IP headers of VPN, etc.!) Tunnels = concept that logic/support only needed at edges! Each PE pair sharing a VPN context need one tunnel Techniques: IP-in-IP, MPLS multiplexing (with good automation, traffic enigneering, etc.), GRE, etc. Stefan Schmid - 41
Tunneling Tunneling is a mechanism to concentrate logic on the edges of the core network! Stefan Schmid - 42
Tunneling Tunneling is a mechanism to concentrate logic on the edges of the core network! Stefan Schmid - 43
VPNs: Further Reading Stefan Schmid - 44
Excursion: Beyond VPNs CloudNet Architecture and Prototype at INET Stefan Schmid - 45