data oriented network architecture (dona) andrey ermolinskiy mohit chawla cs 262 a project poster...
TRANSCRIPT
Data Oriented Network Architecture (DONA)
Andrey ErmolinskiyMohit ChawlaCS 262 A Project PosterDecember 14
DONA Overview
Data REGs FINDs
DONA explores a clean-slate approach to Internet Architecture
Main idea: data-centric routing: Client requests a piece of
data by its name rather than the owner’s address
Names are flat, self-certifying
Dissemination Handlers (DH) are DONA “routers” Combine forwarding, name resolution, and data caching functions
DONA Overview (cont.)
Data REGs FINDs
DONA exposes three operational primitives: FIND -- discovers an entity
or a data item by its name Long-lived FINDs (ttl > 0)
are subscriptions, which set up forwarding state
REGISTER -- advertises ownership of a data item
PUSH -- disseminates new content to all current subscribers
DHes propagate REGISTER requests and route FINDs to nearby copies of data
Load Shedding and Congestion Control
Snapshot of Routing Table at DH D
Snapshot of Congestion Table at DH D
Optimality of Load Distribution
DCi 3
OPT_LS(Sk, Cn): “Given a set of clients and
servers with specific query rates and capacities respectively, find an optimal mapping between clients and servers to minimize the total latency incurred by queries in the system”.
We can show that OPT_LS is NP-complete (reduction from the k-partition problem)
c1 c2 c3.. cn-1
S1
cn
S2 S3
Cap(S1)=Cap(S2)=Cap(S3)=D
L(S1)=L(S2)=L(S3)=1
Sample construction for an instance of a 3-partition problem
C={ a1,a2,a3….aN};
3,2,1;3/
;,, 321
iCV
CVVV
i
Simulation Studies Event-driven simulator written in Java Observes average latency and CDFs of latency Simulation parameters:
A 10 node topology using GT-ITM and manually generated topologies
Latency between links: Pre-Assigned (GT-ITM/manual)
DONA Administrative Policies Goal: ability to selectively deny incoming FIND and REGISTER
requests based on fields in request header. Example:
DENY (type == REGISTER) OR (ttl != 0) OR (appHeader != HTTP)
type == REGISTER ttl != 0
appHeader != HTTPOR
OR
policy action
Parse the expression, convert it to a tree
DH sends a DENY message to inform the client of its decision
Client Access Control DONA provides a framework for implementing user access
control mechanisms (authentication and authorization). AUTHENTICATE policy action instructs a DH to request and
verify client’s credentials prior to granting its request.AUTHENTICATE group1 Certif (type == FIND)
policy action authentication domain
credentials format
DONA
AuthenticationAgent
Application
Client nodeFirst-hop DH
data request
2
1
FIND
Verifier 1
DONA
Verifier 2
Passwd CertifPolicy Module
3
4
AUTHENTICATE
DENY AUTH56credentials request
7
FIND8
Packet contain authToken
9
authToken
ACCEPT
10
Services and Applications RSS content dissemination on top of DONA:
Server-side proxy registers with a DH on behalf of content source. Client-side proxies convert RSS refresh requests into long-lived FINDs
(subscriptions), which set up forwarding state in the topology. PUSH operation propagates content updates through the
dissemination tree
PUSH
FIND (ttl > 0)
Reverse-path forwarding entry
RSS Client 1
RSS Client 2
DH 1Client Proxy 1
DH 2
DH 3
DH 4
RSS Source
Server ProxyClient Proxy 2
DONA
REGISTER
Services and Applications (cont.)
DONA rendezvous capabilities simplify design of Overlay Multicast: Global multicast routing state = shared undirected tree New group members use DONA to discover a nearby member and
attach themselves to the tree To transmit a packet to the group:
Sender locates a nearby member (M), forwards the packet to M Each member forwards the packet to its neighbors on the tree
DONA
M1M2
REGISTER
M4
M5 M6
FINDS1
ATTACH
FIND
SEND
sender
DONA routing ensures that resulting trees are geographically efficient