Protocol for Tetherless Computing S. Keshav P. Darragh A. Seth S. Fung School of Computer Science University of Waterloo Waterloo, Canada, N2L 3G1 1. Introduction Tetherless computing involves asynchronous messaging between mobile endpoints and back-end centralized servers in environments where connectivity is intermittent and data propogation is delay-prone [1]. To enable this type of communication, the system must attain the following goals: 1. Mobility transparency 2. Disconnection transparency 3. Low control overhead 4. Identity management 5. Support for legacy applications [1] This document outlines the end-to-end protocol between the various entities in the tetherless computing architecture (TCA), which together allow secure communication in complex environments, while achieving the requirements listed above. The main agents in this protocol are the mobile endpoint, the access-point interface, mobile contacts, DHT nodes, i3 servers, and DTN nodes. 2.Acronyms APS (Access-point Server ) CM (Connection Manager) DTN (Delay Tolerant Networking) DHT (Distributed Hash Table) DHT-AM (DHT Addressing Manager) This server runs at the access-point. It provides an authentification service controls access of the network by mobile endpoints. It also maintains a list of local DTN nodes and/or i3 servers that it propagates to connecting endpoints. This module runs on the mobile endpoint, and handles many functions related the connected state of that endpoint and its location. An infrastructure which allows for robust, asynchronous messaging between endpoints in a delay-prone networking environment [2]. A decentralized mechanism for associating keys with values and allowing remotely-initiated queries [4]. This module acts as an interface between DTN and the DHT. Specifically, it resolves an address for the DTN layer by querying the DHT.
DTN-MM (DTN Mobility Manager) i3 (Internet Indirection Infrastructure) IDM ( Identity Manager) CL (Client Library) This module deals with inserting keys into the i3 overlay and ensuring that bundles are transferred from the incumbent custody DTN node. An infrastructure that provides mobile transparency for communicating endpoints in the Internet [3]. This module runs on the mobile endpoint. It communicates with the APS to provide secure access to networks. This library will provide application-level functionality. For example, it allows the client to handle registering for bundle delivery with the custody DTN node and receiving those bundles for reassembly. 3. Definitions An arbitrary collection of DTN nodes defined for administrative purposes. The Region identifier of any endpoint belonging to a region must be resolvable by any routing DTN node within that region [2]. Near Mobility This occurs when a mobile endpoint moves within a near area [1]. Far Mobility This occurs when a mobile endpoint moves from one near area to another [1]. Near Area The set of wireless APs which are closer to a given DTN router than any other DTN router [1]. Deep Region A region which is more than one disconnected hop from the Internet [1]. 3. Services 3.1 Description of Parameters GUID (Globally Unique Identifier) DTN tuple DTN address i3 server address Contact ID DTN Node ID DTN Region ID Each endpoint is assigned a globally unique ID. The formatted string used by DTN to address communication endpoints in the network. Includes information about region id, administrative id of the endpoint, interface, and more. The IP and port of the DTN node (the bundledaemon in particular. The IP and port of the i3 server. A globally unique identifier for a particular contact. An identifier for a DTN node that is unique within the region in which the node resides. A globally unique identifier for a particular region. 3.2 General Description of Scenarios There are two categories of scenarios for tetherless computing presented here. Mobile endpoints in the first set of scenarios are no more than one disconnected hop from the Internet. This means that any accesspoint to which an endpoint connects allows the
endpoint direct access to the Internet. These scenarios should cover the most prevalent use cases of tetherless computing. In the second set of scenarios, endpoints can be more than one disconnected hop from the Internet. Thus, they can connect to accesspoints, DTN nodes, and contacts which are themselves disconnected from the Internet. These scenarios are most likely to occur in rural areas where buses and planes act as mobile links within different deep regions. 4. Endpoints One Disconnected Hop From the Internet Fig. 4: TCA (DTN/I3) Network Topology The scenarios in this section cover the most common uses of tetherless computing architecture because they assume that the mobile endpoints in the system are no more than one disconnected hop from the Internet. As described earlier, this means that any access-point to which an endpoint can connect has direct access to the Internet, as shown in Figure 4 [1]. An integration of DTN and i3 is used to enable these scenarios. 4.1 Endpoint gains access to a network via an interface After the endpoint has selected an interface, it must scan for a signal from networks supporting that interface. In the case that there are multiple sources of signals, the endpoint must choose the optimal network to which it should connect. Having selected a
particular network, the endpoint must gain secure access to the services provided by the network. To this end, the endpoint and the network access-point must be able to identify each other and apply that identity against their respective trust model and access rules. Here are the general steps for gaining access to a network: 4.1.1 The CM selects a network interface. 4.1.2 The CM detects signals from networks supporting that interface, compiles a list of reachable networks and their respective signal strength, traffic load, etc. 4.1.3 CM chooses a network according to rules that take into account the endpoint's trust model, the signal strength, the network load data, billing, etc. 4.1.4 The IDM authenticates the network and replies with the endpoint's identity for authorization. 4.1.5 The APS confirms that access is granted to the endpoint and responds with a list of DTN and i3 servers (see Section 4.2). Here are the specific parameters passed between entities: Authentification (security) IDM APS Confirmation (security) APS IDM Table 1: Parameters for authentification between the network provider and the mobile endpoint. 4.2 Endpoint registers with custodian DTN node and i3 Once the endpoint has been authorized to access the network and determines that it trusts the provider, it must choose a custody DTN node and register that node with the i3 overlay. The accesspoint is aware of DTN nodes and i3 servers in its vicinity, as well as maintaining relevant stats on those hosts to allow the endpoint to make an optimal choice. Here are the general steps that allow the endpoint to choose its custody node and relaying that information to the i3 overlay: 4.2.1 The APS transmits to the end-point a list of neighboring DTN and i3 server nodes, with their respective traffic load. This list is piggybacked on the confirmation of access to the network. 4.2.2 The CM chooses a DTN custody node based on the data provided by the APS. The IDM informs the CL of this choice. 4.2.3 The CL layer registers itself with the DTN node and prepares to accept bundles (see Section 4.3). 4.2.4 The DTN-MM inserts the GUID of the endpoint as a public trigger into i3 with the address of the custody DTN node.
Here are the specific parameters passed between entities: DTN, i3 Server List <num nodes><dtn address><traffic measure>.. <num servers><i3 server address><traffic measure> APS IDM -> CM DTN Registration (security), DTN tuple CL DTN Register Trigger GUID, DTN address CM i3 server Table 2: Parameters for endpoint choosing DTN and i3 server. 4.3 Endpoint receives bundles from its custody DTN node There are two options available for the endpoint to receive bundles buffered at its custody DTN node. The first involves periodically polling the node for bundles. The DTN node buffers bundles until such a request comes from the client. This can be used when the endpoint wants to marshall its resources (eg: it is periodically in low-power mode). The other way the endpoint can have bundles delivered is to maintain a persistent connection with the DTN node while there is connectivity. This way, whenever the DTN node receives a bundle or has bundles buffered, it simply places it on this connection. Whenever the connection is not in place, the DTN node assumes the endpoint is disconnected and buffers any bundles addressed to that endpoint it receives. ISSUE: It is important that the DTN node can correctly verify the identity of the endpoint, and the endpoint can determine whether to trust the node (security). Here are the specific parameters passed between the endpoint and the DTN node. In both cases outlined above, the protocol is the same. The only difference is that for polling, the endpoint explicitly closes the connection. Bundle Request (security), DTN tuple CL DTN Bundle Delivery <num bundles> <bundle size> <bundle> DTN CL Table 3: Parameters for endpoint to receive bundles from custody DNT node. 4.4 Endpoint changes its current custody DTN node This scenario is most likely to occur when the endpoint engages in far mobility. That is, the endpoint regains connectivity and determines that the distance from its custody DTN node is causing inefficiencies for receiving bundles. For example, when connected the endpoint may monitor the RTT of packets sent to its custody DTN node, and when this value exceeds some threshold, it may choose to switch custody nodes. Besides proximity, the endpoint could choose to move to a new custody DTN node for a variety of other reasons, including load balancing, node failure, or network partition. In
all these cases, the protocol is as described below: 4.4.1 The endpoint gains authorization to a network, as described in Section 4.1. 4.4.2 The endpoint then selects a new custody DTN node and updates the GUID entry in i3 as described in Section 4.2. 4.4.3 The CM notifies the DTN-MM of the former custody DTN node of the change in custody. 4.4.4 The DTN-MM at the former custody DTN node(s) re-sends undelivered bundles to the GUID of the endpoint via i3. 4.4.5 The endpoint polls its new custody DTN node for bundles, as described in Section 4.3. Here are the specific parameters passed between entities notifying the former custody node; otherwise, the protocol follows the referenced sections. Custody Change Notification DTN tuple, DTN address CM DTN-MM Table 4: Parameters for endpoint to notify its former custody DTN node of its migration. 4.5 Endpoint achieves connectivity and stays with current custody DTN node When the endpoint regains connectivity in close proximity to its current custody DTN node, it may choose not to switch DTN nodes. In this case, it must simply resume polling its custody node, as described in Section 4.3. 4.6 Endpoint sends to a mobile endpoint Because all endpoints are at most one hop away from the Internet, it is possible to use i3, a network overlay that affords mobility transparency by allowing the sender endpoint to address bundles to a constant GUID assigned to the receiver. This section describes the protocol that allows i3 to route the bundles from the sender to the custody DTN node of the receiver endpoint. 4.6.1 After resolving the receiver's name to its GUID, the sender endpoint addresses the bundles with the DTN tuple bundles://internet/tcp://<guid>.i3:5000/<guid> and sends them using the CL interface. 4.6.2 Upon receiving the bundles from the i3 overlay, the receiver's custody DTN node attempts to deliver the bundles to the connection maintained by the endpoint ( as described in Section 4.3). If no connection to the endpoint exists, the DTN node buffers the bundles until the receiver reconnects or the DTN-MM receives a custody change notification.
4.7 Endpoint polls for list of DTN nodes and i3 servers The endpoint may choose while connected to move to a new custody DTN node. This could occur for a variety of reasons, including load balancing, node failure, or network partition. In order to choose a new node, the endpoint needs to poll the APS for a list of neighboring DTN and i3 nodes. The protocol is described below: 4.7.1 The CM contacts the APS with a request for the current list of neighboring DTN and i3 nodes. 4.7.2 The APS transmits a list of neighboring DTN and i3 server nodes, with their respective traffic load. Here are the parameters involved in the communication: DTN, i3 Server Query (security) CM APS DTN, i3 Server List <num nodes><dtn address><traffic measure>.. <num servers><i3 server address><traffic measure> APS CM Table 5: Parameters for endpoint to poll for local DTN and i3 server information. ISSUE: What is the protocol by which DTN and i3 servers coming online register themselves with local APs? How does the AP detect when these nodes go down? 5. Entities More Than One Disconnected Hop From the Internet In these less common scenarios, mobile endpoints can be more than one disconnected hop from the Internet. Thus, they can connect to access-points, DTN nodes, and contacts that are themselves not directly connected to the Internet. A combination of DTN and DHT technologies is used to enable these scenarios. 5.1 Endpoint gains direct connectivity to a network via an interface This scenario is identical to the process described in Section 4.1 since the actual protocol between the endpoint and the network provider is not affected by the increase in hops between the APS and the Internet region. 5.2 Endpoint selects a custodian DTN node and registers with the DHT Similar to Section 4.2, this scenario involves the endpoint establishing itself within the framework of the architecture; however in this case, the endpoint interacts with a DHT rather than the i3 overlay, and more importantly, the custody DTN node may only be reachable via a mobile contact, which runs the APS.
Here are the steps involved for this scenario: 5.2.1 The APS transmits a list of neighboring DTN nodes, with their respective traffic load (this information is piggybacked on the confirmation of access to the network). In the case that the APS is running on a mobile contact, then the DTN nodes on the list are only those reachable by the mobile contact. Also, the mobile contact will indicate its flight path and the GPS location and RTT for each DTN node. 5.2.2 The CM chooses a DTN custody node based on the data provided by the APS. The IDM informs the CL of this choice. 5.2.3 The CL registers with its custody DTN node (see Section 5.3). 5.2.4 The CM updates the routing information for the endpoint in the system (see Section 5.4). Here are the specific parameters passed between entities: DTN Server List <num nodes><dtn Node Id><traffic measure><gps location><round trip time>.. <contact flight path info> APS IDM -> CM Table 6: Parameters for endpoint to select custody DTN node. 5.3 Endpoint selects custodian DTN node This scenario involves the endpoint notifying its custody DTN node to buffer bundles addressed to it. Since the endpoint may be in a disconnected environment, it may not be able to communicate directly with its custody DTN node to register. In this case, the mobile contact with which the endpoint gaining access to the network couriers both the registration data to the DTN node and possibly the bundles being delivered from the DTN node to the endpoint. Thus, when registering itself with the custody node, the endpoint needs to indicate that it is reachable via that mobile contact. Below are the parameters between the endpoint and the mobile contact. The mobile contact then passes this information on to the custody DTN node in the format shown in Table 8 below. Proxy DTN Registration (security), DTN Node ID, DTN tuple, contact ID CL Mobile Contact -> Custody DTN Node Table 7: Parameters for the endpoint to register with the custody DTN node by proxy through the mobile contact. If the endpoint can directly reach its custody DTN node via the access-point, then the registration is similar to that described in Section 4.2. The exception is the contact ID communicated to the DTN node indicates that the endpoint is directly reachable (ie, there is no intermediary mobile contact). The parameters are below:
DTN Registration (security), DTN tuple, contact ID CL DTN Table 8: Parameters for registering an endpoint with its custody DTN node. 5.4 Endpoint updates its routing information The prevalence of deep regions in these scenarios complicates the routing information required to locate an endpoint. This occurs because an endpoint cannot be located by just its GUID alone; the DTN routing algorithm requires the endpoint's current region as well. Thus, the endpoint needs to notify not only the regional gateways of its residency in their region, but also the global DHT of what region it is in. If the endpoint is in a deep region then here are the steps: 5.4.1 The CM transmits to the mobile contact a control bundle which is meant to notify all the custodians to update their local lookup tables. 5.4.2 The mobile contact and the selected custodians participate in a group communication protocol during which all the custodians get updated. 5.4.3 When the previous step terminates, a chosen custodian in each region participates in a group communication protocol with all the DTN gateways in the region, or a centralized DHT to update all the regional route tables. 5.4.4 When the previous step terminates, one of the chosen DTN gateways updates the Internet region s DHT, and supplies information about the region in which the endpoint GUID is located, as well as callback information for the endpoint s DTN custody node. 5.4.5 Next, a DTN gateway in the Internet region participates in a group communication protocol with the set of gateways in the mobile s old region to update their regional mappings for deleting the route outdated entries for the mobile. 5.4.6 When the previous step terminates, the gateway reliably multicasts an update to all the custodians in the old region. The custodian send any stored bundles to the mobile in the new region by rewriting the bundles destination address as unknown and forwarding them on its default route. Here are the contents of the control bundles Region Routing Control Bundle GUID, DTN Node ID CM Mobile Contact -> Regional Gateways DHT Control Bundle GUID, DTN Region ID, DTN Node ID CM Mobile Contact -> Regional Gateway for Routing to Internet Table 9: Contents of control bundles for updating router information of an endpoint entering new near region. If the endpoint can connect directly to a DTN node (ie, it is not in a disconnected region),
then it transmits these bundles itself directly to a DTN router, bypassing the need for a mobile contact. 5.5 Endpoint moves from one deep region to another If the endpoint moves from one region to another, then there are two processes that must occur. The endpoint must update its routing information, and its former custody DTN node must be notified so that it can pass on any buffered bundles for the endpoint to the new custody DTN node. The steps in Section 5.4 describe the required actions to be performed. 5.6 Endpoint changes DTN custody nodes in same near region This is the degenerate case that mirrors the scenario described in Section 4.4, in which there is only one region: the Internet. Since the endpoint has not moved regions, it must simply update the local routing information. Also, the former custody node must be notified so that any buffered bundles are passed on to the new custody node. Here are the steps involved: 5.6.1 The CM transmits to the mobile contact a control bundle which is meant to notify all the custodians to update their local lookup tables. 5.6.2 The mobile contact and the selected custodians participate in a group communication protocol during which all the custodians get updated. 5.6.3 When the previous step terminates, a chosen custodian in each region participates in a group communication protocol with all the DTN gateways in the region, or a centralized DHT to update all the regional route tables. 5.6.4 When the previous step terminates, the custodian reliably multicasts an update to all the old custodians. These old custodians send any stored bundles to the mobile according to its new route mappings. Here are the contents of the control bundles: Callback Control DTN tuple (endpoint), DTN tuple CM Mobile Contact -> Bundle (new custody node) DTN DHT Update Control GUID, DTN node ID CM Mobile Contact -> Bundle Regional Gateway for Routing to Internet Table 10: Contents of control bundles for updating router and custody information of endpoint engaging in near mobility. 5.7 Endpoint resolves address of mobile endpoint This scenario involves an endpoint wishing to know the location of mobile endpoint, in order to address bundles to that endpoint.
5.7.1 The DHT-AM transmits a bundle which queries the DHT for the address of the receiver endpoint. 5.7.2 The DHT looks up the given GUID and responds with a control bundle containing the region information of the endpoint in question. Here are the contents of these control bundles: DTH Look-Up GUID (query), GUID (sender) DHT-AM DHT Control Bundle DHT Response Control Bundle GUID, DTN Region ID DHT DHT-AM Table 11: Contents of control bundles for querying a GUID in global DHT. 5.8 Endpoint in deep region sends to endpoint in different deep region The endpoint has two methods by which it can address bundles to a mobile receiver in a particular region. It can either perform the resolution of the receiver's DHT itself, or it can allow the DTN Internet gateways to perform the resolution. These two options are described in detail below. 5.8.1 Endpoint manually resolves GUID of receiver endpoint In this case, the sender has previously cached the location of the receiver and has reason to believe it is up-to-date, or the sender may have a scheme by which it periodically polls the DHT for the receiver's current region. In any case, here are the steps involved: 5.8.1.1 The sender looks up the current region of the receiver, as described in Section 5.7. 5.8.1.2 The sender addresses the bundles with the following format: bundles://<receiverregionid>//<receiverguid>:5000/<receiverguid>. The sender then transmits them through DTN (potentially via a mobile contact). 5.8.2 Endpoint does not resolve GUID of receiver endpoint To avoid having to resolve the GUID of the receiver, the sender endpoint can take advantage of default routing. Initially, the sender simply guesses that the receiver is in its own region, and addresses the bundles accordingly. When a DTN gateway in the sender's region receives the bundles, it will fail to find the receiver's GUID in its routing table. As a result, it will replace the DTN Region ID field in the DTN tuple of the bundles with a flag that indicates that the region of the receiver should be resolved in the global DHT in the Internet by a DTN gateway in that region. The full sequence in this process is described below: 5.8.2.1 The sender addresses the bundles with the following format: bundles://<senderregionid>//<receiverguid>:5000/<receiverguid>. It then
transmits them through DTN (potentially via a mobile contact). 5.8.2.2 The bundles first reach the DTN regional gateway of the sender's region. Since the receiver endpoint is not in that region, the gateway cannot resolve the GUID to a custody DTN node. Thus, it replaces the DTN tuple of each bundle with the tuple: bundles://<receiverguid>//<receiverguid>:5000/<receiverguid>. The gateway then forwards the bundles on a path toward the Internet region. 5.8.2.3 Each subsequent DTN gateway router along the way to the Internet fails in its attempt to resolve the region <receiverguid>, and continue to forward the bundles towards the Internet. 5.8.2.4 When a DTN gateway bordering on the Internet region receives the bundles, it recognizes that <receiverguid> as a flag. It resolves the receiver's GUID, as described in Section 5.7. 5.8.2.5 The gateway updates the DTN tuple of the bundles with the following format: bundles://<receiverregionid>//<receiverguid>:5000/<receiverguid>. 5.8.2.6 The DTN gateway then routes the bundles towards the receiver's region. 5.9 Endpoint in deep region sends to Receiver in same deep region This scenario is the degenerate case where the sender and receiver endpoints are in the same region, as in Scenario 4.6. The sender may or may not have previously resolved the address of the receiver, but in any case, the steps are the same: 5.9.1 (optional) The sender resolves the address of the receiver endpoint, as in Section 5.7. 5.9.2 The sender addresses the bundles with the following format: bundles://<senderregionid>//<receiverguid>:5000/<receiverguid>. It then transmits them through DTN (potentially via a mobile contact). 5.9.3 The bundles reach the DTN gateway of the sender's region. Since the receiver endpoint is in that region, the gateway resolves the receiver's GUID to a particular DTN node ID in the region. 5.9.4 The DTN gateway routes the bundles to that DTN node in the region. 5.10 Endpoint receives bundles from its custody DTN node Since the endpoint may or may not be able to directly connect to its custody DTN node, then there are two cases to consider. If the endpoint can connect directly to the DTN node, then its contact ID registered with the DTN node indicates so. Thus, when the custody DTN node receives bundles for the endpoint, it will recognize that it should wait for the endpoint to actively retrieve the bundles according to the steps described in Section 4.3. Otherwise, the contact ID for the endpoint will indicate the mobile contact by which it is reachable. When the custody DTN node receives bundles for the endpoint, it transmits them to the mobile contact for delivery. In the case that there are multiple contacts for a single endpoint, then the DTN node must optimally route the data based on its knowledge of the contacts involved, using an unspecified DTN routing algorithm. The steps below
describe this process: 5.10.1 When the mobile contact comes within range, the DTN node transmits any bundles destined for endpoints reachable by that contact. 5.10.2 When within range of the mobile contact, the endpoint contacts the APS of the mobile contact, and accesses the network, as described in Section 5.1. 5.10.3 The endpoint queries the mobile contact for bundles addressed to it. 5.10.4 The mobile contact delivers all bundles addressed to the endpoint, terminates the connection, and replies to the custody DTN node with the state of the delivery. The parameters involved in the interactions are described below: Proxy Bundle (security), <num bundles>, <bundle size> DTN Mobile Contact Delivery <bundle> DTN Bundle Request (security), DTN tuple CL Mobile Contact DTN Bundle Delivery <num bundles>, <bundle size> <bundle> Mobile Contact DTN CL Table 12: Parameters for endpoint to receive bundles from custody DTN node by proxy through a mobile contact. 5.11The endpoint polls for a list of neighboring DTN nodes This scenario is analogous to that described in Section 4.7, except now the endpoint could be located in a deep region and be communicating with a mobile contact. Otherwise, the reason for the endpoint choosing to move to a new custody DTN node are much the same as those described in that section, namely load balancing, node failure, or contact failure. In order to choose a new node, the endpoint needs to poll the APS for a list of neighbouring DTN nodes. The protocol is described below: 5.11.1The CM contacts the APS with a request for the current list of neighboring DTN nodes. 5.11.2 The APS transmits a list of neighboring DTN nodes, with their respective traffic load. If the APS in on a mobile contact, then the contact's flight path and the GPS location and RTT for each DTN node will also be passed on. Here are the specific parameters for this communication: DTN Node Query (security) CM APS DTN Node List <num nodes><dtn Node Id><traffic measure><gps location><round trip time>.. <contact flight path info> APS CM Table 13: Parameters for endpoint to query APS for information on local DTN nodes.
6. Description of Data Maintained By Modules This section describes what data must be maintained by the various modules in the architecture. Just as the scenarios are divided into two categories, so too is this section because the modules are different depending on how many hops the endpoint is from the internet. 6.1 Endpoints One Disconnected Hop From the Internet The table in this section describes the data maintained by modules referenced in Section 4, where mobile endpoints in the system were assumed to be no more than one disconnected hop from the Internet. As described earlier, this means that any access-point to which an endpoint can connect has direct access to the Internet. Module CM APS DTN node i3 Data -address, proximity, and traffic load of current custody DTN node -address, proximity, and traffic load of i3 server entry point -map of local DTN addresses to associated traffic load data -map of local i3 addresses to associated traffic load data -identity management data for endpoints currently authorized to access network -security data that allows APS to grant access to network -list of registered endpoints -map of GUID trigger to associated DTN tuple of custody DTN node for the endpoint 6.2 Entities More Than One Disconnected Hop From the Internet The table in this section describes the data maintained by modules referenced in Section 5, where entities were more than one disconnected hop from the Internet. In other words, endpoints can connect to access-points, DTN nodes, and contacts that are themselves not directly connected to the Internet. CM APS Module Data -DTN Node ID, GPS coordinates, round trip time, and traffic load of current custody DTN node -map of known Contacts ID to associated flight paths -address of global DHT entry point -map of local DTN Node IDs to associated GPS coordinates, round trip time, and traffic load data -Contact ID where APS resides
Module Data -identity management data for endpoints currently authorized to access network -security data that allows APS to grant access to network -(optional) bundles intended for delivery to endpoints reachable from mobile contact DTN node -list of registered endpoints Local DHT/regional -map of GUID to associated DTN node ID of custody DTN node of DTN gateways endpoint Global DHT -map of GUID to associated DTN Region ID of endpoint 7. Open Issues Section 4.3 4.7 4.2, 4.4, 4.6, 5.7 5.4, 5.5, 5.6 Issue It is important that the DTN node can correctly verify the identity of the endpoint, and the endpoint can determine whether to trust the node (security). What is the protocol by which DTN and i3 servers coming online register themselves with local APs? How does the AP detect when these nodes go down? There are changes required of DTN, namely the functionality of the DTN-MM and the DHT-AM. There are changes required of the DHT, namely the callbacks for changes in key values. 7. References [1] A. Seth, et al. An Architecture for Tetherless Computing, Proc. Of InfoCOM, March 2005. [2] Kevin Fall. A Delay-Tolerant Network for Challenged Internets, Proc. Of SIGCOMM, August 2003. [3] Shelley Q. Zhuang, et al. Host Mobility using an Internet Indirection Infrastructure, First International Conference on Mobile Systems, Applications, and Services (ACM/USENIX Mobisys), May 2003. [4] Ion Stoica, et al. Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications, Proc. Of SIGCOMM, 2001.