Part 1: Design Principles

1
Part 1 Design Principles

• 7 design principles
• separation of data, control
• hard state versus soft state
• randomization
• indirection
• network virtualization overlays
• multiplexing
• design for scale

• Goals
• identify, study common architectural components,
  protocol mechanisms
• what approaches do we find in network
  architectures?
• synthesis big picture

2
4 Indirection

• Indirection rather than reference an entity
  directly, reference it (indirectly) via another
  entity, which in turn can or will access the
  original entity

• "Every problem in computer
• science can be solved by
• adding another level of
• indirection"
• -- Butler Lampson

x
A
B
3
Multicast one sender to many receivers

• Multicast act of sending datagram to multiple
  receivers with single transmit operation
• Question how to achieve multicast

• Network multicast
• router actively participate in multicast, making
  copies of packets as needed and forwarding
  towards multicast receivers

Multicast routers (red) duplicate and forward
multicast datagrams
4
Internet Multicast Service Model
128.59.16.12
128.119.40.186
multicast group 226.17.30.197
128.34.108.63
128.34.108.60

• multicast group concept use of indirection
• hosts addresses IP datagram to multicast group
• routers forward multicast datagrams to hosts that
  have joined that multicast group

5
Multicast via Indirection why?
6
How do you contact a mobilefriend?
Mobility and Indirection
I wonder where Alice moved to?
Consider friend frequently changing addresses,
how do you find her?

• search all phone books?
• call her parents?
• expect her to let you know where he/she is?

7
Mobility and indirection

• mobile node moves from network to network
• correspondents want to send packets to mobile
  node
• two approaches
• indirect routing communication from
  correspondent to mobile goes through home agent,
  then forwarded to remote
• direct routing correspondent gets foreign
  address of mobile, sends directly to mobile

8
Mobility Vocabulary
home network permanent home of mobile (e.g.,
128.119.40/24)
home agent entity that will perform mobility
functions on behalf of mobile, when mobile is
remote
wide area network
permanent address address in home network, can
always be used to reach mobile e.g.,
128.119.40.186
9
Mobility more vocabulary
visited network network in which mobile
currently resides (e.g., 79.129.13/24)
permanent address remains constant (e.g.,
128.119.40.186)
care-of-address address in visited
network. (e.g., 79,129.13.2)
wide area network
foreign agent entity in visited network that
performs mobility functions on behalf of mobile.
correspondent wants to communicate with mobile
10
Mobility registration
visited network
home network
wide area network

• End result
• foreign agent knows about mobile
• home agent knows location of mobile

11
Mobility via Indirect Routing
visited network
home network
wide area network
12
Indirect Routing comments

• mobile uses two addresses
• permanent address used by correspondent (hence
  mobile location is transparent to correspondent)
• care-of-address used by home agent to forward
  datagrams to mobile
• foreign agent functions may be done by mobile
  itself
• triangle routing correspondent-home-network-mobil
  e
• inefficient when
• correspondent, mobile
• are in same network

13
Indirect Routing moving between networks

• suppose mobile user moves to another network
• registers with new foreign agent
• new foreign agent registers with home agent
• home agent update care-of-address for mobile
• packets continue to be forwarded to mobile (but
  with new care-of-address)
• mobility, changing foreign networks transparent
  ongoing connections can be maintained!

14
Mobility via Direct Routing
correspondent forwards to foreign agent
visited network
home network
wide area network
correspondent requests, receives foreign address
of mobile
15
Mobility via Direct Routing comments

• overcomes triangle routing problem
• non-transparent to correspondent correspondent
  must get care-of-address from home agent
• what happens if mobile changes networks?

16
Mobile IP

• RFC 3220
• has many features weve seen
• home agents, foreign agents, foreign-agent
  registration, care-of-addresses, encapsulation
  (packet-within-a-packet)
• three components to standard
• agent discovery
• registration with home agent
• indirect routing of datagrams

17
Mobility via indirection why indirection?

• transparency to correspondent
• mostly transparent to mobile (except mobile
  must register with foreign agent)
• transparent to routers, rest of infrastructure
• potential concerns if egress filtering is in
  place in foreign networks (since source IP
  address of mobile is its home address) spoofing?

18
An Internet Indirection Infrastructure

• Motivation
• todays Internet is built around point-to-point
  communication abstraction
• send packet p from host A to host B
• one sender, one receiver, at fixed and well-known
  locations
• not appropriate for applications that require
  other communications primitives
