Information-centric Routing for Opportunistic Wireless Networks

1.1. Assumptions and Design Choices

DABBER relies on the following assumptions with regard to opportunistic wireless environments:¶

o Nodes are mobile.¶

o Nodes overhear each other.¶

o Nodes can be data sources, data destinations, or forwarders.¶

o Nodes may decide to be the custodians of data transmissions based on a set of criteria, such as local available resources.¶

o Nodes do not have a complete topology view.¶

DABBER relies on the following major design choices to develop a name-based routing protocol for opportunistic wireless network:¶

o DABBER must avoid the network being flooded by Interest packets.¶

o DABBER is based on the distribution of name prefix (data reachability) only, since adjacency information may present high variability.¶

o DABBER is based on local information about the context of a node, in order to support the selection of the most suitable neighbours to forward Interest packets.¶

o DABBER avoids the definition of new messages by making usage of synchronization mechanisms already developed for NDN, such as ChronoSync [ChronoSync][PartialSync].¶

1.2. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.¶

3.1. Extensions to NFD

In order to augment NFD with a routing engine to allow for the deployment of NDN/CNN in wireless networks three new elements were included in NFD: a method to add routes to the RIB (Add_route in figure 1); a method to gather information (carried names) and status (time of reception) of Interest and Data messages (Pkt_Mng in figure 1); a new face able to handle the intermittent nature of wireless links, called Opportunistic Face (OPPFace) (c.f figure 1).¶

An OPPFace is a virtual face based on a system of packet queues to hide intermittent connectivity. An OPPFace is created for each neighbor node, where a neighbor node is any node that the current node has ever contacted to directly (i.e. over one radio hop). OPPFaces are kept in the Face Table and their state reflects the wireless connectivity status towards the respective neighbor: they can be in an Up or Down state, depending upon the wireless reachability the corresponding neighbor node.¶

When packets are dispatched based on the information stored in the FIB, an OPPFace is able to delay packet transmission until there is wireless connectivity to the correspondent neighbor: the OPPFace simply queue packets, when OPPFace is Down, or flush the queue, when OPPFace is Up. Since packet queuing is concealed inside OPPFaces, existing forwarding strategies do not need to be changed.¶

OPPFaces can be implemented by using any direct wireless communication mode (Infrastructured, Ad-Hoc, and Direct mode). The current implementation of NDN-OPP for Android devices [NDN-OPP-Android] makes usage of group communications provided by Wi-Fi Direct [NDN-emergency][NDN-opportunisticnets]. More information about the integration of NDN-OPP with Wi-Fi Direct is provided in section 6.2.¶

3.2. Routing Engine

DABBER is a name-based routing protocol that allows nodes to exchange information about name reachability in order to select the most suitable neighbours to forward Interest messages.¶

The operation of the DABBER routing engine is performed based on the following components, illustrated in figure 1:¶

o Neighbor_Management: Keep updated information about neighbours in a Neighbor Table. A neighbor entry in that table has information about the neighbor availability, centrality and similarity, as well as about the delay that Interest packets suffer when forwarded via a certain neighbour. The information about neighbours is used to compute the cost of each name prefix announced by them, while the information about the delay of Interest packets is used to update the weights of the neighbors entries in the RIB. The delay of Interest packets is a measure of the time difference between sending an Interest packet and receiving the corresponding Data packet, based on information collected from the Pkt_Mng module of NDN-OPP. The information about neighbor availability, centrality and similarity is collected by an external entity, as described in section 6.1.¶

o Compute_Name_Cost: This module computes the cost associated with each name prefix as a function of the node similarity of the neighbor announcing the name prefix, and the cost received in the announcement. That cost is used to update the entry of that name prefix / Neighbor in the DABBER internal Routing Table.¶

o Name_Prefix_Management: This module is responsible to remove and add Link State Announcement (LSA) into the Link State DataBase (LSDB) used by PSync. New LSAs present in the LSDB (announced by a neighbor) are removed in order to pass the following tuples to the module responsible to compute the costs of name prefixes: Name prefix; Cost; Neighbor.¶

