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