The (r)evolution of wireless network architectures and protocols
3-1 Design Principles Goals: r identify, study common architectural components, protocol mechanisms...
-
Upload
justin-cambridge -
Category
Documents
-
view
215 -
download
0
Transcript of 3-1 Design Principles Goals: r identify, study common architectural components, protocol mechanisms...
3-1
Design Principles Goals: identify, study
common architectural components, protocol mechanisms
what approaches do we find in network architectures?
synthesis: big picture
design principles: separation of data,
control hard state versus soft
state randomization indirection network virtualization:
overlays multiplexing design for scale
3-2
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
3-3
Examples
Connecting local heterogeneous networks IP over ATM Resilient overlay networks VPN
3-4
The Internet: virturalizing 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
3-5
Cerf & Kahn: Interconnecting two networks
“…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.”
ARPAnet satellite net
3-6
Cerf & Kahn: Interconnecting two networks
ARPAnet satellite net
Gateway: “embed internetwork packets
in local packet format or extract them”
route (at internetwork level) to next gateway
gateway
Internetwork layer: addressing: internetwork
appears as a single, uniform entity, despite underlying local network heterogeneity
network of networks
3-7
Historical Aside:
Proposed Internetwork packet in 1974:
localheader
sourceaddress
dest.address
seq. # bytecount
flagfield
text checksum
network TCPidentifier
8 16
3-8
Cerf & Kahn’s Internetwork Architecture
What is virtualized? two layers of addressing: internetwork
and local network new layer makes everything
homogeneous at internetwork layer underlying local network technology
(cable, satellite, 56K modem) is “invisible” at internetwork layer
3-9
IP-Over-ATMClassic 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
ATMnetwork
EthernetLANs
EthernetLANs
3-10
IP-Over-ATM
AALATMphyphy
Eth
IP
ATMphy
ATMphy
apptransport
IPAALATMphy
apptransport
IPEthphy
3-11
IP View of the world
ATMnetwork
IPnetwork
3-12
Classical IP-over ATM [RFC 1577]
AB C D
E
R1 R2
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)
LIS1 LIS2 LIS3
3-13
Classical IP-over ATM [RFC 1577]
AB C D
E
R1 R2
Inter-LIS communication: source, dest. in different
LIS each LIS looks like a LAN hop-by hop forwarding:
A-R1-R2-E
LIS1 LIS2 LIS3
3-14
NHRP (next hop resolution protocol) [RFC 2332]
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
AB C D
E
NHRP server, S1
LIS1 LIS2 LIS3
NHRP server, S2
NHRP server, S3
“ARP over multiple hops”
3-15
IP-over-ATM: why?
because it’s there- use ATM network as a link-layer to connect IP routers
can manage traffic more carefully in ATM network (e.g., rate-limit source/dest pairs, provide CBR service)
leave IP untouched – leverage the fact that many users have IP addresses already
3-16
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
3-17
Overlay network
3-18
Overlay network Focus at the application level
3-19
Internet Routing BGP defines routes between stub networks
UCLA Noho.net
Berkeley.netUMass.net
Internet 2
Mediaone
C&W
3-20
Internet Routing BGP defines routes between stub networks
UCLA Noho.net
Berkeley.netUMass.net
Internet 2
Mediaone
C&W
Noho-to-UMass
3-21
Internet Routing BGP defines routes between stub networks
UCLA Noho.net
Berkeley.netUMass.net
Internet 2
Mediaone
C&W
Noho-to-Berkeley
3-22
Internet Routing
UCLA Noho.net
Berkeley.net UMass.net
Internet 2
Mediaone
C&W
Noho-to-Berkeley
Congestion or failure: Noho to Berkely BGP-determined route may not change (or will change slowly)
3-23
Internet Routing
UCLA Noho.net
Berkeley.net UMass.net
Internet 2
Mediaone
C&W
Noho-to-Berkeley
Noho to UMass to Berkeley route not visible or
available via BGP! MediaOne can’t route to
Berkeley via Internet2
Congestion or failure: Noho to Berkely BGP-determined route may not change (or will change slowly)
3-24
RON: Resilient Overlay Networks
Premise: by building application overlay network, can increase performance, reliability of routing
Two-hop (application-level) noho-to-Berkeley route
application-layer router
Virtualize the Internet!
Layer 7 routing!
3-25
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
3-26
An order-of-magnitude fewer failures
0010100%
001480%
002050%
003230%
15412720%
475747910%
RON Worse
No Change
RON Better
Loss Rate
30-minute average loss rates
6,825 “path hours” represented here12 “path hours” of essentially complete outage76 “path hours” of TCP outage
RON routed around all of these!One indirection hop provides almost all the benefit!
6,825 “path hours” represented here12 “path hours” of essentially complete outage76 “path hours” of TCP outage
RON routed around all of these!One indirection hop provides almost all the benefit!
3-27
RON Research Issues
• how to design overlay networks?• Measurement and self-configuration• 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?• Interacting levels of control (network- and
application-layer routing
3-28
Virtual Private Networks (VPN)
SP infrastructure: backbone provider edge devices
Customer: customer edge devices (communicating
over shared backbone)
Networks perceived as being private networksby customers using them, but built over shared infrastructure owned by service provider (SP)
VPNs
3-29
VPN reference architecture
customeredge device
provideredge device
3-30
VPN: logical view
customeredge device
provideredge device
virtual private network
3-31
Leased-line VPN
customer sites interconnected via static virtual channels (e.g., ATM VCs), leased lines
customer site connects to provider edge
3-32
Customer premise VPN
customer sites interconnected via tunnels tunnels encrypted typically SP treats VPN packets like all other packets
All VPN functions implemented by customer
3-33
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 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
3-34
Network-based Layer 3 VPNs
multiple virtual routers in single provider edge device
3-35
Tunneling
3-36
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 VPNs ability to share at lower layers even though logically
separate means lower cost exploit multiple paths, redundancy, fault-recovery in lower
layers Need isolation mechanisms to ensure resources shared
appropriately abstraction and manageability: all machines with
addresses that are “in” are trusted no matter where they are