Transcript ppt - Computer Science Division

Internet Indirection
Infrastructure
Ion Stoica
UC Berkeley
Motivations
• Today’s Internet is built around a unicast
point-to-point communication abstraction:
– Send packet “p” from host “A” to host “B”
• This abstraction allows Internet to be highly
scalable and efficient, but…
• … not appropriate for applications that require
other communications primitives:
–
–
–
–
Multicast
Anycast
Mobility
…
2
Why?
• Point-to-point communication  implicitly
assumes there is one sender and one receiver,
and that they are placed at fixed and well-known
locations
– E.g., a host identified by the IP address 128.32.xxx.xxx
is located in Berkeley
3
Key Observation
• Virtually all previous proposals use indirection,
e.g.,
– Physical indirection point  mobile IP
– Logical indirection point  IP multicast
“Any problem in computer science can
be solved by adding a layer of indirection”
4
Our Solution
Build an efficient indirection layer
on top of IP
• Use an overlay network to implement this layer
– Incrementally deployable; don’t need to change IP
Application
Indir.
TCP/UDP
layer
IP
5
Internet Indirection Infrastructure (i3)
• Each packet is associated an identifier id
• To receive a packet with identifier id, receiver R
maintains a trigger (id, R) into the overlay
network
data id
Sender
Receiver (R)
data R
id R
trigger
6
Service Model
• API
– sendPacket(p);
– insertTrigger(t);
– removeTrigger(t) // optional
• Best-effort service model (like IP)
• Triggers periodically refreshed by end-hosts
• ID length: 256 bits
7
Mobility
• Host just needs to update its trigger as it moves
from one subnet to another
Sender
id R2
R1
Receiver
(R1)
Receiver
(R2)
8
Multicast
• Receivers insert triggers with same identifier
• Can dynamically switch between multicast and
unicast
data id
Sender
data R1
id R1
Receiver (R1)
id R2
data R2
Receiver (R2)
9
Anycast
• Use longest prefix matching instead of exact
matching
– Prefix p: anycast group identifier
– Suffix si: encode application semantics, e.g., location
data p|a
Sender
data R1
p|s1 R1
p|s2 R2
Receiver (R1)
Receiver (R2)
p|s3 R3
Receiver (R3)
10
Service Composition: Sender Initiated
• Use a stack of IDs to encode sequence of
operations to be performed on data path
• Advantages
– Don’t need to configure path
– Load balancing and robustness easy to achieve
Transcoder (T)
data idT,id
Sender
data id
data T,id
idT T
data R
id R
Receiver (R)
11
Service Composition: Receiver
Initiated
• Receiver can also specify the operations to be
performed on data
data id
Sender
Firewall (F)
data R
data F,R
idF F
Receiver (R)
data idF,R
id idF,R
12
Quick Implementation Overview
• ID space is partitioned across infrastructure
nodes
– Each node responsible for a region of ID space
• Each trigger (id, R) is stored at the node
responsible for id
• Use Chord to route triggers and packets to
nodes responsible for their IDs
– O(log N) hops
13
Example
• ID space [0..63] partitioned across five i3 nodes
• Each host knows one i3 node
• R inserts trigger (37, R); S sends packet (37, data)
[8..20]
[4..7]
data 37
Sender (S)
[42..3]
[21..35]
[36..41]
data R
37 R
Receiver (R)
14
Optimization: Path Length
• Sender/receiver caches i3 node mapping a specific
ID
• Subsequent packets are sent via one i3 node
[8..20]
[4..7]
data 37
[42..3]
Sender (S)
cache node
[21..35]
[36..41]
data R
37 R
Receiver (R)
15
Optimization: Triangular Routing
• Use well-known trigger for initial rendezvous
• Exchange a pair of (private) triggers well-located
• Use private triggers to send data traffic
[8..20]
[4..7]
37
data
[2] 30
2 S
Sender (S)
[42..3]
S
[30]
[21..35]
[36..41]
[2] R
37 R
data
R
2
[30]
30 R
Receiver (R)
16
Outline
• Overview
 Security
• Discussion
17
Some Attacks
Eavesdropping
Loop
id1 id2
id R
id A
S
R
id4 id1
Attacker (A)
id2 id3
id3 id4
Attacker
Confluence
Dead-End
id2 id3
Attacker id1 id2
id2 id3
id2 id3
id3 V
Victim
(V)
Attacker
id1 id2
id2 id3
18
Constrained Triggers
• hl(), hr(): well-known one-way hash functions
• Use hl(), hr() to constrain trigger (x, y)
Right constrained
must match
ID: prefix
64
key
128
y.key = hr(x)
suffix
64
x
y
Left constrained
x.key = hl(y.key)
x.key = hl(y)
x
y
x
y
end-host address
19
Attacks & Defenses
Attack
Defense
Trigger
constraints
Pushback
Trigger
challenges
Public i3
node
constraints
Eavesdropping&
Impersonation
Loops &
Confluences
Dead-ends
Reflection &
Malicious triggerremoval
Confluences
on i3 public nodes
20
Outline
• Overview
• Security
 Discussion
21
Design Principles
1) Give hosts control on routing
– A trigger is like an entry in a routing table!
– Flexibility, customization
– End-hosts can
•
•
•
•
•
Source route
Set-up acyclic communication graphs
Route packets through desired service points
Stop flows in infrastructure
…
2) Implement data forwarding in infrastructure
– Efficiency, scalability
22
Design Principles (cont’d)
Host
Data plane
Internet &
Infrastructure overlays
p2p &
End-host overlays
i3
Infrastructure
Control plane
Data plane
Control plane
Control plane
Data plane
23
Example: Application Specific Routing
A
Network measurements
Route
Service
(ROSE-1)
Query/reply routing info.
Setup routes
ROSE-2
B
D
C
24
Conclusions
• Indirection – key technique to implement basic
communication abstractions
– Multicast, Anycast, Mobility, …
• This research
– Advocates for building an efficient Indirection Layer
on top of IP
– Explore the implications of changing the
communication abstraction; already done in other
fields
• Direct addressable vs. associative memories
• Point-to-point communication vs. Tuple space (in Distributed
systems)
25