o RIB_Update: This module keeps updated information about the cost of the name prefixes that will be used to populate the NFD RIB. The information about each name prefix is kept in a local Routing Table based on the tuple: Name prefix; Cost; Neighbor. The cost variable is a function of the cost provided by the Compute_Name_Cost module, plus the information about the availability and centrality of the neighbor, provided by the Neighbor_Management module. In defined periods of time the RIB_Update modules will use the content of the local Routing Table to populate the NFD RIB as well as to insert new LSA into the LSDB.¶

o LSDB: The Link State DataBase is the structure used by the PSync to keep all the information to be synchronized among neighbor nodes. By placing LSAs into the LSDB, DABBER ensures that such information is passed to all neighbours without the need to define a new set of messages for the exchange of routing information.¶

Between PSync and ChronoSync, DABBER makes use of the former since it is designed to support partial dataset synchronization. This means that PSync allows a node to subscribe to a subset of data streams, where a data stream is a sequence of data items under a common name prefix. Hence, by avoiding full sync operations of a LSDB in which only a few entries may be new, PSync helps to improve DABBER performance over networks in which wireless links are intermittently available.¶

4.1. Name Prefix Dissemination

DABBER was designed to exploit the synchronization mechanisms made available by NDN, such as PSync to control the dissemination of name prefixes without the need to define neither new messages nor new message passing mechanisms.¶

This means that while IP-based routing protocols push updates to other routers, DABBER devices pull updates. DABBER can use any underlay communication channels (e.g., TCP/UDP tunnels, Link layer TXT records) to exchange LSA information via an existing mechanism, such as PSync.¶

By using Interest/Data packets (exchanged by PSync), DABBER benefits from CCN/NDN built-in data authenticity to exchange routing information: since a routing update is carried in an Data packet and every Data packet carries a signature, a DABBER device can verify the signature of each LSA to ensure that it was generated by the claimed origin node and was not tampered during dissemination.¶

      Prefix LSA
+----------------------------------------------------+
|LSA |Number of|Prefix 1|Cost|...|Prefix N|Cost|Sign.|
|Name|Prefixes |        |    |   |        |    |     |
+----------------------------------------------------+

Figure 2: Prefix LSA format.¶

DABBER advertises Prefix LSAs every time a new name prefix is added or deleted to the LSA DataBase (LSDB). Name prefixes are advertised with a cost metric related to the validity of the associated data, as shown in Figure 2. Each LSA used by DABBER has the name DID/DABBER/LSA/Prefix/version. The DID is described by a scheme based on URIs. It can be for instance network/operator/home/node/. The version field is increased by 1 whenever a device creates a new version of the LSA.¶

DABBER disseminates LSAs via a data synchronization mechanism (e.g. PSync) of the local LSDB. This peer synchronization approach is receiver-driven, meaning that a device requests LSAs only when it has CPU cycles. Thus it is less likely a device will be overwhelmed by a flurry of updates. In order to reduce the amount of transferred data, DABBER removes obsolete LSAs from the LSDB by periodically refreshing each of its own LSAs by generating a newer version. Every LSA has a lifetime associated with it and will be removed from the LSDB when the lifetime expires.¶

DABBER performs the dissemination of LSAs based on a process able to synchronize the content of LSDBs. In this sense, all LSAs are kept in the LSDB as a name set, and DABBER uses a hash of the LSA name set as a compact expression of the set. Neighbor nodes use the hashes of their LSA name sets to detect inconsistencies in their sets. For this reason, neighbor nodes exchange hashes of the LSDB as soon as OPPFaces are up.¶

Current version of DABBER makes use of PSync as a synchronization mechanism. PSync allows DABBER to define a collection of named data in a local repo as a slice. LSA information is synchronized among neighbor nodes, since PSync keeps the repo slice containing the LSA information in sync with identically defined slices in neighboring repositories.¶

