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