• multicast (one to many)
• mobility (one to anywhere)
• anycast (one to any)
• weve seen indirection used to provide these
  services
• idea make indirection a first-class object

19
Internet Indirection Infrastructure (i3)

• change communication abstraction instead of
  point-to-point, exchange packets by name
• each packet has an identifier ID
• to receive packet with identifier ID, receiver R
  stores trigger (ID, R) into network
• triggers stored in network overlay nodes

Sender
Receiver (R)
20
What is a DHT?

• hash table
• data structure that maps keys to values
• essential building block in software systems
• Distributed Hash Table (DHT)
• similar, but spread across the Internet
• interface
• insert(key, value)
• lookup(key)

21
How?

• Every DHT node supports single operation
• given key as input route messages toward node
  holding key

22
DHT in action
23
DHT in action
24
DHT in action
Operation take key as input route messages to
node holding key
25
DHT in action put()
Operation take key as input route messages to
node holding key
26
DHT in action put()
insert(K1,V1)
Operation take key as input route messages to
node holding key
27
DHT in action put()
(K1,V1)
Operation take key as input route messages to
node holding key
28
DHT in action get()
retrieve (K1)
Operation take key as input route messages to
node holding key
29
DHT Design Goals

• an overlay network with
• flexible mapping of keys to physical nodes
• small network diameter
• small degree (fanout)
• local routing decisions
• robustness to churn
• routing flexibility
• Ddecent locality (low stretch)
• a storage or memory mechanism with
• best-effort persistence (via soft state)

30
DHT Topologies

• DHTs emulate interconnection networks
• have group-theoretic structure
• Cayley and Coset graphs
• rich families of such graphs with different
  properties
• can exploit the structure (i.e. constraints) of
  the overlay
• e.g. to embed complex computations with efficient
  communication

31
An Example DHT Chord

• overlayed 2k-Gons

32
Routing in Chord

• at most one of each Gon
• e.g. 1-to-0

33
Routing in Chord

• at most one of each Gon
• e.g. 1-to-0

34
Routing in Chord

• at most one of each Gon
• e.g. 1-to-0

35
Routing in Chord

• at most one of each Gon
• e.g. 1-to-0

36
Routing in Chord

• at most one of each Gon
• e.g. 1-to-0

37
Routing in Chord

• at most one of each Gon
• e.g. 1-to-0
• what happened?
• constructed thebinary number 15!
• routing from x to yis like computing y - x mod
  n by summing powers of 2

2
4
8
1
Diameter log n (1 hop per gon type)Degree log
n (one outlink per gon type)
38
Deconstructing DHTs

• DHT is composed of
• logical, underlying interconnection network
• an emulation scheme
• works on a non-round of nodes
• without global knowledge of network size
• self-monitoring components
• track and react to churn

39
A
B
D
C
40
Service Model

• API
• sendPacket(p)
• insertTrigger(t)
• removeTrigger(t) // optional
• best-effort service model (like IP)
• triggers periodically refreshed by end-hosts
• reliability, congestion control, flow-control
  implemented at end hosts, and trigger-storing
  overlay nodes

41
Discussion

• trigger is similar to routing table entry
• essentially application layer publish-subscribe
  infrastructure
• application-level overlay infrastructure
• unlike IP, end hosts control triggers, i.e., end
  hosts responsible for setting and maintaining
  routing tables
• provide support for
• mobility
• multicast
• anycast
• composable services

42
Mobility

• receiver updates its trigger as it moves from one
  subnet to another
• mobility transparent to sender
• location privacy

Receiver (R1)
Sender
trigger
ID
R1
43
Mobility

• receiver updates its trigger as it moves from one
  subnet to another
• mobility transparent to sender
• location privacy

Sender
ID
R2
Receiver (R2)
44
Multicast

• unifies multicast and unicast abstractions
• multicast receivers insert triggers with same ID
• application naturally moves between multicast and
  unicast, as needed
• impossible in current IP model

send(R1, data)
send(ID,data)
Receiver (R1)
ID
R1
Sender
ID
R2
send(R2, data)
Receiver (R2)
45
Anycast (contd)

• route to any one in set of receivers
• receiver i in anycast group inserts same ID, with
  anycast qualifications
• route to receiver with best match between a and si

send(R1,data)
Receiver (R1)
IDs1
R1
send(IDa,data)
IDs2
R2
Sender
Receiver (R2)
IDs3
R3
Receiver (R3)
46
Composable Services

• use stack of IDs to encode successive operations
  to be performed on data (e.g., transcoding)