If a new LSA name is detected in a repo, PSync notifies DABBER to retrieve the corresponding LSA in order to update the local LSDB. DABBER can also request new LSAs from PSync when resources (e.g. CPU cycles) are available.¶

       Node A                            Node B
  +------------------------+     +---------------------------+
  |        +-------------+ |     |+-------------+            |
  | DABBER |    Psync    | |     ||    Psync    |   DABBER   |
  |        +-------------+ |     |+-------------+            |
  +------------------------+     +---------------------------+
       |            |  Sync Interest (1) |            |
       |            |------------------->|            |
       |            |<-------------------|            |
       | New LSA (2)|                    |            |
       |----------->|                    |            |
       |            |   Sync Reply (3)   |            |
       |            |------------------->|            |
       |            |                    | Notify (4) |
       |            |                    |----------->|
       |            |   LSA Interest (5) |            |
       |<-----------|--------------------|------------|
       |            |   LSA Data (6)     |            |
       |------------|--------------------|----------->|
       |            |                    |            |
       |            |  Sync Interest (7) |            |
       |            |------------------->|            |
       |            |<-------------------|            |

Figure 3: LSA exchange process.¶

Figure 3 shows how an LSA is disseminated between two neighbor nodes A and B, when the OPPFace is up. To synchronize the slice representing the LSDB information in the repo, PSync, on each node, periodically sends Sync Interests with the hash of its LSA name set / slice (step 1). When Node A has a new Prefix LSA in its LSDB, DABBER writes it in the Chronosync slice (step 2). At this moment, the hash value of the LSA slide of node A becomes different from that of node B. As a consequence, the PSync in node A replies to the Sync Interest of node B with a Sync Reply with the new hash value of its local LSA slice (step 3). The PSync in node B identifies the LSA that needs to be synchronized and notifies DABBER about the missing LSA, and updates its LSA name set (step 4). Since DABBER on node B has been notified of the missing LSA, DABBER sends an LSA Interest message to retrieve the missing LSA (step 5). DABBER on node A sends the missing data in a LSA Data message (step 6). When DABBER on node B receives the LSA data, it inserts the LSA into its LSDB. PSync on nodes A and B compute a new hash for updating the set and send a new Sync Interest with the new hash (step 7).¶

When more than one LSA needs to be synchronized, the issued LSA Interest packet will contain information about as many LSAs as allowed by the Link maximum transmission unit. In the same sense one LSA Data packet may also be used to transport information about more than one LSA.¶

4.2. Name Prefix Cost Computation

When DABBER is notified that a new Prefix LSA was registered in the LSDB or an existing Prefix LSA has a new version, it computes a new cost for each name prefix in such Prefix LSA. The cost of a name prefix is given by its validity.¶

DABBER starts by computing a new validity v for a prefix N depending upon the validity announced by the neighbor, and the relevancy of the association between the two neighbor nodes (e.g., node A and node B). The cost of the Name Prefix, passed to NFD, will then be computed as an inversely proportional value to its validity.¶

The relevance of the association between two neighbor nodes can be, e.g., a measure of similarity, where similarity is seen as a link measure, i.e., it provides a correlation cost between a node and its neighbors. Or such relation can be weighted based on metrics derived from average contact duration thus allowing a node to adjust the Name Prefix validity based on the probability of meeting the respective neighbor again. The "relation" between two neighbor nodes is computed based on the three metrics (A, C, and S) provided by the local contextual manager, plus a metric computed by DABBER itself: the time reachability.¶

The variable considered by DABBER for the computation of the validity/cost of a Name prefix passed by a neighbor Na are:¶

o Validity (V) - Represents the expiration date of the data associated with the Name Prefix. Currently it is the UNIX Timestamp (10 digit integer).¶

o Similarity metric (S) towards the neighbor Na, as passed by the contextual manager (S >= 0), aiming to select neighbors with whom the current node has a good communication link.¶

