Transcript PPT Version

A Tetherless Computing
Architecture
Darcy Kroeker
S. Keshav
1
Background – Routing in Time-Varying
Networks
A





B
This network is partitioned into disconnected components
Routing from A to B is impossible
But… routing from A toward B is possible when components collide
… even if A and B are never connected
So… make sure the components collide once in a while
This requires a store-and-forward delivery mechanism similar to mail and e-mail.
2
Where Is This Important?
Mars
Mars
Satellite
Mars Rover
Mars
Base Station
Earth
Satellite
Earth
Base Station
3
Where Is This Important?
Developing Regions
Challenges:

Infrastructure is unreliable (eg. electricity, connectivity)

Communication and access to Internet is poor in rural areas

Costs must be very low to be affordable
Idea:

Use buses as “data mules” to ferry data between disconnected networks

Data hops on the bus, hops off again closer to destination

We trade communication response time for low cost, by using mechanical backhaul
(bus) for remote links
Key Applications

E-mail with attachments

Offline web browsing
4
DTN – Remaining Problems
DTNRG goes a long way toward a solution, but from our perspective there are a few
remaining problems:
Node Mobility

Nodes drop out and re-appear in a different place in the network!

How to notify other nodes of the new location?

How to re-direct any bundles already in transit to the old location?
Routing

DTN reference implementation includes three routing algorithms:

Static: uses static (manually configured) routing tables

Flood

Link State

We need a dynamic routing protocol that supports a high degree of node mobility.
Our Tetherless Computing Architecture (TCA) addresses these problems
5
TCA Overview
Node Types

All nodes run the TCA Protocol

There are three types of nodes:

Mobile: a leaf node (an end-user device typically, such as a phone, laptop, or PC)

Router: forwards data between nodes

Gateway: a special type of Router with a permanent connection to Internet
Phone
(Mobile)
Village Kiosk
(Router)
Bus
(Router)
Bus Terminal
(Gateway)
6
TCA Overview
Regions

A collections of nodes sharing a single gateway forms a Region

A Region is a disconnected network in general
Region
Phone
(Mobile)
Village Kiosk
(Router)
Bus
(Router)
Bus Terminal
(Gateway)
7
TCA Overview
A Higher-Level View : Many Regions

Unlike Regions, the Internet is usually available and connected

Gateways are the points at which the Regions connect to the Internet

A Region is associated with the gateway that serves it

TCA uses the Internet to host a Registry containing the current location (Region) of
each node
Internet
Region A
Gateway A
Registry
Gateway C
Gateway B
Region C
Region B
8
TCA Protocol Stack
The TCA Protocols deal with:

Registering a mobile node in the network

Routing bundles addressed to a mobile node

Route discovery
TCA Protocol Implementation:

Mostly implemented at the Application Layer

Uses the services of the DTN Bundle Layer
TCA
Application Layer
Bundle Layer
DTN
Convergence Layer
TCP
UDP
…
Before discussing the protocols, some background on naming and addressing….
9
TCA Naming and Addressing
Naming in DTN

The naming scheme in DTN is borrowed from existing Internet standards

Names are URIs, of the form <scheme name>:<scheme-specific part, or ssp>

The <scheme name> specifies the format and meaning of the <ssp>

Each “endpoint” in DTN (an application-level source or sink of bundles) has a URI
“Endpoint ID”
Example: dtn://blackice.uwaterloo.ca
Naming in TCA

TCA defines a custom scheme named “tca”

TCA Endpoint ID’s are of the form: tca://<host>/<app> where

<host> is a GUID (globally unique identifier) of the node
(analogous to <ip address> in TCP)

<app> is the identifier of an application on that node
(analogous to <port> in TCP)
Example: tca://blackice/app
These names are just identifiers, not sufficient information to actually contact a node.
10
TCA Naming and Addressing Contd.
Addresses

In addition to its name, each node has an address at which it may be contacted

This address is tied to a particular convergence layer (eg. tcp)

This address is again expressed as a URI:
Example: tcp://5.6.7.8:5000
A route (or a single hop thereof) can be expressed as a mapping from name to address
name
For example:
tca://blackice/app
address
tcp://5.6.7.8:5000
means: to send a bundle to the endpoint named tca://blackice/app, send it using the
tcp concvergence layer, to the TCP/IP address 5.6.7.8 port 5000.
Unlike in TCP/IP, in TCA it is not necessary (or even useful) for addresses to be known
globally. Only a node’s nearest neighbors – its direct contacts – need to know its address.
11
TCA Late-Bound Bundles
Example: hail sends bundle to blackice

bundle is forwarded up the default route to hail’s gateway

hail’s gateway looks up blackice’s gateway in the Registry and send bundle

blackice’s gateway forwards the bundle to blackice along known route
tca://blackice > 1.2.3.4:5
Internet
Region A
tca://windstorm
tca://blackice
tca://gwa
addr: 1.2.3.4:5
Registry
tca://gwc
Tca://gwb
Region C
tca://hurricane
Region B
tca://hail
12
TCA Late-Bound Bundles Contd.
Details:




Each node knows the address of the next hop router toward its gateway. This is its
default route used for all bundles addressed to unknown endpoints.
This enables routing from hail in Region C toward gateway C.
Each node knows the address of the previous hop router toward any router that has
previously registered with it. (registration to be discussed later).
This enables routing from gateway A to blackice in region A, assuming blackice has
previously registered in region A.
Implementation Notes:

The Registry is implemented as a Distributed Hash Table (using OpenDHT).

The Registry contains the SHA1 hash of an endpoint id, not the endpoint id itself.
13
TCA Registration
Example: blackice registers

