Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 A Tetherless Computing Architecture Darcy Kroeker S. Keshav.

Similar presentations

Presentation on theme: "1 A Tetherless Computing Architecture Darcy Kroeker S. Keshav."— Presentation transcript:

1 1 A Tetherless Computing Architecture Darcy Kroeker S. Keshav

2 2 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 AA B This requires a store-and-forward delivery mechanism similar to mail and .

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

4 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 with attachments Offline web browsing

5 5 DTN – 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 DTNRG goes a long way toward a solution, but from our perspective there are a few remaining problems:

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

7 7 TCA Overview Regions A collections of nodes sharing a single gateway forms a Region A Region is a disconnected network in general Village Kiosk (Router) Bus (Router) Phone (Mobile) Bus Terminal (Gateway) Region

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

9 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 Convergence Layer Bundle Layer Application Layer TCPUDP… DTN TCA TCA Protocol Implementation: Mostly implemented at the Application Layer Uses the services of the DTN Bundle Layer Before discussing the protocols, some background on naming and addressing….

10 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 : The specifies the format and meaning of the Each endpoint in DTN (an application-level source or sink of bundles) has a URI Endpoint ID Example: dtn:// Naming in TCA TCA defines a custom scheme named tca TCA Endpoint IDs are of the form: tca:// / where is a GUID (globally unique identifier) of the node (analogous to in TCP) is the identifier of an application on that node (analogous to in TCP) Example: tca://blackice/app These names are just identifiers, not sufficient information to actually contact a node.

11 11 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:// :5000 A route (or a single hop thereof) can be expressed as a mapping from name to address TCA Naming and Addressing Contd. tca://blackice/apptcp:// :5000 nameaddress Unlike in TCP/IP, in TCA it is not necessary (or even useful) for addresses to be known globally. Only a nodes nearest neighbors – its direct contacts – need to know its address. 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 port 5000.

12 12 TCA Late-Bound Bundles Region A Region B Region C tca://gwa addr: :5 Tca://gwb tca://gwc Internet Registry tca://blackice tca://hail tca://hurricane tca://windstorm Example: hail sends bundle to blackice bundle is forwarded up the default route to hails gateway hails gateway looks up blackices gateway in the Registry and send bundle blackices gateway forwards the bundle to blackice along known route tca://blackice > :5

13 13 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. TCA Late-Bound Bundles Contd.

14 14 TCA Registration Region A Region B Region C tca://gwa addr: :5 tca://gwb tca://gwc Internet Registry tca://blackice tca://hail tca://hurricane tca://windstorm 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 blackices new location if a previous registration for blackice existed, gateway initiates a change-of-address tca://blackice > :5

15 15 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 blackices 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 blackices 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 TCA Registration Contd.

16 16 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:// :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 Bs 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. TCA Route Discovery

17 17 TCA Protocol Implementation Convergence Layer Bundle Layer TCA Controller TCP… DTN TCA 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 Convergence Layer Bundle Layer TCA Controller TCP… Convergence Layer Bundle Layer TCA Controller TCP… register(eid) mobileroutergateway register(eid)

18 18 TCA Control Bundles Cross-Calls (Inter-Node) src = tca:// /admin dest = tca:// /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:// /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:// /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:

19 19 ASK Protocol – Sequence Diagram

20 20 REGISTER Protocol – Sequence Diagram

21 21 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. TCA Design Controversy 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 22 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 Future Work

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

Download ppt "1 A Tetherless Computing Architecture Darcy Kroeker S. Keshav."

Similar presentations

Ads by Google