o Availability metric (A) towards the neighbor Na, as passed by the contextual manager ( 0 < A < 1), aiming to select neighbors able to process Interest packets with high probability.¶

o Centrality metric (C) towards the neighbor Na, as passed by an external context-aware agent (rf. to section 6.1, C >= 0), aiming to select neighbors with high probability of successfully forwarding Interest packets.¶

o Time reachability (T) which corresponds to the RTT between sending an Interest packet towards the source of such Name Prefix and receiving a data packet. (0 < T < 1). Currently the value of T is computed as (current time when data packet is received - time when Interest packet was sent) / Validity of Name Prefix. Time reachability allows DABBER to select next hops that lead to closer sources.¶

        Neighbor table
  +------------------------------------------------------+
  |   Face     | Status | Metric C | Metric A | Metric S |
  +------------------------------------------------------+
  |     1      |    UP  |    6     |   0.3    |    12    |
  |     2      |  DOWN  |    4     |   0.8    |    8     |
  |     3      |    UP  |    1     |   0.8    |    9     |
  +------------------------------------------------------+

Figure 4: Neighbor table.¶

The values C, A and S provided by the contextual manager are stored in a Neighbor Table (c.f. Figure 4) indexed by the number of faces. The higher the values of C, A and S, the most preferential a neighbor is.¶

T is measured by observing the flow of Interest and Data packets. Thus, the lowest the T, the most preferential a Face is. Although different nodes may have a different implementation of a face ranking logic, the relevancy of T in comparison to C and A should be higher, since T reflects the measured delay to reach a data source, while C and A are indicators of the neighbors potential as relays.¶

Based on the above mentioned metrics the Validity of a new Name Prefix (V) is updated based on two operations:¶