blackice sends a special registration bundle up the default route

the “reverse path” is constructed along the way

gateway updates the Registry with blackice’s new location

if a previous registration for blackice existed, gateway initiates a change-of-address
Internet
Region A
tca://blackice > 1.2.3.4:5
tca://windstorm
tca://blackice
tca://gwa
addr: 1.2.3.4:5
Registry
tca://gwc
tca://gwb
Region C
tca://hurricane
Region B
tca://hail
14
TCA Registration Contd.
Details:

The register bundle is forwarded up the default route.

Each node along the way modifies the register bundle, adding its address as
last_hop

Each node along the way adds the route back to the mobile to its routing table, using
the last_hop address

Gateway C checks the Registry to see if blackice has previously registered in a
different region, deleting the previous entry if any.

In either case, Gateway C adds the new Registry entry for blackice, specifying its
own address as blackice’s gateway.

If blackice had previously registered in another region, Region B, Gateway C sends a
“change of address” bundle (COA) to Gateway B.

Gateway B forwards the COA toward blackice’s previous location using the reverse
path.

At each hop along the reverse path, the node destroys its route table entry for
blackice after forwarding the COA.
Implementation Notes:

No race condition! If a bundle is in-flight to a route undergoing destruction, it becomes
a regular unbound bundle at some point. Thereafter, the right thing happens.

Registration bundles are sent to the special endpoint id tca://registry
15
TCA Route Discovery
Motive

Most infrastructure nodes (“permanent” Routers and Gateways) will have their route
tables configured manually on setup.

Mobiles (and perhaps some Routers) need to choose routes dynamically, based on
their current location
Details

Similar to DHCP

Node A detects a new link. eg. potential neighbour node B at tcp://5.6.7.8:5000

Node A probes the DTN port on this link by sending an ASK bundle

If B is a TCA router, it responds with an ADV bundle

ADV contains B’s eid, and the eid of its reachable gateway

In future, ADV could contain additional info (link schedule, capacity, etc.)

Node A can now decide whether to add a permanent route to B

… and if so, whether to make this route its default route.
16
TCA Protocol Implementation





TCA Control logic is implemented outside DTN for greater separation of concerns
TCA Controller runs as an ordinary DTN client application
All Control messages are sent as bundles through the ordinary DTN API
Inter-Node Control bundles are sent to the eid of the destination Controller
Inter-Layer Control bundles are sent to a special eid tca://localhost/bundlelayer
TCA Controller
TCA
DTN
TCA Controller
TCA Controller
Bundle Layer
Bundle Layer
Bundle Layer
Convergence Layer
Convergence Layer
Convergence Layer
register(eid)
TCP
…
…
TCP
register(eid)
mobile
TCP
…
register(eid)
router
gateway
17
TCA Control Bundles
Cross-Calls (Inter-Node)
src = tca://<host_eid>/admin
dest = tca://<host_eid>/admin
register(mobile_eid, link_spec)
coa(mobile_eid, gateway_link_spec)
ask(link_spec)
adv(link_spec, adv_str)
Down-Calls (Inter-Layer)
src = tca://<host_eid>/admin
dest = tca://localhost/bundlelayer
add_route(pattern, link_spec)
del_routes(pattern)
get_routes(pattern)
Up-Calls (Inter-Layer)
src = tca://localhost/bundlelayer
dest = tca://<host_eid>/admin
ask_sent
adv_sent
coa_sent
contact_down
contact_up
link_available
link_unavailable
reg_received(mobile_eid, link_spec)
routes(route_list)
unb_received(eid)
Complete Control API documentation:
http://www.mindstream.watsmore.net/wiki/index.php?title=TCA_Source
18
ASK Protocol – Sequence Diagram
Src Controller
Src BL
Dest BL
Dest Controller
add_route
ask
ask
ask_sent
ask_received
del_route
add_route
adv
adv
adv_sent
adv
del_route
19
REGISTER Protocol – Sequence Diagram
Mobile
App
Controller
Router
BL
Controller
Gateway
BL
Controller
BL
register(mobile_eid, NULL)
reg_received
register(mobile_eid, link_spec)
register(mobile_eid, link_spec)
reg_received
register(mobile_eid, link_spec)
register(mobile_eid, link_spec)
reg_received
20
TCA Design Controversy
Layering TCA Control over Bundle Layer

Q: Is it the “right” separation of concerns?

Q: What functionality belongs in each layer?

Q: One process or two?

Q: Even if “right”, is it worth the trouble?

A: No clear answer. Similar to question of which parts of a protocol stack belong in
kernel, and which in user-level code.
Inter-Layer Communication as Bundles

Q: Is this a good idea?

A: Similar to the question of control-over-data channel versus separate control
channel. We have opted for control-over-data channel.
21
Future Work


We have a concrete application driving all future work:
Government services offered through kiosks in rural India
Plan to use a bus and kiosk network, running TCA protocols
Topics of Current Research

Mutual Authentication (Bus-Kiosk, Kiosk-User)

More advanced routing protocols using multiple routes:

Multiple buses with different schedules, destinations, gateways

Flow control – utilizing finite bus capacity:

Maximize fairness

Maximize throughput

Mixed-media communications

Cheap, high-capacity bus (but slow!)

Expensive, low-capacity cell network (but always available!)

OCMP uses policy definitions to send data using most suitable medium
22
Conclusion
1. TCA solves two of the problems with DTN:

Node mobility

Routing in a changing network
2. The Control API provides an extension point for future work
3. We hope our approach has applications of social importance in developing regions
23