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 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. 3
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
Historical Aside: Proposed Internetwork packet in 1974: local header source address dest. address seq. # byte count flag field text checksum network TCP 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 Berkeley.net Internet 2 UMass.net C&W Mediaone UCLA Noho.net 12
Internet Routing BGP defines routes between stub networks Berkeley.net Internet 2 UMass.net C&W UCLA Noho-to-UMass Mediaone Noho.net 13
Internet Routing BGP defines routes between stub networks Berkeley.net Internet 2 UMass.net C&W UCLA Noho-to-Berkeley Mediaone Noho.net 14
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
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
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
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 Loss Rate 10% 20% 30% 50% 80% 100% 30-minute average loss rates RON No Better Change 479 127 32 20 14 10 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!! One indirection hop provides almost all the benefit!" 0 0 0 0 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 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
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
IP View of the world IP network ATM network 23
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
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 hop-by hop forwarding: LIS 1 LIS 2 LIS 3 A-R1-R2-B R1 R2 25
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
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 edge device provider edge device 28
VPN: logical view virtual private network customer edge device provider edge device Part 1 2-29
Leased-line VPN customer sites interconnected via static virtual channels (e.g., ATM VCs), leased lines customer site connects to provider edge 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