o V' = f (V, S') = trunc (V * S'), where:¶

S' = (S - Smin) / (Smax - Smin); Smin = 0 and Smax = max (Smax, C)¶

o V'' = f (V', C', A, T) = 0.3* trunc (V' * (C'+A)) + 0.7 * trunc (V' * T), where:¶

C' = (C - Cmin) / (Cmax - Cmin); Where Cmin = 0 and Cmax = max (Cmax, C)¶

The computation of V' is done by the Compute_Name_Cost module, while the execution of V'' is done by the RIB_Update module (c.f. figure 1). The value of V'' may be updated more often than V', since it is assumed that the properties of the neighbours (C,A) as well as the delay to a data holder (T) may vary more than the new announcement from neighbours with an updated value of V.¶

4.3. Update of Internal Structures

After the computation of the cost of the Name Prefix taking into account the relation of the current node with the neighbor announcing it, DABBER updates its internal routing table (operation done by the RIB_Update module) and its LSDB. The information on the routing table will be used to update the RIB of the local NFD and the information of the LSDB will be announced to all neighbors by PSync.¶

To update the Internal routing table, DABBER adds an entry (Na, V'') for the Name Prefix received from Na, where V'' is the computed cost of the name prefix. The routing table is then ordered by name prefix in decreased order of validity.¶

Since the current node will also disseminate the received Name Prefix, DABBER updates the cost of the Name Prefix in the LSA stored in its local LSDB in order to consider the computed value V''. For this, DABBER can use two methods:¶

o Maximal method: Cost of Name Prefix = max (V'', current cost on LSA).¶

o Average method: Cost of Name Prefix = max (average (cost of Name Prefix entries on local routing table), current cost on LSA).¶

4.4. Update of NFD Structures

After computing the new value of the cost of a name prefix, DABBER updates the RIB entry of that name prefix with the face over which the Name Prefix LSA was received and the new computed cost. The cost (k) of the Name Prefix to be stored in the RIB is computed based on its validity V'' as k = trunc (100/V'').¶

DABBER updates the RIB on NFD with the cost k based on three possible logics:¶

o Increase diversity - The new Face is included in the RIB entry, if the computed cost k helps to increase diversity of the name prefix. For instance the new cost k is higher than the average costs already stored for that name prefix, affected by a configured diversity constant. This logic includes all neighbors with cost = trunc (100/V''), such that 1/V'' - Avr (Costs in RIB for N) > X (predefined value).¶

o Downward Path Criterion - It is a non-equal cost multi-path logic that is guaranteed to be loop-free. Based on the Downward Path Criterion, the X faces (the maximum number X of desirable faces can be defined by configuration) to be considered for a name prefix include the one with the lowest cost k plus X-1 faces that have a cost k lower than the cost that the current node has itself to the name prefix. This logic includes X neighbors with cost = trunc(100/V''), such that cost is the lowest value of 1/V'' or cost < 1/ V.¶

o Downward Path Criterion extension - Also considers any face over which the name prefix can be reached with a cost k equal to the cost that the current node has itself to the name prefix. To avoid packets from looping back, there is the need to add a tiebreaker, which assures that traffic only crosses one direction of equal-cost links. This logic includes X neighbors with cost = trunc (100/V''), such that cost is the lowest value of 1/V'' or cost <=1/ V.¶

In any case the deployment of a DABBER network relies on having all nodes implemented with the same logic.¶

4.5. Packet Format

DABBER nodes exchange Prefix LSAs by means of a synchronization mechanism such as PSync, without the need to create new packets for the exchange of routing information.¶

6.1. Context Awareness

DABBER defines routing and forwarding strategies that take into consideration, at a network level, the context of wireless nodes, and not just the history of contacts among wireless nodes. Contextual information is obtained in a self-learning approach, by software-based agents running in each networked device, and not based on network wide orchestration. Contextual agents are in charge of computing nodes and link related costs concerning availability and centrality metrics. Contextual agents interact with DABBER via a well-defined interface: the contextual self-learning process is not an integrating part of the DABBER routing framework.¶

The contextual agent (named Contextual Manager [UmobileD45]) installed in each device can therefore be seen as an end-user background service that seamlessly captures wireless data to characterize the affinity network (roaming patterns and peers' context over time and space) and the usage habits and data interests (internal node information) of a node. Data is captured directly via the regular MAC Layer (e.g., Wi-Fi, Bluetooth, LTE) as well as via native applications for which the user configures interests or other type of personal preferences. For instance, an application can request a one-time configuration of categories of data interests (e.g., music, food).¶

Based on the defined interface, DABBER is able of querying the local Contextual Manager about the characteristics of neighbor nodes, based on three types of information: i) Node availability (metric A); ii) Node centrality (metric C); iii) Node similarity (metric S):¶

o Node Availability (A) gives an estimate of the node availability based on the usage of internal resources over time and space, as well as the usage of physical resources (battery status; CPU status, etc.).¶

o Node Centrality (C) provides awareness about the node's affinity network neighborhood context. This means that a list is kept with the following information about each neighbor: neighbour's node degree (number of nodes contacted in a predefined time window); Frequency of contacts between the neighbor and other nodes; Duration of each contact between the neighbor and other nodes; Importance of encountered nodes.¶

The Contextual Manager keeps values for the mentioned metrics for different periods of time. Encountered nodes can be of different types, such as other mobile devices or wireless access points, for instance.¶

6.2. Integration with Wi-Fi Direct

When Wi-Fi Direct is used on the MAC layer, there is a one-to-one correspondence between an OPPFace and a neighbor node (for each node detected in a Wi-Fi Direct Group, a new instance of an OPPFace is created). In this peer-to-peer scenario, OPPFaces can be used in two transmission modes: connection-oriented, in which packets are sent to a neighbor node via a reliable TCP connection over the group owner; connection-less, in which packets are sent directly to a neighbor node during the Wi-Fi direct service discovery phase. In the latter case data transmission is limited to the size of the TXT record (900 bytes for Android 5.1 and above). This type of communication is used to exchange small packets that require fast transmission (e.g. emergency apps, Chronosync status messages). The connection-less solution allows peers to exchange a short number of bytes without the establishment of a TCP socket.¶