• dont need to configure path between services

S_MPEG/JPEG
Receiver R (JPEG)
Sender (MPEG)
ID
R
ID_MPEG/JPEG
S_MPEG/JPEG
47
Composable Services (contd)

• both receivers and senders can specify operations
  to be performed on data

S_MPEG/JPEG
Receiver R (JPEG)
Sender (MPEG)
ID_MPEG/JPEG
S_MPEG/JPEG
ID
(ID_MPEG/JPEG, R)
48
Discussion of I3

• how would receiver signal ACK to sender? what is
  needed?
• does many-to-one fit well in this paradigm?
• security, snooping, information gathering what
  are the issues?

49
Indirection Summary

• Weve seen indirection used in many ways
• multicast
• mobility
• SoS
• Internet indirection
• The uses of indirection
• sender does not need to know receiver id - do not
  want sender to know intermediary identities
• beauty, grace, elegance
• transparency of indirection is important
• performance is it more efficient?
• security important issue for I3

50
5. 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 1960s/70s
• layering of abstractions dont sweat the details
  of the lower layer, only deal with lower layers
  abstractly

51
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

52
Cerf Kahn Interconnecting two networks
satellite net
ARPAnet

• 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.

53
Cerf Kahn Interconnecting two networks

• Gateway
• embed internetwork packets in local packet
  format or extract them
• route (at internetwork level) to next gateway

gateway
satellite net
ARPAnet
54
Historical Aside
Proposed Internetwork packet in 1974
55
Cerf Kahns 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

56
IP-Over-ATM

• IP over ATM
• replace network (e.g., LAN segment) with ATM
  network
• ATM addresses, IP addresses

• Classic IP only
• 3 networks (e.g., LAN segments)
• MAC (802.3) and IP addresses

ATM network
Ethernet LANs
Ethernet LANs
57
IP-Over-ATM
58
IP View of the world
IP network
ATM network
59
Classical IP-over ATM RFC 1577

• 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)

C
D
B
E
A
LIS1
LIS2
LIS3
R2
R1
60
Classical IP-over ATM RFC 1577

• Inter-LIS communication
• source, dest. in different LIS
• each LIS looks like a LAN
• hop-by hop forwarding
• A-R1-R2-E

C
D
B
E
A
LIS1
LIS2
LIS3
R2
R1
61
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

ARP over multiple hops
62
IP-over-ATM why?

• because its 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

63
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

64
Overlay network
65
Overlay network
Focus at the application level
66
Whats new/ whats old
67
Internet Routing

• BGP defines routes between stub networks

Internet 2
Berkeley.net
UMass.net
CW
Mediaone
UCLA
Noho.net
68
Internet Routing

• BGP defines routes between stub networks

Internet 2
Berkeley.net
UMass.net
CW
Mediaone
Noho-to-UMass
UCLA
Noho.net
69
Internet Routing

• BGP defines routes between stub networks

Internet 2
Berkeley.net
UMass.net
CW
Mediaone
Noho-to-Berkeley
UCLA
Noho.net
70
Internet Routing
Internet 2
Berkeley.net
UMass.net

• Congestion or failure Noho to Berkely
  BGP-determined route may not change (or will
  change slowly)

CW
Mediaone
Noho-to-Berkeley
UCLA
Noho.net
71
Internet Routing

• Noho to UMass to Berkeley
• route not visible or available via BGP!
• MediaOne cant route to Berkeley via Internet2

Internet 2
Berkeley.net
UMass.net

• Congestion or failure Noho to Berkely
  BGP-determined route may not change (or will
  change slowly)

CW
Mediaone
Noho-to-Berkeley
UCLA
Noho.net
72
RON Resilient Overlay Networks

• Premise by building application overlay network,
  can increase performance, reliability of routing

Layer 7 routing!
Two-hop (application-level) noho-to-Berkeley
route
application-layer router
Virtualize the Internet!
73
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-comm
  ercial-use policy

74
An order-of-magnitude fewer failures
30-minute average loss rates
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!
75
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

76
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)

77
VPN reference architecture
customer edge device
provider edge device
78
VPN logical view
virtual private network
customer edge device
provider edge device
79
Leased-line VPN
customer site connects to provider edge
customer sites interconnected via static virtual
channels (e.g., ATM VCs), leased lines
80
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

81
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

• customers 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

82
Network-based Layer 3 VPNs
multiple virtual routers in single provider edge
device
83
Tunneling
84
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, redundacy, 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