A Tetherless Computing Architecture

1. A Tetherless Computing Architecture Darcy Kroeker S. Keshav

2. B A A Background – Routing in Time-Varying Networks • 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.

3. Where Is This Important? Mars Mars Satellite Earth Satellite Earth Base Station Mars Base Station Mars Rover

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

5. DTN – Remaining Problems DTNRG goes a long way toward a solution, but from our perspective there are a few remaining problems: 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. 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? Our Tetherless Computing Architecture (TCA) addresses these problems

6. 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) Bus (Router) Village Kiosk (Router) Bus Terminal (Gateway)

7. 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) Bus (Router) Village Kiosk (Router) Bus Terminal (Gateway)

8. 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 Region A Internet Gateway A Registry Region C Gateway C Gateway B Region B

9. 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 Convergence Layer DTN TCP UDP … Before discussing the protocols, some background on naming and addressing….

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

11. 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 address tca://blackice/app tcp://5.6.7.8:5000 For example: 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.

12. 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 Region A Internet tca://windstorm tca://gwa addr: 1.2.3.4:5 tca://blackice Registry Region C tca://gwc Tca://gwb Region B tca://hurricane tca://hail

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

14. 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 Region A tca://blackice > 1.2.3.4:5 Internet tca://windstorm tca://gwa addr: 1.2.3.4:5 tca://blackice Registry Region C tca://gwc tca://gwb Region B tca://hurricane tca://hail

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

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

17. 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 Controller TCA Controller TCA register(eid) Bundle Layer Bundle Layer Bundle Layer Convergence Layer Convergence Layer Convergence Layer DTN TCP … TCP … TCP … register(eid) register(eid) mobile router gateway

18. TCA Control Bundles Cross-Calls (Inter-Node) src = tca://<host_eid>/admin dest = tca://<host_eid>/admin Up-Calls (Inter-Layer) src = tca://localhost/bundlelayer dest = tca://<host_eid>/admin register(mobile_eid, link_spec) coa(mobile_eid, gateway_link_spec) ask(link_spec) adv(link_spec, adv_str) 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) Down-Calls (Inter-Layer) src = tca://<host_eid>/admin dest = tca://localhost/bundlelayer add_route(pattern, link_spec) del_routes(pattern) get_routes(pattern) Complete Control API documentation: http://www.mindstream.watsmore.net/wiki/index.php?title=TCA_Source

19. ASK Protocol – Sequence Diagram

20. REGISTER Protocol – Sequence Diagram

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

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

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