In the peer-to-peer scenario of Wi-Fi direct, DABBER operates as follows: routing information is shared among all members of a Wi-Fi direct group, while Interest Packets are forwarded to specific neighbors. With Dabber it is the carrier of an Interest packet that decides which of the neighbors will get a copy of the Interest packet. Hence, with the current implementation of NDN-OPP, DABBER places a copy of the Interest packet in the OPPFaces of selected neighbors. In what concerns the dissemination of routing information, it is ensured by: i) node mobility, meaning that nodes carry such information between Wi-Fi direct groups; ii) information is passed between neighbor groups via nodes that belong to more than one group.¶

Based on the reception of notifications of Wi-Fi Direct regarding changes in the peers detected in the neighborhood, DABBER is able to update its internal peer list (Neighbor Table). If it is not currently connected to a Wi-Fi Direct Group, it performs a selection heuristic to determine which node to connect to. The motivation behind this selection process is to attempt to minimize the number of Wi-Fi Direct Groups in a certain area given that nodes can only transmit packets within the Group they are currently connected to.¶

By defining OPPFaces implemented based on a broadcast link layer such as ad-hoc Wi-Fi, DABBER will need to create only one OPPFace in each networked device. Such OPPFace would be used to exchange packets with any neighbor node, making use of the overhearing property of the wireless medium. Since with DABBER, it is the carrier that decides which of the neighbors are entitled to get a certain Interest packet, DABBER would need to encode in the Interest packet information about the ID of the neighbors that should process the overheard Interest packet.¶

6.3. Integration with DTN

By defining a new DTNFace implemented based on the bundle layer, DABBER could make use of the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) described in the DTN architecture. A DTNFace could provide a robust communications platform for the transmission of Data packets towards the consumer node, making usage of any available custodian nodes.¶

The bundle protocol [RFC5050] introduces the concept of a "bundle agent" that manages the interface between applications and the "convergence layers" that provide the transport of bundles between nodes during communication opportunities. A DTNFace would extends the bundle agent aiming to control the actions of the bundle agent during communication opportunities.¶

A new DTNFace would aim to control the reception and delivery of bundles, which are placed in a queue during the forwarding of Data packets. A DTNFace would allows the routing process to be aware of the bundles placed at the node, and allows it to inform the bundle agent about the bundles to be sent to a neighbor node. Therefore, the bundle agent implemented in a DTNFace would need to provide the following interface/functionality to the forwarding process:¶

o Get Bundle List: Returns a list of the stored bundles and their attributes to the routing agent.¶

o Send Bundle: Notifies the bundle agent to send a specified bundle.¶

o Drop Bundle Advice: Advises the bundle agent that a specified bundle may be dropped by the bundle agent if appropriate.¶

o Acked Bundle Notification: Bundle agent informs routing agent whether a bundle has been delivered to its final destination and time of delivery.¶

6.4. Producer Mobility

As NDN uses a publish/subscribe communication model, where request resolution and data transfer are decoupled, it is especially relevant to solve the problem of data producer mobility. Supporting producer mobility requires, first of all, finding the new location of the source each time data sources move, and, second, updating the name resolution system according to the new location, in order to maintain the consistency of NDN forwarding.¶

This could be achieved by using a dissemination method to efficiently discover data sources by replicating Interest messages in an efficient way that avoids network flooding [Optimal-stopping].¶

With this new feature the prospective forwarders for a given Interest message are limited in number and carefully selected in terms of three criteria:¶

o Centrality: how well connected a node is in the network. The more central a node is, the bigger the chances are to find a data source.¶

o Reliability: the likeliness of a node does not drop messages. The more reliable a node is, the least probable is that the Interest message will be discarded.¶

o Similarity: how alike the contacted candidate node is in terms of shared acquaintances. The less similar, the more likely is that it will find different nodes in the future.¶

