Virtualization of Networks
Total Page:16
File Type:pdf, Size:1020Kb
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 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 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 Cerf & Kahn: Interconnecting two networks Internetwork layer: Gateway: ❒ Addressing: Internetwork ❒ “Embed internetwork packets appears as a single, uniform in local packet format or entity, despite underlying local extract them” network heterogeneity ❒ Route (at internetwork level) ❒ Network of networks to next gateway gateway ARPAnet satellite net 4 Historical Aside: Proposed Internetwork packet in 1974: local source dest. flag seq. # byte text checksum header address address count field TCP network identifier 8 16 5 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 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 Overlay network 8 Overlay network Focus at the application level 9 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 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 Internet Routing ❒ BGP defines routes between stub networks Internet 2 Berkeley.net UMass.net C&W Mediaone UCLA Noho.net 12 Internet Routing ❒ BGP defines routes between stub networks Internet 2 Berkeley.net UMass.net C&W Mediaone Noho-to-UMass UCLA Noho.net 13 Internet Routing ❒ BGP defines routes between stub networks Internet 2 Berkeley.net UMass.net C&W Mediaone Noho-to-Berkeley UCLA Noho.net 14 Internet Routing Internet 2 Berkeley.net UMass.net Congestion or failure: Noho to Berkely C&W BGP-determined route may not change (or will change slowly) Mediaone Noho-to-Berkeley UCLA Noho.net 15 Internet Routing Noho to UMass to Berkeley ❒ Route not visible or available via BGP! ❒ MediaOne can’t route to Internet 2 Berkeley via Internet2 Berkeley.net UMass.net Congestion or failure: Noho to Berkely C&W BGP-determined route may not change (or will change slowly) Mediaone Noho-to-Berkeley UCLA Noho.net 16 RON: Resilient Overlay Networks Premise: by building application overlay network, can increase performance, reliability of routing application-layer Two-hop (application-level) router noho-to-Berkeley route 17 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- for-commercial-use” policy -18 An order-of-magnitude fewer failures 30-minute average loss rates RON No RON Loss Rate Better Change Worse 10% 479 57 47 20% 127 4 15 30% 32 0 0 50% 20 0 0 80% 14 0 0 100% 10 0 0 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!! One indirection hop provides almost all the benefit!" 19 RON Research Issues •! How to design overlay networks? •! Measurement and self-configuration •! Understanding performance of underlying net. •! Fast fail-over. •! Sophisticated metrics. •! application-sensitive (e.g., delay versus throughput) path selection. •! Effect of RON on underlying network •! If everyone does RON, are we better off? 20 IP-Over-ATM IP over ATM Classic IP only ❒! Replace “network” (e.g., ❒! 3 “networks” (e.g., LAN segment) with ATM LAN segments) network ❒! MAC (802.3) and IP ❒! ATM addresses, IP addresses addresses ATM network Ethernet Ethernet LANs LANs 21 IP-Over-ATM app app transport transport IP IP IP AAL AAL Eth Eth ATM ATM phy phy phy ATM phy phy ATM phy 22 IP View of the world IP network ATM network 23 Classical IP-over ATM [RFC 1577] LIS: logical IP subnet C D B ❒! End systems in same LIS A E have same IP network addr ❒! LIS looks like a LAN LIS1 LIS2 LIS3 ❒! ATM net divided into multiple LIS R1 R2 ❒! 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 Classical IP-over ATM [RFC 1577] Inter-LIS communication: C D B ❒ A E ! source, dest. in different LIS ❒! each LIS looks like a LAN ❒! hop-by hop forwarding: LIS1 LIS2 LIS3 ❍! A-R1-R2-B R1 R2 25 NHRP (next hop ❒! Source/dest. not in same LIS: resolution protocol) ATMARP can not provide ATM [RFC 2332] dest. address ❒! NHRP: Resolve IP-to-ATM B C D address of remote dest. A E ❍! Client queries local NHRP server ❍! NHRP server routes NHRP request to next NHRP server LIS LIS LIS 1 2 3 ❍! Destination NHRP returns dest ATM address back through NHRP server chain (like routed DNS) NHRP NHRP ❒! Source can send directly to dest. server, S1 server, S NHRP 3 using provided ATM address server, S2 26 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 VPN reference architecture customer provider edge device edge device 28 VPN: logical view virtual private network customer provider edge device edge device Part 1 2-29 Leased-line VPN customer site connects to customer sites interconnected via static virtual provider edge channels (e.g., ATM VCs), leased lines 30 Customer premise VPN ! All VPN functions implemented by customer Customer sites interconnected via tunnels ! Tunnels encrypted typically ! SP treats VPN packets like all other packets 31 Drawbacks ❒! Leased-line VPN: configuration costs, maintainence by SP: long time, much manpower ❒! CPE-based VPN: expertise by customer to acquire, configure, manage VPN Network-based VPN ❒! cCustomer’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 Network-based Layer 3 VPNs multiple virtual routers in single provider edge device 33 Tunneling 34 VPNs: why? ❒! Privacy ❒! Security ❒! 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 .