idnits 2.17.1 draft-mendes-icnrg-dabber-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 12, 2019) is 1685 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group Paulo Mendes 3 Internet-Draft Airbus 4 Intended Status: Experimental Rute C. Sofia 5 Expires: March 15, 2020 fortiss 6 Vassilis Tsaoussidis 7 Democritus University of Thrace 8 Carlos Borrego 9 Autonomous University of Barcelona 10 September 12, 2019 12 Information-centric Routing for Opportunistic Wireless Networks 13 draft-mendes-icnrg-dabber-03 15 Abstract 17 This draft describes the Data reAchaBility BasEd Routing (DABBER) 18 protocol, which has been developed to extend the reached of Named 19 Data Networking based routing approaches to opportunistic wireless 20 networks. By "opportunistic wireless networks" it is meant multi-hop 21 wireless networks where finding an end-to-end path between any pair 22 of nodes at any moment in time may be a challenge. The goal is to 23 assist in better defining opportunities for the transmission of 24 Interest packets towards the most suitable data source, based on 25 metrics that provide information about: i) the availability of 26 different data sources; ii) the availability and centrality of 27 neighbor nodes; iii) the time lapse between forwarding Interest 28 packets and receiving the corresponding data packets. The document 29 presents an architectural overview of DABBER followed by 30 specification options related to the dissemination of name-prefix 31 information to support the computation of next hops, and the ranking 32 of forwarding options based on the best set of neighbors to ensure a 33 short time-to-completion. 35 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 50 This Internet-Draft will expire on March 2, 2020. 52 Copyright and License Notice 54 Copyright (c) 2019 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.1. Contextual Aspects . . . . . . . . . . . . . . . . . . . . 5 71 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . 6 72 1.3. NFD Adjustment to Opportunistic Networks . . . . . . . . . 7 73 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 9 74 2. DABBER Architecture . . . . . . . . . . . . . . . . . . . . . . 9 75 2.1. Assumptions and Requirements . . . . . . . . . . . . . . . 10 76 2.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 2.3. LSA Dissemination . . . . . . . . . . . . . . . . . . . . . 12 78 2.4. Multiple path Computation . . . . . . . . . . . . . . . . . 14 79 2.4.1. Name Prefix Validity Computation . . . . . . . . . . . 14 80 2.4.2. Update of DABBER internal information . . . . . . . . . 16 81 2.4.2. Update of RIB of the local NFD . . . . . . . . . . . . 17 82 2.5. Packet Forwarding . . . . . . . . . . . . . . . . . . . . . 17 83 2.6. Loop Prevention . . . . . . . . . . . . . . . . . . . . . . 18 84 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 18 85 3.1. Overall Operation Example . . . . . . . . . . . . . . . . . 19 86 3.2. Peer Discovery and Face Setup . . . . . . . . . . . . . . . 20 87 3.3. Peer Communication Modes . . . . . . . . . . . . . . . . . 21 88 3.4. Multi-homing Wireless Communication . . . . . . . . . . . . 22 89 3.5. LSA Exchange . . . . . . . . . . . . . . . . . . . . . . . 23 90 3.6. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . 24 91 3.7. Failure and Recovery . . . . . . . . . . . . . . . . . . . 25 92 3.8. Interface towards a Contextual Agent . . . . . . . . . . . 25 93 3.9. Adjustment to data source mobility . . . . . . . . . . . . 25 94 4. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 27 95 4.1. Interoperability with NDN operation over DTNs . . . . . . . 27 96 4.2. Interoperability with NDN operation in wired networks . . . 27 97 4.2.1. Interoperability with NLSR . . . . . . . . . . . . . . 27 98 4.2.2. Interoperability with broadcast based forwarding . . . 28 99 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 28 100 5.1. Authenticity . . . . . . . . . . . . . . . . . . . . . . . 29 101 5.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . . 30 102 5.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 30 103 6. Implementation and Deployment Experience . . . . . . . . . . . 31 104 6.1 Improvement of Network Service Discovery . . . . . . . . . 31 105 6.1.1. Peer Registration Service . . . . . . . . . . . . . . . 32 106 6.1.2. Peer Announcement Service . . . . . . . . . . . . . . . 32 107 6.1.3. Leader Service . . . . . . . . . . . . . . . . . . . . 32 108 6.1.4. Disconnect Detector Service . . . . . . . . . . . . . . 33 109 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 33 110 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 33 111 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 112 9.1 Normative References . . . . . . . . . . . . . . . . . . . 34 113 9.2 Informative References . . . . . . . . . . . . . . . . . . 34 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 116 1. Introduction 118 In a networking scenario where an increasing number of wireless 119 systems, such as end-user nodes and mobile edge nodes, are being 120 deployed, there are two networking paradigms that are highly 121 correlated to the efficiency of pervasive data sharing: Information- 122 Centric Networking (ICN), and opportunistic wireless networking. The 123 latter concerns the capability of exploiting any potential wireless 124 communication opportunity to exchange data in a multi-hop wireless 125 networks, where it is difficult to find an end-to-end path between 126 any pair of nodes at any moment in time. 128 Combining opportunistic networking with ICN principles is relevant to 129 efficiently extend the applicability of information-centric 130 networking to novel scenarios, such as affordable pervasive access; 131 low cost extension of access networks; edge computing; vehicular 132 networks. 134 This document describes the Data reAchaBility BasEd Routing (DABBER) 135 routing protocol for information-centric wireless opportunistic 136 networks [24]. These networking architectures are operationally 137 located on the Internet fringes (Customer Premises). In such areas, 138 networking experiences intermittent connectivity and variable 139 availability of nodes due to their movement and/or due to other 140 constrains, e.g., limited battery, storage, and processing. 142 DABBER has been therefore designed to be compatible with the routing 143 deployed within ICN access networks. Its main purpose is to assist in 144 extending the reach of multi-hop transmission to opportunistic 145 environments, in a seamless and fully interoperable way. 147 It is our understanding that routing in such wireless environments 148 needs to be done based on strategies that take into consideration, at 149 a network level, the context of wireless nodes, and not just the 150 history of contacts among wireless nodes. The goal is to assist in 151 better defining opportunities for the transmission of Interest 152 packets over time and space. Such opportunities can be better 153 addressed if routing metrics take into consideration, as common in 154 opportunistic environments, measures of centrality, as well as 155 measures of node and data availability. 157 Being NDN[1][2][8] a well established ICN framework, the first step 158 proposed by this draft is to consider the current de facto NDN 159 routing, Named-data Link State Routing protocol (NLSR)[19][20], in a 160 way that allows the benefits of link-state approaches, while 161 delimiting its downsize in the context of the wireless medium. 163 Although DABBER specification allows an easier integration with NDN 164 access networks based on NSLR (e.g. the messaging systems based on 165 the synchronization of LSA is the same), its operation is completely 166 independent of NSLR. This means that DABBER can be used in any 167 isolated wireless opportunistic network, or by any wireless node that 168 frequently attaches to fix NDN networks (e.g. by using a Wi-Fi link), 169 which do not have NLSR as their routing protocol. 171 DABBER is intended as complementing existing forwarding protocols for 172 opportunistic networks (e.g., Prophet [12], Scorp [13], dLife 173 [14][18], BubbleRap [15]). 175 1.1. Contextual Aspects 177 Prior art in forwarding solutions for opportunistic networks showed 178 that data transmission in such wireless environments needs to be done 179 based on strategies that take into consideration, at a network level, 180 the context of wireless nodes, and not just the history of contacts 181 among wireless nodes. 183 This section provides an example on how to obtain contextual 184 information that defines the availability and centrality of a 185 wireless node, based on a specific operational example that is being 186 developed in the context of the H2020 UMOBILE project [6][17]. 188 Contextual information is obtained in a self-learning approach, by 189 software-based agents running in wireless nodes, and not based on 190 network wide orchestration. Contextual agents are in charge of 191 computing node and link related costs concerning availability and 192 centrality metrics. Contextual agents interact with DABBER via well- 193 defined interfaces. This to say that the contextual self-learning 194 process is not an integrating part of the routing plane, as it would 195 add additional complexity to the simplified routing plane of NDN. 197 The contextual agent (named Contextual Manager, CM [7]) installed in 198 each wireless node can therefore be seen as an end-user background 199 service that seamlessly captures wireless data to characterize the 200 affinity network (roaming patterns and peers' context over time and 201 space) and the usage habits and data interests (internal node 202 information) of a node. Data is captured directly via the regular MAC 203 Layer (e.g., Wi-Fi, Bluetooth, LTE) as well as via native 204 applications for which the user configures interests or other type of 205 personal preferences. For instance, an application can request a one- 206 time configuration of categories of data interests (e.g., music, 207 food). 209 Based on the defined interface (cf. section 3.6), DABBER is able of 210 querying the local Contextual Manager about the characteristics of 211 neighbor nodes, based on three types of information: i) Node 212 availability (metric A); ii) Node centrality (metric C); iii) Node 213 similarity (metric S). 215 Node Availability (A) gives an estimate of the node availability 216 based on the usage of internal resources over time and space, such as 217 the time spent per application category (e.g. per day), as well as 218 the usage of physical resources (battery status; CPU status, etc). 220 Node Centrality (C) provides awareness about the node's affinity 221 network neighborhood context. For instance, the more visited networks 222 a node has over a period of time, the more central a node is 223 (increases the possibility for data transmission); The higher the 224 number of connections a node has over a period of time, the more 225 central a node is; The higher the node degree of node over a period 226 of time, the higher is its centrality; The lower the distances 227 traversed by the node are, the higher is its centrality. 229 Node similarity (S) provides awareness about a node's similarity 230 towards neighbor nodes, based on the assumption that the more similar 231 nodes are, the higher the probability of more robust data exchange 232 between those nodes. This metric relies on a cosine similarity to 233 provide a link cost between peer nodes. In the case of DABBER, 234 similarity is computed based on the number of encounters between peer 235 nodes and the average duration of such encounters. 237 The detailed specification of the contextual manager is out of scope 238 of this document. Nevertheless, code for such an agent is being 239 provided openly in the context of the H2020 UMOBILE project [7]. What 240 is relevant to have in mind, from a routing perspective, is that this 241 contextual plane provides weights (A, C and S) to assist the routing 242 protocol in ranking next hops, which is an aspect highly relevant in 243 the context of multiple path routing. We believe that contextual 244 awareness can assist NDN routing schemes in better dealing with 245 topological variability, by anticipating changes derived from prior 246 learning. 248 1.2. Applicability 250 DABBER is being developed to allow the deployment of wireless NDN 251 networks where nodes and links can be intermittently available, such 252 as in the case of emergency situations [25]. From an end-to-end 253 perspective we can consider two scenarios: the NDN wireless network 254 is at the fringes of the NDN core; the NDN wireless network can 255 interconnect different NDN fixed networks. 257 While the latter may support applicability scenarios typical of 258 Delay-Tolerant Networks (DTN)[21][22] for instance tunneling traffic 259 over an area lacking network deployment, the former allows the 260 extension of the applicability of information-centric networking to 261 novel scenarios such as affordable pervasive data access, low cost 262 extension of access networks, edge computing, and vehicular networks: 264 Affordable pervasive data access: 265 This scenario encompasses the implementation of NDN in personal 266 mobile nodes (e.g. smartphones) allowing users to share data and 267 messaging services by exploiting existing intermittent wireless 268 connections (e.g. Wi-Fi, Wi-Fi direct) in environment without/or 269 limited Internet access. 271 Low cost extension of access networks: 272 This scenario refers to the usage of wireless nodes (mobile or 273 fix) to extend the reach of an NDN networks while reducing CAPEX 274 costs. 276 Edge/Fog computing: 277 This scenario is related to the efforts being done to bring cloud 278 computing closer to the end-users. This scenario encompasses a 279 large set of heterogeneous (wireless and sometimes autonomous) 280 decentralized nodes able of communicating, directly or via an 281 infrastructure, in order to perform storage and processing tasks 282 without the intervention of third parties. This scenario deals 283 with nodes that might not be continuously connected to a network, 284 such as laptops, smartphones, tablets and sensors, as well as 285 nodes that may be intermittently available due to scarce 286 resources, such as wireless access routers and even Mobile Edge 287 Computing (MEC) servers. 289 V2X networks: 290 This scenario deals with the intermittent connectivity between 291 vehicles as well as between vehicles and the infrastructure. 293 1.3. NFD Adjustment to Opportunistic Networks 295 The main functionality of the Named-Data Networking Forwarding Daemon 296 (NFD) [7] is to forward Interest and Data packets. This section 297 provides a set of design considerations that need to be considered to 298 allow the operation of NFD in opportunistic wireless networks. Such 299 considerations have been implemented in a new branch of NDN, called 300 NDN-OPP [3], which code of available on GitHub 301 (https://github.com/COPELABS-SITI/ndn-opp). 303 NDN-OPP introduces a few modifications in the way NFD performs its 304 forwarding, by leveraging the concept of Faces in order to adapt the 305 operation of the NFD to the intermittent property of wireless 306 connections. This is done by the implementation of a new type of 307 face, called Opportunistic Face - OPPFace. 309 Each OPPFace is based on a system of packet queues to hide 310 intermittent connectivity from NFD: instead of dispatching packets 311 from the FIB, the OPPFace is able of delaying packet transmission 312 until the wireless face is actually connected. OPPFaces are kept in 313 the Face Table of the forwarder and their state reflects the wireless 314 connectivity status: they can be in an Up or Down state, depending 315 upon the wireless reachability towards neighbor nodes. Since packet 316 queuing is concealed inside OPPFaces, no other part of the NFD or any 317 existing forwarding strategy needs to be changed. 319 OPPFaces can be implemented by using any direct wireless/cellular 320 communication mode (e.g., Ad-Hoc Wi-Fi, Wi-Fi Direct, D2D LTE, DTN). 322 The current operational version of NDN-OPP (V1.0) makes usage of 323 group communications provided by Wi-Fi Direct. In this case there is 324 a one-to-one correspondence between an OPPFace and a neighbor node. 325 In this peer-to-peer scenario, OPPFaces can be used in two 326 transmission modes: connection-oriented, in which packets are sent to 327 a neighbor node via a reliable TCP connection over the group owner; 328 connection-less, in which packets are sent directly to a neighbor 329 node during the Wi-Fi direct service discovery phase. In the latter 330 case data transmission is limited to the size of the TXT record (900 331 bytes for Android 5.1 and above). 333 In the peer-to-peer scenario of Wi-Fi direct, DABBER operates as 334 follows: routing information is shared among all members of a Wi-Fi 335 direct group, while Interest Packets are forwarded to specific 336 neighbors. With Dabber it is the carrier of an Interest packet that 337 decides which of the neighbors will get a copy of the Interest 338 packet. Hence, with the current implementation of NDN-OPP, DABBER 339 places a copy of the Interest packet in the OPPFaces of selected 340 neighbors. In what concerns the dissemination of routing information, 341 it is ensured by: i) node mobility, meaning that nodes carry such 342 information between Wi-Fi direct groups; ii) information is passed 343 between neighbor groups via nodes that belong to more than one group. 345 In a scenario where NDN-OPP would have OPPFaces implemented based on 346 a broadcast link layer, such as ad-hoc Wi-Fi, only one OPPFace would 347 be created in each node. Such OPPFace would be used to exchange 348 packets with any neighbor node, making use of the overhearing 349 property of the wireless medium. Since with DABBER, it is the carrier 350 that decides which of the neighbors are entitle to get a certain 351 Interest packet, DABBER would need to encode in the Interest packet 352 information about the ID of the neighbors that should process the 353 overheard Interest packet. 355 This means that the operation of DABBER is the same independently of 356 the nature of the link layer protocol, the only different being the 357 number of transmissions that needs to be done at the link layer to 358 forward Interest packets and to disseminate routing information. 360 Besides the OPPFaces towards neighbor wireless nodes, NDN-OPP makes 361 use of the Wi-Fi Face, already defined in NFD, and will integrate the 362 DTN Face developed in the UMOBILE project[23]. This means that DABBER 363 is able of exploiting any available wireless Face (OPPFace, Wi-Fi 364 Face, DTN Face). Future versions of NDN-OPP will allow DAGGER to 365 exploit interfaces to other wireless access networks, such as LTE. 367 A detailed specification of NDN-OPP and OPPFaces can be found in [3]. 368 In the remainder document we will refer to OPPFaces, Wi-Fi Faces and 369 DTN Faces simply as Faces. 371 1.4. Conventions 373 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 374 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 375 document are to be interpreted as described in RFC 2119. In this 376 document, these words will appear with that interpretation only when 377 in ALL CAPS. Lower case uses of these words are not to be interpreted 378 as carrying significance described in RFC 2119. 380 2. DABBER Architecture 382 This section presents an overview of the overall DABBER protocol 383 architecture. The three major considerations to architect DABBER are: 385 i) In opportunistic networks it is not possible to know the 386 complete network topology. Hence, there is no need to disseminate 387 Adjacency information. 389 ii) In opportunistic networks it is not efficient to flood the 390 network, as shown by all prior solutions based on controlled 391 packet replication forwarding ([12][13][14][18][15]) instead of 392 broadcast as used in Epidemic routing. 394 iii) Selecting the best set of neighbors to replicate packets to, 395 may not be efficient if based only on connectivity based 396 information (e.g. inter-contact times, contact duration). 398 DABBER relies on the same message formats, message exchange process, 399 and same data structures (RIB and FIB), made available by NDN, and 400 used by NLSR. As shown in figure 1, both protocols are able of 401 populating the FIB with a list of next hops towards each name prefix. 402 This is done based on the information collected from neighbor nodes 403 and stored in the RIB. 405 Node A Node B 406 +----------+ +------------+ 407 N - |1 2| - N----- |1 2| 408 | | | | 409 |3 4| - N |3 4| 410 +----------+ | +------------+ 411 | Node C 412 | +------------+ 413 ------ |1 2| 414 | | 415 |3 4| 416 +------------+ 418 RIB FIB 419 +----------------------------+ +-----------------------+ 420 |Prefix Name | Face | Cost | | Prefix Name | Faces | 421 +----------------------------+ +-----------------------+ 422 | N | 2 | 3 | | N | 2,1,4 | 423 | N | 4 | 10 | | | | 424 | N | 1 | 5 | +---------------------- + 425 +----------------------------+ 427 Figure 1: RIB and FIB Management, node A. 429 However, NLSR needs to build a full network topology, based on 430 Adjacency Link State Advertisements (LSA), to compute shortest paths 431 towards each node in the network (based on a simple extension of the 432 Dijkstra's algorithm). After this, NLSR computes shortest paths 433 towards each data source by associating each router with name 434 prefixes, based on the information exchanged via Prefix LSAs. Such 435 name prefixes are ordered in the FIB based on the distance of the 436 path towards the data source (shortest first). 438 While NLSR relies on the dissemination of Adjacency and Prefixes 439 LSAs, DABBER only requires the dissemination of Prefix LSAs and does 440 not require the computation of shortest paths: DABBER replaces the 441 path cost used by NSLR with a data reachability cost, as described in 442 section 2.4, reducing the impact that topological changes would have 443 on the stability of routing information. 445 The computation of data reachability costs towards different data 446 sources, based on the local dissemination of name prefixes, aims to 447 avoid flooding the wireless network with Interest packets that would 448 otherwise be broadcast to all potential data sources. 450 2.1. Assumptions and Requirements 451 DABBER relies on the following assumptions: 453 o Mobile nodes are able of exploiting wireless connectivity. For 454 instance having NDN-OPP installed. 456 o Mobile nodes can be a source and destination of data, being able 457 of operating as a router: there is not a clear distinction, in 458 terms of routing process, between sources, destinations, and 459 routers. 461 In terms of requirements: 463 o LSAs must be exchanged based on Interest / Data messages, as in 464 NSLR. 466 o A synchronization mechanism should be used to exchange LSAs 467 among neighbor node, as in NSLR. 469 o LSAs should be used to distribute only name prefix reachability, 470 since building a network topology based on adjacency information 471 is not feasible in an opportunistic network. 473 o Multiple next-hops for each name prefix must be computed based 474 on local information that encodes data reachability. 476 o Link failure recovery must be local and hence, the recovery 477 process should be based on the operation of OPPFaces (UP/Down link 478 management). 480 o IP addresses or any other form of addressing a node in the 481 network must not be considered, as in NLSR. 483 o Selective information diffusion must be considered, in order to 484 avoid network flooding. 486 o Data sources must set the validity of name prefixes - validity v 487 - as an integer that represents the expiration date of the data. 489 2.2. Naming 491 DABBER makes use of NDN hierarchical naming scheme to identify each 492 wireless node. This strategy is similar to the one used by NLSR. The 493 difference is in the name semantics: being a routing protocol for 494 wired networks, NLSR uses names that reflect network structures and 495 operational practices, making it easy to identify routers belonging 496 to the same network, and operator realms. In NLSR each router is 497 named according to the network it resides in, the specific site it 498 belongs to, as well as an assigned router name, i.e., 499 ///. For example, /ATT/AtlantaPoP1/router3. 500 This semantics provide additional topological information to the 501 routing process. 503 With DABBER, we assume that DABBER is installed in mobile devices 504 (e.g. smartphones), which have a contract with a mobile operator. In 505 a networking environment, a hierarchical naming scheme still makes 506 sense to identify to which network operator does the mobile node 507 belongs to and to the home site, in case the mobile operator has more 508 than one operational site. This naming scheme still makes sense even 509 if DABBER is only used to exchange traffic over 802.11, wifi direct 510 or 802.11 adhoc links, and never over a cellular interface. 512 Since DABBER is used to exchange data directly between mobile nodes 513 in an opportunistic networking scenario, it makes use of a 514 hierarchical naming scheme that reflects the way mobile roaming 515 works: When a mobile node is used outside its home, it attempts to 516 communicate with a visited mobile network. The visited network 517 recognizes that the node does not belong to any of its networks, and 518 checks if there is a roaming agreement between the home network and 519 one of the networks of the visited operator. If so the call is routed 520 towards an international transit network. 522 Based on the operation of a mobile network, the following semantics 523 is used to name DABBER nodes:////, 524 where represents the international transit network allowing 525 roaming services for the mobile operator; refers to the 526 operator providing the mobile service; is the network site of 527 the mobile operator where the node is registered; is the 528 mobile equipment. 530 The hierarchical name is used to implement a trust model to allow 531 nodes to verify the signature of routing messages, as described in 532 section 5. 534 The information included in the hierarchical name may be used to 535 select next hops belonging to the same operator network, or nodes 536 that have the same home network. It is assumed that an opportunistic 537 wireless network is build based on wireless direct connectivity 538 between nodes that may belong to different operators and home 539 networks, but that may have roaming patterns that allows them to have 540 frequent wireless contacts. 542 2.3. LSA Dissemination 544 DABBER runs on top of NDN, making use of Interest/Data packets to 545 exchange LSAs. This means that while IP-based routing protocols push 546 updates to other routers, DABBER nodes need to pull the updates. 547 DABBER can use any underlay communication channels (e.g., TCP/UDP 548 tunnels, Link layer TXT records) to exchange LSA information. 550 DABBER benefits from NDN built-in data authenticity: since a routing 551 update is carried in an NDN data packet and every NDN data packet 552 carries a signature, a DABBER node can verify the signature of each 553 LSA message to ensure that it was generated by the claimed origin 554 node and was not tampered during dissemination. 556 Similarly to what happens with NLSR, DABBER disseminates LSAs via a 557 data synchronization mechanism (e.g. ChronoSync [9], PartialSync 558 [10]) of the local LSDB. 560 The main differences towards NLSR are: 562 o Contrary to NLSR, DABBER does not disseminate Adjacency LSAs to 563 reflect the status of the links towards neighbor nodes. 565 o As NSLR, DABBER advertises Prefix LSAs every time a new name 566 prefix is added or deleted to the LSDB. However in the case of 567 DABBER, name prefixes are advertised with a cost/metric related to 568 the validity of the associated data. 570 This peer synchronization approach is receiver-driven, meaning that a 571 node will request LSAs only when it has CPU cycles. Thus it is less 572 likely a node will be overwhelmed by a flurry of updates. In order to 573 remove obsolete LSAs, every node periodically refreshes each of its 574 own LSAs by generating a newer version. Every LSA has a lifetime 575 associated with it and will be removed from the LSDB when the 576 lifetime expires. The LSA format is shown in Figure 2. 578 Prefix LSA 579 +-----------------------------------------------------------------+ 580 | LSA | Number of |Prefix 1|Cost| ... |Prefix N|Cost| Signature | 581 | Name | Prefixes | | | | | | | 582 +-----------------------------------------------------------------+ 584 Figure 2: Prefix LSA format. 586 Each LSA used by DABBER has the name 587 ////DABBER/LSA/Prefix/. The 588 LSA is increased by 1 whenever a node creates a new version 589 of the LSA. 591 A detailed description of the LSA exchange process is provided in 592 section 3.3. 594 2.4. Multiple path Computation 596 As mentioned, DABBER considers that there is a set of potential next- 597 hops via which a name prefix N can be reached with a certain cost k. 598 This cost k represents the probability of reaching a data object 599 identified by N via a Face F, and is related to the time validity of 600 the name prefix (v). The rationale for this approach is that the 601 selection of faces that have a lower cost k (higher validity v) will 602 improve data reachability. The validity of a name prefix is set by 603 the data source as an integer that represents the expiration date of 604 the data. 606 Since different nodes can announce the same name prefix, a certain 607 name prefix may be associated with different values of k (as v shall 608 differ) over different faces, depending upon the nodes announcing 609 such name prefix: this lead to the identification of multiple next 610 hops, each one with a different cost. 612 The computation of multiple next hops is performed every time DABBER 613 has a new Name Prefix LSA (or a new version of an existing Name 614 Prefix LSA) in its LSDB (c.f. section 2.3). The sequence of 615 operations, as described in the following sub-sections are: Computes 616 a new value for the validity of a new Name Prefix in the LSDB; 617 Updates DABBER internal routing table; Updates the LSDB with the data 618 reachability information (validity) of the current node towards the 619 new Name Prefix; Updates the RIB based on the DABBER internal routing 620 table, following a Downwards Path Criterion (FIB is updated by NFD 621 based on the RIB content). Periodically DABBER will update the 622 validity values of all Name Prefixes in its internal routing table, 623 performing the consequent updates of the local LSDB and RIB, and 624 needed. 626 2.4.1. Name Prefix Validity Computation 628 When DABBER is notified that a new Prefix LSA was entered in the LSDB 629 or an existing Prefix LSA has a new version, it computes a new 630 validity for each name prefix in such Prefix LSA. 632 DABBER starts by computing a new validity v for a prefix N depending 633 upon the validity announced by the neighbor, and the relevancy of the 634 "relation" between the two neighbor nodes (e.g., node A and node B). 635 The cost of the Name Prefix, passed to NFD, will then be computed as 636 an inversely proportional value to its validity. 638 The relevancy of the "relation" between two neighbor nodes can be, 639 e.g., a measure of similarity [7], where similarity is seen as a link 640 measure, i.e., it provides a correlation cost between a node and its 641 neighbors. Or such relation can be weighted based, as is common in 642 opportunistic environments, on metrics derived from average contact 643 duration thus allowing a node to adjust the Name Prefix validity 644 based on the probability of meeting the respective neighbor again. In 645 the current implementation of DABBER, the "relation" between two 646 neighbor nodes is computed based on the three metrics (A, C, and S) 647 provided by the local contextual manager, plus a metric computed by 648 DABBER itself: the time reachability. 650 The variable considered by DABBER for the computation of the validity 651 (and cost) of a Name prefix passed by a neighbor Na are: 653 o Validity (V) - Represents the expiration date of the data 654 associated with the Name Prefix. Currently it is the UNIX 655 Timestamp (10 digit integer). 657 o Similarity metric (S) towards the neighbor Na, as passed by the 658 contextual manager (S >= 0), aiming to select neighbors with whom 659 the current node has a good communication link. 661 o Availability metric (A) towards the neighbor Na, as passed by 662 the contextual manager ( 0 < A < 1), aiming to select neighbors 663 able to process Interest packets with high probability. 665 o Centrality metric (C) towards the neighbor Na, as passed by the 666 contextual manager ( C >= 0), aiming to select neighbors with high 667 probability of successfully forwarding Interest packets. 669 o Time reachability (T) which corresponds to the RTT between 670 sending an Interest packet towards the source of such Name Prefix 671 and receiving a data packet. (0 < T < 1). Currently the value of T 672 is computed as (current time when data packet of received - time 673 when Interest packet was sent) / Validity of Name Prefix. Time 674 reachability allows DABBER to select next hops that lead to closer 675 sources. 677 Neighbor table 678 +------------------------------------------------------+ 679 | Face | Status | Metric C | Metric A | Metric S | 680 +------------------------------------------------------+ 681 | 1 | UP | 6 | 0.3 | 12 | 682 | 2 | DOWN | 4 | 0.8 | 8 | 683 | 3 | UP | 1 | 0.8 | 9 | 684 +------------------------------------------------------+ 686 Figure 3: Neighbor table. 688 The values C, A and S provided by the contextual manager are stored 689 in a Neighbor Table as shown in figure 3. Since an OPPFace is created 690 by NDN-OPP (c.f. section 1.3), the table is indexed by the number of 691 faces. The higher the values of C, A and S, the most preferential a 692 neighbor is. 694 T is measured by observing the flow of Interest and Data packets. 695 Thus, the lowest the T, the most preferential a Face is. Although 696 different nodes may have a different implementation of a face ranking 697 logic, the relevancy of T in comparison to C and A should be higher, 698 since T reflects the measured delay to reach a data source, while C 699 and A are indicators of the neighbors potential as relays. 701 Based on the above mentioned metrics the Validity of a new Name 702 Prefix (V) is updated based on two operations: 703 o V' = f (V, S') = trunc (V * S'), where: 705 S' = (S - Smin) / (Smax - Smin); Smin = 0 and Smax = max (Smax, 706 C) 708 o V'' = f (V', C', A, T) = 0.3* trunc (V' * (C'+A)) + 0.7 * trunc 709 (V' * T), where: 711 C' = (C - Cmin) / (Cmax - Cmin); Where Cmin = 0 and Cmax = max 712 (Cmax, C) 714 2.4.2. Update of DABBER internal information 716 After the computation of the validity of the Name Prefix taking into 717 account the relation of the current node with the neighbor announcing 718 it (c.f. section 2.4.1), DABBER updates its internal routing table 719 and its LSDB. The information on the routing table will be used to 720 updated the RIB of the local NFD and the information of the LSDB will 721 be announced to all the neighbor by Chronosync. 723 To update the Internal routing table, DABBER adds an entry Na for the 724 Name Prefix with a validity V''. The routing table is then ordered by 725 name prefix in decreased order of validity. 727 To update its local LSDB updated with validity of current node 728 towards the Name Prefix, DABBER can use two methods: 729 o Maximal method: Name Prefix entry on current node LSA updated 730 with max (V'', current value on LSA). 732 o Average method: Name Prefix entry on current node LSA updated 733 with max ( average (cost of Name Prefix entries on local routing 734 table), current value on LSA). 736 2.4.2. Update of RIB of the local NFD 738 After computing the new value of the validity V'' of a name prefix, 739 as described in section 2.4.1, DABBER updates the RIB entry of that 740 name prefix with the face over which the Name Prefix LSA was received 741 and the new cost of such Name prefix. The cost (k) of the Name Prefix 742 is computed based on its validity as k = trunc (100/V''). 744 DABBER assigns selection logics to name prefix, such as NDN assigns 745 forwarding strategies to name prefixes. 747 There may be different available logics to choose from: 749 o Increase diversity - The new Face is included in the RIB entry, 750 if the computed cost k helps to increase diversity of the name 751 prefix. For instance the new cost k is higher than the average 752 costs already stored for that name prefix, affected by a 753 configured diversity constant. This is include all neighbors with 754 cost = trunc (100/V''), such that 1/V'' - Avr (Costs in RIB for N) 755 > X (predefined value). 757 o Downward Path Criterion - It is a non-equal cost multi-path 758 logic that is guaranteed to be loop-free. Based on the Downward 759 Path Criterion, the X faces (the maximum number X of desirable 760 faces can be defined by configuration) to be considered for a name 761 prefix include the one with the lowest cost k plus X-1 faces that 762 have a cost k lower than the cost that the current node has itself 763 to the name prefix. This is include X neighbors with cost = 764 trunc(100/V''), such that cost is the lowest value of 1/V'' or 765 cost < 1/ V. 767 o Downward Path Criterion extension - Also considers any face over 768 which the name prefix can be reached with a cost k equal to the 769 cost that the current node has itself to the name prefix. To avoid 770 packet from looping back, there is the need to add a tiebreaker, 771 which assures that traffic only crosses one direction of equal- 772 cost links. This is, include X neighbors with cost = trunc 773 (100/V''), such that cost is the lowest value of 1/V'' or cost 774 <=1/ V. 776 2.5. Packet Forwarding 778 Packets are forwarded based on the information that is stored in the 779 FIB, which is updated by the NFD when there is an update of the RIB 780 (multicast forwarding strategy used). 782 In order to support the operation of NDN in intermittently connected 783 networks, a new type of Face was added to NFD, Opportunistic Faces 784 (OPPFaces), which allows forwarded packets to be queued, being 785 dispatched as soon as a wireless channel is established. The new 786 concept of Opportunistic Faces aims to provide support for 787 intermittent communications without requiring any other changes to 788 NFD itself. This makes co-existence of the opportunistic networks 789 side-by-side with traditional communication schemes possible. 791 The implementation of the OPPFaces depends upon the specific link 792 layer protocols based on two basic policies: In the presence of a 793 peer-to-peer link layer protocol, such as Wi-Fi Direct or D2D LTE, 794 one OPPFace should be created for each wireless neighbor; In the 795 present of broadcast link layer protocols, such as Ad-Hoc Wi-Fi, a 796 unique OPPFace should be created. 798 The state of an Opportunistic Face reflects the fact that the 799 corresponding neighbor device is currently reachable in the Wi-Fi 800 Direct range. Based on this information, the Opportunistic Face 801 decides whether to simply queue the packet or attempt a transmission 802 over the associated Opportunistic Channel. 804 Based on the feedback provided by the wireless channel, the Face can 805 decide whether to remove the packet from the queue once it has been 806 passed on to its intended peer. Furthermore, the Opportunistic Face 807 integrates a mechanism to automatically flush the queue whenever the 808 Face is brought up upon detection of the corresponding peer being 809 available in the same Wi-Fi Direct Group. 811 2.6. Loop Prevention 813 Given the multi-path nature of DABBER, the incoming Face might appear 814 among the potential next-hops for a given name prefix. For this 815 reason, DABBER applies the Incoming Face Exclusion principle [11] in 816 order to prevent forwarding Interest packets back though the Face 817 them came from, thus removing two-hop loops. 819 Furthermore, in order to detect longer forwarding loops (more than 820 two hops), DABBER relies on the nonce-based detection scheme 821 available in NDN in order to drop a looping packet as soon as it is 822 received the second time. 824 In addition, DABBER considers a loop removal mechanism, which takes 825 care of disabling the Face responsible for the looping once it is 826 detected, as described in section 3.4. 828 3. Protocol Overview 829 3.1. Overall Operation Example 831 We consider the scenario in Figure 4 to assist in the protocol 832 operation overview: namely to understand to role of DABBER to allow 833 extension of NDN operation towards wireless dynamic networks. In 834 Figure 4, nodes A, B, and C reside in an opportunistic network and 835 run DABBER, while nodes E and F are wireless edge routers running 836 another NDN routing/forwarding protocol, such as NLSR. G is a 837 wireless node running DABBER. 839 +--------------------+ 840 | +---+ | 841 | | B | . | 842 | +---+ .2+---+ | +---+ +---+ +---+ 843 |+---+ | C |3 ... | E |....| F |....| G | 844 || A |.......1+---+ | +---+ +---+ +---+ 845 |+---+ | 846 +--------------------+ 848 Figure 4: End-to-end operational example. 850 In our example, Node A starts producing some content derived, for 851 instance, from the use of an application (such as a data sharing 852 application). The produced content is stored in its local Content 853 Store with the name /NDN/video/Lisbon/nighview.mpg. Node B stores in 854 its Content Store a data object with name 855 /NDN/video/Lisbon/river.mpg, which node B received from a neighbor 856 (meaning that B have already synchronize its LSDB with such a 857 neighbor). 859 Due to the update of the Content Store, the name prefix 860 /NDN/video/Lisbon/ is stored in the LSDB of node A and B with a 861 validity of 864000 and 518400 in the case of node A and B 862 respectively. In the case of node A, the cost k of the name prefix 863 equals the validity v of the data object, e.g., v=864000 seconds (10 864 days) stipulated by the application. In the case of node B the 865 validity is the result of the computation process described in 866 section 2.4. 868 From a routing perspective, storing a name prefix in the local LSDB 869 allows the node to share the respective Prefix LSA on all its Faces, 870 excepting on the Face over which the LSA was previously received, as 871 explained in section 3.3. This LSA exchange is done when the OPPFaces 872 are up, as described in section 3.2. Node C, which got a new Prefix 873 LSA from nodes A and B, will: 875 o Update its LSDB with the Prefix LSAs received from node A and 876 node B. 878 o Update its internal routing table with two new entries for the 879 name prefix /NDN/video/Lisbon/, associated with the face towards A 880 (face1) and with the face towards B (face2), after computing the 881 values of V' and V'' for the received validity values: 883 o The validity of the name prefix is updated based on the 884 metric configured for node C: average inter-contact time. 886 o Let's assume that A and C encounter each other frequently, 887 while B and C do not meet frequently. This means that node C 888 stores 2 new entries for prefix /NDN/video/Lisbon/ in its 889 internal routing table related to face2 with a validity for A 890 higher than the one for B. 892 o Update its LSDB with the validity of the current node towards 893 the Name Prefix following the maximal or average methods (c.f. 894 section 2.4.2). 896 o Update the RIB with one new entry for the name prefix 897 /NDN/video/Lisbon/ with two faces (face 1 and face 2) with a cost 898 inversely proportional to the validity of the Name Prefix. 900 Based on the status of the FIB (updated based on the status of the 901 RIB) all interest packets that node C gets for the name prefix 902 /NDN/video/Lisbon/ will be forwards to the number of faces associated 903 to the used forwarded strategy, but respecting the ranking of faces 904 done by DABBER. 906 When node C gets in the range of router E (wireless edge router) it 907 will exchange disseminate routing information, based on some 908 interoperability issues need to be considered, as described in 909 section 4. 911 3.2. Peer Discovery and Face Setup 913 In an opportunistic network DABBER needs to manage the dynamic 914 connectivity among neighbor nodes. For this proposes the DABBER 915 protocol relies on a background process, the Connectivity Manager. 917 The current version of DABBER comes with a Connectivity Manager for 918 Wi-Fi Direct. However, such connectivity manager can be easily 919 extended to integrate other type of wireless or cellular support. The 920 description provided in this sub-section is adjusted to the case of 921 Wi-Fi Direct. 923 When booted, the Connectivity Manager starts reacting to changes in 924 the peers available within scanning range of the current node. It 925 oversees managing the connection to a Wi-Fi Direct Group and 926 automatically joins a Group if it is not part of one. 928 Upon the reception of notifications regarding changes in the peers 929 detected in the neighborhood, the Connectivity Manager updates its 930 internal peer list. If it is not currently connected to a Wi-Fi 931 Direct Group, it performs a selection heuristic to determine which 932 node to connect to. The motivation behind this selection process is 933 to attempt to minimize the number of Wi-Fi Direct Groups in a certain 934 area given that nodes can only transmit packets within the Group they 935 are currently connected to. 937 The heuristic simply favors whichever Group Owner is already detected 938 among the available peers. In the case there is exactly one Group 939 Owner, the current node attempts to join its Group. If more than one 940 or no Group Owners are available, the heuristic selects the non- 941 client node with the highest UUID. If the selected node is not the 942 current node, a connection is attempted. This heuristic guarantees 943 that the current node will never attempt to connect to a client, thus 944 breaking an existing Group. Also, all nodes located in an area, and 945 that have the same view of available peers, will all select the same 946 node as the Group Owner to which connection should be attempted. 948 For each node detected in a Wi-Fi Direct Group, a new instance of an 949 OPPFace is created. The status of an OPPFace tells us if the 950 connectivity link towards a specific node is up or down. Based on 951 this information, the OPPFace decides whether to simply queue packets 952 (when OPPFace is down) or flush the queue (when OPPFace is up). 954 In order to achieve this, whenever the node joins a Wi-Fi Direct 955 Group, it gets registered in the Group so that other nodes can send 956 packets to it. After this setup, all service changes detected within 957 the Group (connectivity up or down) are reflected into the Neighbor 958 Table (c.f. Figure 3). Upon disconnection from the Group, the node is 959 unregistered and the node returns to a state of waiting for a Group 960 to be joined. 962 3.3. Peer Communication Modes 964 This section describes the two communication methods implemented to 965 allow for direct communication between wireless neighbors over Wi-Fi 966 Direct: connection-oriented and connectionless. 968 The connection-oriented solution allows peers to exchange packets by 969 means of a reliable TCP connection established over the Wi-Fi direct 970 group owner. This type of communication system is used mostly for 971 large packets that may require reliable communication. The 972 connection-oriented solution requires the formation of a Wi-Fi direct 973 group by the connectivity manager. Once a device joins to the group, 974 it will receive a list containing information related to each 975 connected device. Since we are working with opportunistic networks, 976 it is common that some devices could join or leave the group 977 frequently. In order to deal with it, the group owner is also 978 responsible to keep the list of connected devices updated. 980 The connection-less communication method allows peers to exchange 981 packets directly without the establishment of any Wi-Fi direct group, 982 by exploiting the TXT records available during the Wi-Fi Direct 983 service discovery phase. This type of communication is used to 984 exchange small packets that require fast transmission (e.g. emergency 985 apps, Chronosync status messages). The connection-less solution 986 allows peers to exchange a short number of bytes without the 987 establishment of a TCP socket. To use this methodology, each device 988 has to listen to all announced UUID related with it. Every time that 989 a device needs to send a packet, it serializes the packet and starts 990 announcing it, during the service discovery exchange, over TXT Record 991 with the UUID of the destination. Android versions above 5.1 allow 992 the transfer of up to 900 bytes. 994 In order to implement a reliable connection-less solution, the 995 Connectivity Manager maintains a TXT Record for each intended 996 recipient of packets, which contains data packets and an 997 acknowledgement list. Since the sequence and order in which devices 998 probe and respond to one another is not controlled, a device might 999 perform the acknowledgement of a given packet received from a remote 1000 peer, but might receive the packet again in the next TXT Record in 1001 the event the remote peer does not successfully probes the current 1002 device to get the pending acknowledgements. 1004 The decision of using a connection-oriented or connection-less 1005 communication is based on the following reasoning: 1006 o Hypothesis 1: Packets are exchanged between two wireless peers 1007 over a reliable TCP socket is such socket already exists; 1009 o Hypothesis 2: If a TCP connection does not exist, decision is 1010 take based on packet size. The connection-less mechanism is used 1011 for fast dispatching of small packets (limited to the size if the 1012 TXT record, which depends upon the Android version; Bigger packets 1013 will require the establishment of a reliable TCP connection over 1014 the Wi-Fi direct group owner. 1016 3.4. Multi-homing Wireless Communication 1018 Although DABBER is being specified for the operation of NDN 1019 opportunistic wireless networks, wireless devices can exploit the 1020 present of Wi-Fi infrastructure connections made available by a 1021 nearby Wi-Fi Access Point. 1023 For this propose, beside using the new OPPFaces , DABBER also makes 1024 use of the Wi-Fi Face previously implemented in NFD. The Wi-Fi face 1025 may provide higher communication resilience and lower delays, as well 1026 as the possibility for wireless devices to exchange data with 1027 standard NDN devices deployed in a faraway location. 1029 Currently DABBER allows packets to be forwarded to a subset of 1030 available faces (OPPFaces, and Wi-Fi Faces). A more static 1031 alternative can be to avoid replicating Interest packets among 1032 wireless peers devices when a Wi-Fi network is available. 1034 It is expected that NDN-aware Access Points will be able to provide 1035 wireless devices with the IP address of the local NDN router within 1036 wireless beacons. In the current version this information is made 1037 available during the configuration phase. By default, the system is 1038 configured to connect to the NDN router deployed in COPELABS, but 1039 another NDN router may be selected. 1041 3.5. LSA Exchange 1043 DABBER performs the dissemination of LSAs based on a process able of 1044 synchronizing the content of LSDBs. In this sense, all LSAs are kept 1045 in the LSDB as a name set, and DABBER uses a hash of the LSA name set 1046 as a compact expression of the set. Neighbor nodes use the hashes of 1047 their LSA name sets to detect inconsistencies in their sets. For this 1048 reason, neighbor nodes exchange hashes of the LSDB as soon as 1049 OPPFaces are UP. 1051 Current version of DABBER makes use of ChronoSync as synchronization 1052 mechanism. Chronosync allows DABBER to define a collection of named 1053 data in a local repo as a slice. LSA information are synchronized 1054 among neighbor nodes, since Chronosync keeps the repo slice 1055 containing the LSA information in sync with identically defined 1056 slices in neighboring repositories. 1058 If a new LSA name is detected in a repo, ChronoSync notifies DABBER 1059 to retrieve the corresponding LSA in order to update the local LSDB. 1060 DABBER can also request new LSAs from Chronosync when resources (e.g. 1061 CPU cycles) are available. 1063 Figure 5 shows how an LSA is disseminated between two neighbor nodes 1064 A and B, when the OPPFace is UP. To synchronize the slice 1065 representing the LSDB information in the repo, ChronoSync, on each 1066 node, periodically sends Sync Interests with the hash of its LSA name 1067 set / slice (step 1). When Node A has a new Prefix LSA in its LSDB, 1068 DABBER writes it in the Chronosync slice (step 2). At this moment, 1069 the hash value of the LSA slide of node A becomes different from that 1070 of node B. As a consequence, the Chronosync in node A replies to the 1071 Sync Interest of node B with a Sync Reply with the new hash value of 1072 its local LSA slice (step 3). The Chronosync in node B identifies the 1073 LSA that needs to be synchronized and notifies DABBER about the 1074 missing LSA, and updates its LSA name set (step 4). Since DABBER on 1075 node B has been notified of the missing LSA, DABBER sends an LSA 1076 Interest message to retrieve the missing LSA (step 5). DABBER on node 1077 A sends the missing data in a LSA Data message (step 6). When DABBER 1078 on node B receives the LSA data, it inserts the LSA into its LSDB. 1079 Chronosync on nodes A and B compute a new hash for updated the set 1080 and send a new Sync Interest with the new hash (step 7). 1082 Node A Node B 1083 +----------------------------+ +----------------------------+ 1084 | +-------------+ | |+-------------+ | 1085 | DABBER | Chronosync | | || Chronosync | DABBER | 1086 | +-------------+ | |+-------------+ | 1087 +----------------------------+ +----------------------------+ 1088 | | Sync Interest (1) | | 1089 | |------------------->| | 1090 | |<-------------------| | 1091 | New LSA (2)| | | 1092 |----------> | | | 1093 | | Sync Reply (3) | | 1094 | |------------------->| | 1095 | | | Notify (4) | 1096 | | |------------->| 1097 | | LSA Interest (5) | | 1098 |<-----------|--------------------|--------------| 1099 | | LSA Data (6) | | 1100 |------------|--------------------|------------->| 1101 | | | | 1102 | | Sync Interest (7) | | 1103 | |------------------->| | 1104 | |<-------------------| | 1106 Figure 5: LSA exchange process. 1108 When more than one LSA needs to be synchronized, the issued LSA 1109 Interest packet will contain information about as many LSAs as 1110 allowed by the Link maximum transmission unit. In the same sense one 1111 LSA Data packet may include also be used to transport information 1112 about more than one LSA. 1114 3.6. Loop Avoidance 1116 In addition to the loop avoidance mechanism of NDN, DABBER considers 1117 a loop removal mechanism, which takes care of disabling the Face 1118 responsible for the looping once it is detected. 1120 3.7. Failure and Recovery 1122 As described in section 3.2, DABBER relies on a connectivity manager 1123 that is able to react to changes in the peers available within the 1124 wireless scanning range of the current node. 1126 Upon detection of a Wi-Fi Direct Group, the connectivity manager 1127 automatically joins that Group, if it is not part of one. 1129 Upon the reception of notifications regarding changes in the peers 1130 detected in the neighborhood, the Connectivity Manager updates its 1131 internal peer list. 1133 3.8. Interface towards a Contextual Agent 1135 The interface between DABBER and CM provides the former with periodic 1136 information concerning a node's centrality (C) and a node's 1137 availability (A), as well as with a similarity weight (S) between 1138 peers (link relevancy). 1140 This interface integrates premises to perform specific requests to 1141 get the computed values C and A for a list of peers provided by 1142 DABBER. The peers are identified by hashed MACs. 1144 The interface integrates also a premise to provide a similarity 1145 weight (S) between two peers passed by DABBER to the CM. For 1146 instance, if DABBER requests similarity between node A (sender) and 1147 node B (potential successor), then the CM computes similarity for 1148 both nodes based on a specific period of time. Such analysis can 1149 assist in a better selection of peers for data transmission, for 1150 instance. 1152 3.9. Adjustment to data source mobility 1154 As NDN uses a publish/subscribe communication model, where request 1155 resolution and data transfer are decoupled, it is especially relevant 1156 to solve the problem of data source mobility. Supporting data source 1157 mobility requires, first of all, finding the new location of the 1158 source each time data sources move, and, second, updating the name 1159 resolution system according to the new location, in order to maintain 1160 the consistency of NDN forwarding. 1162 This sub-section described a new feature of DABBER which follows a 1163 new reactive approach to face the challenges of the data source 1164 mobility and consistent forwarding in Mobile ICNs. To this end, 1165 DABBER is using the efficient dissemination method for Opportunistic 1166 Networks [26] to efficiently discover data sources by replicating 1167 Interest messages in an efficient way that avoids network flooding. 1169 With this new feature the prospective forwarders for a given Interest 1170 message (which are denoted as discoverers) are limited in number and 1171 carefully selected in terms of three criteria: 1173 o Centrality: how well connected a node is in the network. The 1174 more central a node is, the bigger the chances are to find a data 1175 source. 1177 o Reliability: the likeliness a node does not drop messages. The 1178 more reliable a node is, the least probable is that the Interest 1179 message will be discarded. 1181 o Similarity: how alike the contacted candidate node is in terms 1182 of shared acquaintances. The less similar, the more likely is that 1183 it will find different nodes in the future. 1185 A combination of these three criteria defines a reward function 1186 (discoverer suitability) of an Optimal Stopping (OS) problem. If a 1187 node finds a new node with a certain value for the discoverer 1188 suitability it is difficult to know whether this value is a good one 1189 when compared with what a node could find in future contacts. This 1190 decision is not trivial: if a node chooses early-contacted discoverer 1191 candidates, good results are not guaranteed because selected 1192 discoverers could have a low discoverer suitability metric. On the 1193 other end of the spectrum, selecting late-contacted discoverer 1194 candidates does not guarantee either good discoverer nodes since it 1195 is likely that good candidates with high discovery suitability values 1196 would be skipped. 1198 DABBER is so extended with the ability to perform an OS-based 1199 strategy that allows nodes to select the most suitable node among all 1200 of the contacted ones to forward the Interest message. This strategy 1201 relies on the existence of an optimal set of stopping values such 1202 that the nth discoverer node for a certain Interest message is the 1203 first contacted node which is the best of all the previously explored 1204 nodes, if the node has contacted the first stopping value. If this 1205 node is not found, then it will be the first node which is the second 1206 best of all the previous nodes, if the node has contacted the second 1207 stopping value, and so on. Otherwise, if these nodes are not found, 1208 then, the nth discoverer node will be the last nth node before 1209 reaching the last contacted node. This makes the dissemination of the 1210 Interest messages in Mobile NDNs efficient, even, and pervasive all 1211 over the network, increasing the delivery ratio while decreasing the 1212 network overhead. 1214 4. Interoperability 1216 As mentioned in section 1.2 DABBER is being developed to allow the 1217 deployment of wireless NDN networks where nodes and links can be 1218 intermittently available. In this section we analyze the 1219 interoperability of DABBER in two scenarios: the NDN wireless network 1220 is at the fringes of a wired NDN core; the NDN wireless network can 1221 interconnect topologically separated NDN networks or hosts, via a 1222 DTN. 1224 4.1. Interoperability with NDN operation over DTNs 1226 In this sub-section, we review the deployment of DABBER over existing 1227 DTNs. We only consider deployment scenarios where NDN is deployed as 1228 an overlay over a DTN. In this case, the existing DTN infrastructure 1229 and implementation are leveraged to extend NDN operation in 1230 challenged networks. We consider scenarios such as data mulling, 1231 services to remote locations, and interconnecting different NDN hosts 1232 (fixed or mobile)[23]. 1234 In such challenged network topologies, OPPFaces may not be able to 1235 cope well with long delays or disruption due to frequent 1236 disconnections and node mobility, severely hampering network 1237 operations. A DTN face integrated into NDN-OPP provides the latter 1238 with a robust communications platform supporting communications in 1239 these conditions, by providing the option to propagate Interests to, 1240 and return Data from, remote NDN hosts or networks. These are assumed 1241 to typically reside in access points and wireless edge routers, or 1242 mobile devices and have a corresponding DTN face implementation. 1244 DABBER will employ the DTN face, either in a hop-by-hop or a multi- 1245 hop fashion, when it senses, through the connectivity manager, that 1246 the OPPFaces do not provide a high probability of successful data 1247 delivery (e.g. Time-to-completion is too high). As DTN faces operate 1248 as regular faces, multiple path computation is performed using the 1249 procedure described in section 2.4. 1251 4.2. Interoperability with NDN operation in wired networks 1253 In this sub-section we analyze the interoperability of DABBER with 1254 two potential configurations of an NDN access network based on: a 1255 routing protocol able of disseminating name prefix information, such 1256 as NLSR; a broadcast based forwarding approach. 1258 4.2.1. Interoperability with NLSR 1260 The LSA dissemination mechanism described in section 3.3 is used to 1261 ensure interoperability with NLSR. Such mechanism ensures the 1262 interoperability between a DABBER node and a NLSR edge router, since 1263 the specification used by DABBER follows the same message structure 1264 and sequence of the mechanism used by NLSR [19][20]. 1266 However, when DABBER is executing the LSA dissemination procedure 1267 over a Wi-Fi face (towards a NLSR edge router), the following updates 1268 to the procedure described in section 3.3 need to be done in order to 1269 account for the changes between DABBER and NLSR as stated in section 1270 2.3: 1271 o DABBER will ignore all notifications that Chronosync will send 1272 related to Adjacency LSAs. 1274 4.2.2. Interoperability with broadcast based forwarding 1276 Broadcast-based forwarding is a common mechanism in the design of 1277 some networks, such as switched Ethernet and mobile ad-hoc networks. 1278 In NDN networks this means that NFD broadcasts Interest packets that 1279 do not match an entry in the FIB, inserting then into the FIB the 1280 forwarding path learned through observation of Data return paths. The 1281 main challenge in broadcast based forwarding schemes is the prefix 1282 granularity problem: determine the name prefix of an inserted FIB 1283 entry from the Data name. Several solutions exist [16], including the 1284 announcements of name prefixes, as done by DABBER. 1286 In any case DABBER interoperability with such NDN networks relies on 1287 the following considerations: 1289 o When in contact with a wireless edge router, DABBER always 1290 forward Interest packet towards the Wi-Fi Face, even when the 1291 Interest packet does not match an entry in the FIB. o Interest 1292 packets received from a wireless edge router will not be 1293 broadcast. Interest packets will be forwarded if they match an 1294 entry in the FIB, or dropped otherwise. 1296 5. Security Considerations 1298 DABBER follows the NDN security framework built on public-key 1299 cryptography, allows it to secure the exchange of routing messages, 1300 by being able of verifying the authenticity of routing messages, and 1301 ensuring the needed levels of confidentiality. Moreover, DABBER 1302 ensures the right level of privacy of the involved entities, who 1303 provide local information to support routing decisions. 1305 Routing security can be achieved not only by signing routing 1306 messages, but also by allowing the usage of multiple paths, as done 1307 by DABBER: when an anomaly is detected routers can retrieve the data 1308 through alternative paths. 1310 Besides the presented security and privacy considerations, the issue 1311 of Denial of Service (DoS) needs to be properly addressed. An example 1312 is when a malicious user sends a high rate of broadcast messages 1313 aiming to exhaust available forwarding resources. 1315 The remaining of this section provides initial insights about the 1316 methods used by DABBER to ensure the authenticity, confidentiality of 1317 the routing message exchange as well as the privacy of the involved 1318 entities. 1320 5.1. Authenticity 1322 As happens with NLSR, DABBER routing messages are carried in NDN data 1323 packets containing a signature. Hence, a DABBER node can verify the 1324 signature of each routing message to ensure that it was generated by 1325 the claimed origin node and was not tampered with during 1326 dissemination. For this propose, DABBER makes use of a hierarchical 1327 trust model for routing, as used by NLSR within a single domain, to 1328 verify the keys used to sign the routing messages. 1330 Following the name structure described in section 2.2, DABBER models 1331 the trust management as a five-level hierarch, as in NLSR, although 1332 reflecting a different administrative structure: represents 1333 the authority responsible by the international transit network 1334 allowing roaming services; represents the operator 1335 providing the mobile service; represents the network site of 1336 the mobile operator where the node is registered; represents 1337 the mobile equipment. Each node can create a DABBER process that 1338 produces LSAs. 1340 With this hierarchical trust model, one can establish a chain of keys 1341 to authenticate LSAs. Specifically, a LSA must be signed by a valid 1342 DABBER process, which runs on the same node where the LSA was 1343 originated. To become a valid DABBER process, the process key must be 1344 signed by the corresponding node key, which in turn should be signed 1345 by the registered home network of the network operator. Each home 1346 network key must be signed by the operator key, which must be 1347 certified by the network authority using the network key, which is 1348 called trust anchor in NDN. 1350 Since keys must be retrieved in order to verify routing updates, 1351 DABBER allows each node to retrieve keys from its neighbors. This 1352 means that a DABBER node will use the NDN Interest/Data exchange 1353 process to gathers keys from all its direct neighbors. Upon the 1354 reception of an Interest of the type //broadcast/KEYS each 1355 neighbor looks up the requested keys in their local key storage and 1356 return the key if it is found. In case a neighbor does not have the 1357 requested key, the neighbor can further query its neighbors for such 1358 key. The used key retrieval process makes use of a broadcast 1359 forwarding strategy, stopping at nodes who either own or cache the 1360 requested keys. 1362 5.2. Confidentiality 1364 Although being deployed under the control of an operator, DABBER 1365 allows its network to be extended beyond the reach of its 1366 infrastructure network, into scenarios where wireless communications 1367 between involved DABBER devices/router may be spoofed. Hence, DABBER 1368 requires routing data confidentiality to ensure the setup of a secure 1369 communication topology. 1371 DABBER basic approach relies on the usage of encryption to protect 1372 the confidentiality of routing messages. By taking advantage of the 1373 semantically meaningful NDN names DABBER relies on approaches such as 1374 named-based access control (NAC)[27]. NAC provides content 1375 confidentiality and access control based on a combination of 1376 symmetric and asymmetric cryptography algorithms, while using NDN's 1377 data-centric security and naming convention to automate data access 1378 control. 1380 Being implemented in wireless devices that may energy constraint, it 1381 will be important to verify the efficiency of the cryptographic 1382 solution, namely since the generation of asymmetric key pairs as well 1383 as the symmetric and asymmetric encryption/decryption operations may 1384 be expensive in terms of the usage of resources. devices. 1386 5.3. Privacy 1388 In DABBER, forwarding decisions are taken into account using 1389 different metrics such as centrality and similarity. While these 1390 metrics may be efficient in terms of node selection, they can breach 1391 privacy of network users carrying networked devices by inferring 1392 social related information such as position inside groups, as well as 1393 information about the devices themselves. 1395 If exchanged as clear text, the information carried in routing 1396 metrics may potentially compromising the privacy of users. A way of 1397 preserving the privacy of the users in DABBER is to use NDN-P2F [28], 1398 a privacy-preserving forwarding scheme that uses homomorphic 1399 encryption for information-centric wireless Ad Hoc Networks. 1401 In, NDN-P2F, forwarding decisions are made by performing calculations 1402 on encrypted forwarding metric values without decrypting them first, 1403 while maintaining low overhead and delays. As a result, forwarding 1404 decisions can be taken preserving the user's privacy. For these 1405 purposes, homomorphic encryption is extremely useful. This 1406 cryptographic scheme allows computations on ciphertexts and generates 1407 encrypted results that, when decrypted, match the results of the 1408 operations as if they had been performed on plaintexts. 1410 There are many homomorphic cryptosystems. A good choice for DABBER 1411 can be the Paillier cryptosystem [29] because it is lightweight and, 1412 among its properties, it includes the homomorphic addition and 1413 multiplication of plaintexts and the homomorphic multiplication by a 1414 scalar. The Paillier cryptosystem, however, does not provide a way of 1415 calculating the encrypted subtraction, which is needed for metric 1416 comparisons. For these purposes, the mapping scheme proposed in [30] 1417 can be used to be able to operate with negative numbers. 1419 6. Implementation and Deployment Experience 1421 DABBER is implemented as the routing scheme for the NDN framework for 1422 Opportunistic Networks (NDN-OPP) [3]. NDN-OPP is an extension of the 1423 NDN Android implementation, aiming to support NDN communication in 1424 wireless networks by exploiting direct communication between wireless 1425 nodes, as well as intermittent Wi-Fi connectivity to the Internet 1426 (NDN global test-bed). 1428 NDN-OPP has been demonstrated in ACM ICN 2017 in Berlin [4], as well 1429 as in the NDNComm in Memphis [5]. NDN-OPP code is available in 1430 GitHub: https://github.com/COPELABS-SITI/ndn-opp 1432 6.1 Improvement of Network Service Discovery 1434 This section provides information about a set of improvements that 1435 were included in the operation of Wi-Fi Direct during the development 1436 of DABBER. Such improvements are related to the operation of the 1437 Network Service Discovery mechanism. 1439 NSD gives access to services that other devices provide on a local 1440 network. NSD implements the DNS-based Service Discovery (DNS-SD) 1441 mechanism, which allows services to be requested by specifying their 1442 type and the name of a device instance that provides the desired 1443 service. DNS-SD is supported both on Android and on other mobile 1444 platforms. 1446 NSD was also implemented on NDN-OPP, were it is responsible for 1447 detecting other devices that are using NDN-OPP via a Wi-Fi Direct 1448 network. 1450 After a set of tests, the DNS-SD library revealed some flaws: it was 1451 noticed that in some old versions of Android, sometimes devices could 1452 not get registered. This means that such devices could not be 1453 discovered. Moreover, registration and discovering processes revealed 1454 to be too slow. For that reason, NSD service should be running all 1455 the time, not only to detect new devices but also device 1456 disconnections. Once NDN-OPP deals with opportunistic communications, 1457 it should be capable of performing such processes quickly. 1459 Hence, in order to solve these issues, we developed a NSD similar 1460 implementation, based on the following guidelines: since a device 1461 joins a Wi-Fi Direct network, that device already knows the group 1462 owner's IP address. Then, we use this information to build a solution 1463 based on sockets, which has higher performance. Our solution 1464 implementation has four main components. All of them are explained in 1465 the next sub-sections. 1467 6.1.1. Peer Registration Service 1469 The registration service allows devices in a Wi-Fi group to discover 1470 NDN-OPP peers by sharing information via the group owner. When a Wi- 1471 Fi Direct connection is performed successfully, the device that 1472 performed this connection only knows the group owner's IP address. In 1473 order to be discovered, this device must advertise that it already 1474 joined the network. In order to do that, the device should make its 1475 IP address and UUID available in the group. These data is 1476 encapsulated in an NsdInfo object that is serialized and then sent 1477 over a socket to the group owner: the register service remains 1478 sending this object in configured time intervals. 1480 If the Wi-Fi Direct connection goes down, the mechanism that sends 1481 these objects stops. Then, eventually the Disconnect Detector Service 1482 classifies this device as a disconnected device. 1484 6.1.2. Peer Announcement Service 1486 This component is responsible to guarantee communications among all 1487 connected peers. In order to do that, the Discovery Service uses a 1488 socket system: when a device tries to register itself, it starts by 1489 sending, to the group owner, a NSD packet containing its personal 1490 information. The Announcement Service, which runs on the group owner, 1491 receives this packet through a socket and will notify all registered 1492 listeners. 1494 6.1.3. Leader Service 1496 This service is instantiated only by the group owner. The group owner 1497 is responsible to keep the list of connected devices consistent and 1498 updated. In order to do that, when a device joins a network and 1499 registers itself, the group owner will be notified. The Leader 1500 Service will receive the UUID and IP address of the registered device 1501 and then, if that device is not already in the list, the Leader 1502 Service will add it, and also notify all connected devices in order 1503 to keep them updated. 1505 The periodical registration requests are sent by the Register Service 1506 in order to inform the Leader Service that this device is still 1507 alive. Also a copy of these requests is sent to Disconnect Detector 1508 Service that decides when a device is considered disconnected. 1510 When a device is considered disconnected, the Disconnect Detector 1511 Service notifies the Leader Service saying that this device is 1512 considered disconnected. At that moment, the Leader Service removes 1513 that device from the list of connected devices, and notifies all 1514 connected devices. 1516 6.1.4. Disconnect Detector Service 1518 Since the group owner does not know when a device leaves the network, 1519 we developed an additional component to deal with it. The Disconnect 1520 Detector Service is responsible to define when a device is considered 1521 disconnected from the network. 1523 The Disconnect Detector Service runs periodically, incrementing a 1524 counter per each device. When this counter achieves a pre-configured 1525 number, that device is considered disconnected; The Disconnect 1526 Detector Service notifies the Leader Service that such device is 1527 disconnected. This notification is performed through onPeerLost 1528 method. 1530 The reset of this counter is performed every time the Leader Service 1531 receives a register request from that device. 1533 7. IANA Considerations 1535 This document has no actions for IANA. 1537 8. Acknowledgments 1539 The research leading to these results received funding from the 1540 European Union (EU) Horizon 2020 research and innovation programmer 1541 under grant agreement No 645124(Action full title: Universal, mobile- 1542 centric and opportunistic communications architecture, Action 1543 Acronym: UMOBILE). 1545 We thank all contributors, as well as the valuable comments offered 1546 by Lixia Zhang (UCLA) and Lan Wang (University of Memphis) to improve 1547 this draft. 1549 9. References 1551 9.1 Normative References 1553 [1] Lixia Zhang, Deborah Estrin, Jeffrey Burke, Van Jacobson, James 1554 D. Thornton, Diana K. Smetters, Beichuan Zhang, Gene Tsudik, KC 1555 Claffy, Dmitri Krioukov, Dan Massey, Christos Papadopoulos, 1556 Tarek Abdelzaher, Lan Wang, Patrick Crowley, Edmund Yeh "Named 1557 Data Networking", NDN Technical Report NDN-001, October 2010. 1559 [2] A. Afanasyev, J. Shi, B. Zhang, L. Zhang, I. Moiseenko, Y. Yu, W. 1560 Shang, Y. Li, S. Mastorakis, Y. Huang, J. P. Abraham, E. 1561 Newberry, S. DiBenedetto, C. Fan, C. Papadopoulos, D. Pesavento, 1562 G. Grassi, G. Pau, H. Zhang, T. Song, H. Yuan, H. B. Abraham, P. 1563 Crowley, S. O. Amin, V. Lehman, M. Chowdhury, and L. Wang, "NFD 1564 Developer's Guide", NDN, Technical Report NDN-0021, February 1565 2018. 1567 [3] Miguel Tavares, Paulo Mendes, "NDN-Opp: Named-Data Networking in 1568 Opportunistic Networks", Technical Report COPE-SITI-TR-18-01, 1569 January 2018. 1571 9.2 Informative References 1573 [4] Seweryn Dynerowicz, Paulo Mendes, "Named-Data Networking in 1574 Opportunistic Networks", in ACM ICN, Berlin, Germany, September 1575 2017. 1577 [5] Seweryn Dynerowicz, Omar Aponte, Paulo Mendes, "NDN Operation in 1578 Opportunistic Wireless Networks", in NDNcomm, Memphis, USA, 1579 March 2017 1581 [6] Christos-Alexandros Sarros, Sotiris Diamantopoulos, Sergi Rene, 1582 Ioannis Psaras, Adisorn Lertsinsrubtavee, Carlos Molina-Jimenez, 1583 Paulo Mendes, Rute Sofia, Arjuna Sathiaseelan, George Pavlou, 1584 Jon Crowcroft, Vassilis Tsaoussidis, "Connecting the Edges: A 1585 Universal, Mobile centric and Opportunistic Communications 1586 Architecture", IEEE Communication Magazine, February 2018 1588 [7] Rute C. Sofia, Igor Santos, Jose Soares, Sotiris Diamantopoulos, 1589 Christos-Alexandro Sarros, Dimitris Vardalis, Vassilis 1590 Tsaoussidis, Angela; d'Angelo, "UMOBILE D4.5 - Report on Data 1591 Collection and Inference Models" Technical Report, September 1592 2018. 1594 [8] NDN Project, "NFD Developer's Guide", Technical Report NDN-0021, 1595 October 2016. 1597 [9] Zhenkai Zhu and Alexander Afanasyev, "Let's ChronoSync: 1598 Decentralized Dataset State Synchronization in Named Data 1599 Networking", in Proc. IEEE ICNP, Goettingen, Germany, Oct 2013 1601 [10] Minsheng Zhang, Vince Lehman, and Lan Wang, "PartialSync: 1602 Efficient Synchronization of a Partial Namespace in NDN", NDN 1603 Technical Report NDN-0039, June 2016. 1605 [11] Klaus Schneider, Beichuan Zhang, "How to Establish Loop-Free 1606 Multipath Routes in Named Data Networking", NDN Technical Report 1607 NDN-0044, April 2017. 1609 [12] A. Lindgren, A. Doria, E. Davies, S. Grasic, "Probabilistic 1610 Routing Protocol for Intermittently Connected Networks, IETF RFC 1611 6693, Aug 2012. 1613 [13] Waldir Moreira, Paulo Mendes, Susana Sargento, "Social-aware 1614 Opportunistic Routing Protocol based on User's Interactions and 1615 Interests", in Proc. of AdhocNets, Barcelona, Spain, October 1616 2013 1618 [14] Waldir Moreira, Paulo Mendes, Susana Sargento, "Opportunistic 1619 Routing based on daily routines", in Proc. of IEEE WoWMoM 1620 workshop on autonomic and opportunistic communications, San 1621 Francisco, USA, June, 2012 1623 [15] P. Hui, J. Crowcroft, and E. Yoneki, "Bubble rap: social-based 1624 forwarding in delay tolerant networks," Mobile Computing, IEEE 1625 Transactions on, vol. 10, pp. 1576-1589, November, 2011. 1627 [16] Junxiao Shi, Eric Newberry, Beichuan Zhang, "On Broadcast-based 1628 Self-Learning in Named Data Networking", in Proc. Of IFIP 1629 Networking, Stockholm, Sweden, June 2017 1631 [17] The H2020 UMOBILE project. Grant number 645124, 2015-2018. 1632 Available via http://www.umobile-project.eu/ 1634 [18] Waldir Moreira, Paulo Mendes and Eduardo Cerqueira, 1635 "Opportunistic Routing based on Users Daily Life Routine", IETF 1637 [19] Vince Lehman, A K M Mahmudul Hoque, Yingdi Yu, Lan Wang, 1638 Beichuan Zhang, Lixia Zhang "A Secure Link State Routing 1639 Protocol for NDN", NDN Technical Report NDN-0037, January 2016. 1641 [20] Vince Lehman, Muktadir Chowdhury, Nicholas Gordon, Ashlesh 1642 Gawande, "NLSR Developer's Guide", November 2017. 1644 [21] V. Cerf, S. Burleigh, A. Hooke, L. Torgerson, R. Durst, K. 1645 Scott, K. Fall, H. Weiss, "Delay-Tolerant Networking 1646 Architecture", IETF RFC 4838, April 2007 1648 [22] K. Scott, S. Burleigh, "Bundle Protocol Specification", IETF RFC 1649 5050, November 2007 1651 [23] C.A. Sarros, A. Lertsinsrubtavee, C. Molina-Jimenez, K. 1652 Prasopoulos, S. Diamantopoulos, D. Vardalis, A. Sathiaseelan, 1653 "ICN-based Edge Service Deployment in Challenged Networks" 1654 (demo), in Proceedings of the 4th ACM Conference on Information- 1655 Centric Networking, Berlin, Germany, September 26-28, 2017 1657 [24] Paulo Mendes, Rute Sofia, Vassilis Tsaoussidis, Sotiris 1658 Diamantopoulos, Christos-Alexandros Sarros, "Information-centric 1659 Routing for Opportunistic Wireless Networks", in ACM ICN, 1660 Boston, USA, September 2018. 1662 [25] Miguel Tavares, Omar Aponte, Paulo Mendes, "Named-data Emergency 1663 Network Services", in ACM MOBISYS, Munich, Germany, June 2018. 1665 [26] Borrego, Carlos, Joan Borrell, and Sergi Robles. "Efficient 1666 broadcast in opportunistic networks using optimal stopping 1667 theory." Ad Hoc Networks 88 (2019): 5-17 1669 [27] Zhiyi Zhang, Yingdi Yu, Sanjeev Kaushik Ramani, Alex Afanasyev, 1670 Lixia Zhang, "NAC: Automating Access Control via Named Data", in 1671 Proc. of IEEE MILCOM, 2018. 1673 [28] Borrego, Carlos, et al. "Privacy-Preserving Forwarding using 1674 Homomorphic Encryption for Information-Centric Wireless Ad Hoc 1675 Networks." IEEE Communications Letters (2019). 1677 [29] Paillier, Pascal. "Public-key cryptosystems based on composite 1678 degree residuosity classes." International Conference on the 1679 Theory and Applications of Cryptographic Techniques. Springer, 1680 Berlin, Heidelberg, 1999. 1682 [30] Sanchez-Carmona, Adrian, Sergi Robles, and Carlos Borrego. 1683 "PrivHab+: A secure geographic routing protocol for DTN." 1684 Computer Communications 78 (2016): 56-73. 1686 Authors' Addresses 1687 Paulo Mendes 1688 Airbus Central Research & Technology 1689 Willy-Messerschmitt Strasse 1 1690 81663 Munich 1691 Germany 1692 Email: paulo.mendes@airbus.com 1693 URI: http://www.paulomilheiromendes.com 1695 Rute C. Sofia 1696 fortiss GmbH 1697 Guerickestrasse 25 1698 80805 Munich 1699 Germany 1700 Email: sofia@fortiss.org 1701 URI: http://www.rutesofia.com 1703 Vassilis Tsaoussidis 1704 Democritus University of Thrace 1705 University Campus 1706 69100 Komotini 1707 Greece 1708 Email: vtsaousi@ee.duth.gr 1710 Carlos Borrego 1711 Department of Information and Communications Engineering 1712 Autonomous University of Barcelona 1713 08193 Bellaterra 1714 Spain 1715 carlos.borrego@uab.cat