In the current version of DABBER, the degree of diffusion of Interest packets depends on the logic used to update the RIB on NFD (Increase diversity, Downward Path Criterion, Downward Path Criterion extension). It may happen that the diffusion degree could still lead to some overhead. In this case DABBER could be extended to allow nodes to select the most suitable node among all of the neighbors to forward the Interest message based on an optimal stopping approach. This strategy relies on the existence of an optimal set of stopping values such that the nth discoverer node for a certain Interest message is the first contacted node which is the best of all the previously explored nodes, if the node has contacted the first stopping value. If this node is not found, then it will be the first node which is the second best of all the previous nodes, if the node has contacted the second stopping value, and so on. Otherwise, if these nodes are not found, then, the nth discoverer node will be the last nth node before reaching the last contacted node. This makes the dissemination of the Interest messages in Mobile NDNs efficient, even, and pervasive all over the network, increasing the delivery ratio while decreasing the network overhead.¶

7.1. Authenticity

DABBER routing messages are carried in Data packets containing a signature. Hence, a DABBER device can verify the signature of each routing message to ensure that it was generated by the claimed origin node and was not tampered with during dissemination. For this purpose, DABBER makes use of a hierarchical trust model for routing to verify the keys used to sign the routing messages.¶

DABBER can model a trust management as a five-level hierarchy, although reflecting a different administrative structure: represents the authority responsible by the international transit network allowing roaming services; represents the operator providing the mobile service; represents the network site of the mobile operator where the node is registered; represents the mobile equipment. Each node can create a DABBER process that produces LSAs.¶

Since keys must be retrieved in order to verify routing updates, DABBER allows each node to retrieve keys from its neighbors. This means that a DABBER node will use the Interest/Data exchange process to gather keys from all its direct neighbors. Upon the reception of an Interest of the type //broadcast/KEYS each neighbor looks up the requested keys in their local key storage and returns the key if it is found. In case a neighbor does not have the requested key, the neighbor can further query its neighbors for such key. The used key retrieval process makes use of a broadcast forwarding strategy, stopping at nodes who either own or cache the requested keys.¶

7.2. Confidentiality

Although being deployed under the control of an operator, DABBER allows its network to be extended beyond the reach of its infrastructure network, into scenarios where wireless communications between involved DABBER devices/router may be spoofed. Hence, DABBER requires routing data confidentiality to ensure the setup of a secure communication topology.¶

DABBER basic approach relies on the usage of encryption to protect the confidentiality of routing messages. By taking advantage of the semantically meaningful names DABBER relies on approaches such as Named-based Access Control (NAC) [NAC]. NAC provides content confidentiality and access control based on a combination of symmetric and asymmetric cryptography algorithms, while using NDN's data-centric security and naming convention to automate data access control.¶

Being implemented in wireless devices that may energy constraint, it will be important to verify the efficiency of the cryptographic solution, namely since the generation of asymmetric key pairs as well as the symmetric and asymmetric encryption/decryption operations may be expensive in terms of the usage of resources.¶

7.3. Privacy

In DABBER, forwarding decisions are taken into account using different metrics such as centrality and similarity. While these metrics may be efficient in terms of node selection, they can breach privacy of network users carrying networked devices by inferring social related information such as position inside groups, as well as information about the devices themselves.¶

If exchanged as clear text, the information carried in routing metrics may potentially compromise the privacy of users. A way of preserving the privacy of the users in DABBER could pass by using homomorphic encryption for information-centric wireless Ad Hoc Networks.¶

With homomorphic encryption forwarding decisions are made by performing calculations on encrypted forwarding metric values without decrypting them first, while maintaining low overhead and delays. As a result, forwarding decisions can be taken preserving the user's privacy. For these purposes, homomorphic encryption is extremely useful. This cryptographic scheme allows computations on ciphertexts and generates encrypted results that, when decrypted, match the results of the operations as if they had been performed on plaintexts.¶

10.1. Normative References

[DABBER18]

Mendes, P., Sofia, R., Soares, J., Tsaoussidis, V., and S. Diamantopoulos, "Information-centric Routing for Opportunistic Wireless Networks", in Proc. of ACM Information Centric Networking , September 2018.

[DABBER18-1]

DABBER Development Team, "DABBER Source Code", https://github.com/COPELABS-SITI/ndn-opp/tree/dabber , September 2020.

[DABBER18-2]

DABBER Development Team, "DABBER Android", https://play.google.com/store/apps/details?id=pt.ulusofona.copelabs.ndn , September 2020.

[NDN-OPP]

Tavares, M. and P. Mendes, "NDN-Opp: Named-Data Networking in Opportunistic Networks", Technical Report COPE-SITI-TR-18-01 , January 2018.

[NFD]

A. Afanasyev, et al, "NFD Developer's Guide", NDN Technical Report NDN-001 , October 2010.

10.2. Informative References

[ChronoSync]

Zhu, Z. and A. Afanasyev, "Lets ChronoSync:Decentralized Dataset State Synchronization in Named Data Networking", in Proc. IEEE ICNP , October 2013.

[Dlife]

Moreira, W., Mendes, P., and S. Sargento, "Opportunistic Routing based on daily routines", in Proc. of IEEE WoWMoM workshop on autonomic and opportunistic communications, San Francisco, USA , June 2012.

[Dlife-draft]

Moreira, W., Mendes, P., and E. Cerqueira, "Opportunistic Routing based on Users Daily Life Routine", IETF Internet Draft (draft-moreira-dlife-04) , May 2014.

[NAC]

Z. Zhang, et al, "NAC: Automating Access Control via Named Data", in IEEE MILCOM , October 2018.

[NDN-emergency]

Tavares, M., Aponte, O., and P. Mendes, "Named-data Emergency Network Services", in ACM MOBISYS, Munich, Germany , June 2018.

[NDN-OPP-Android]

NDN-OPP Development Team, "NDN-OPP Android", https://github.com/COPELABS-SITI/ndn-opp , September 2020.

[NDN-opportunisticnets]

Dynerowicz, S. and P. Mendes, "Named-Data Networking in Opportunistic Networks", ACM ICN, Berlin, Germany , September 2017.

[OI]

Lopes, L., C. Sofia, R., Mendes, P., and W. Moreira, "Oi! Opportunistic Data Transmission Based on Wi-Fi Direct", in Proc. of IEEE INFOCOM , April 2016.

[Optimal-stopping]

Borrego, C., Amado, M., Molinaro, A., Mendes, P., C. Sofia, R., Magaia, N., and J. Borrel, "Forwarding in Opportunistic Information-Centric Networks: An Optimal Stopping Approach", IEEE Communications Magazine, 58(5), 56-61 , 2020.

[PartialSync]

Zhang, M., Lehman, V., and L. Wang, "PartialSync:Efficient Synchronization of a Partial Namespace in NDN", NDN Technical Report NDN-0039 , June 2016.

[RFC4838]

Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, April 2007, <https://www.rfc-editor.org/info/rfc4838>.

[RFC5050]

Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, DOI 10.17487/RFC5050, November 2007, <https://www.rfc-editor.org/info/rfc5050>.

[RFC7476]

Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., Tyson, G., Davies, E., Molinaro, A., and S. Eum, "Information-Centric Networking: Baseline Scenarios", RFC 7476, DOI 10.17487/RFC7476, March 2015, <https://www.rfc-editor.org/info/rfc7476>.

[Scorp]

Moreira, W., Mendes, P., and S. Sargento, "Social-aware Opportunistic Routing Protocol based on User's Interactions and Interests", in Proc. of AdhocNets, Barcelona, Spain , October 2013.

[Umobile]

C. Sarros, et al, "Connecting the Edges: A Universal, Mobile centric and Opportunistic Communications Architecture", IEEE Communication Magazine , February 2018.

[UmobileD45]

R. Sofia, et al, "UMOBILE D45 - Report on Data Collection and Inference Models", Umobile Technical Report , September 2018.