idnits 2.17.1 draft-mendes-icnrg-dabber-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 349 has weird spacing: '...etation only...' -- The document date (February 23, 2018) is 2252 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: '6' is defined on line 1185, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1198, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group P.Mendes 3 Internet-Draft COPELABS/University Lusofona 4 Intended Status: Experimental Rute Sofia 5 Expires: August 27, 2018 Senception/COPELABS/University Lusofona 6 Vassilis Tsaoussidis 7 Sotiris Diamantopoulos 8 Christos-Alexandros Sarros 9 Democritus University of Thrace 10 February 23, 2018 12 Information-centric Routing for Opportunistic Wireless Networks 13 draft-mendes-icnrg-dabber-00 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 August 27, 2018. 52 Copyright and License Notice 54 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . 13 79 2.4.1. Cost Computation . . . . . . . . . . . . . . . . . . . 14 80 2.4.2. RIB Update with Face Selection . . . . . . . . . . . . 14 81 2.4.3. FIB Update with Face Ranking . . . . . . . . . . . . . 15 82 2.4.4. LSDB Updates . . . . . . . . . . . . . . . . . . . . . 16 83 2.5. Loop Prevention . . . . . . . . . . . . . . . . . . . . . . 17 84 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 17 85 3.1. Overall Operation Example . . . . . . . . . . . . . . . . . 17 86 3.2. Peer Discovery and Face Setup . . . . . . . . . . . . . . . 19 87 3.3. LSA Exchange . . . . . . . . . . . . . . . . . . . . . . . 20 88 3.4. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . 21 89 3.5. Failure and Recovery . . . . . . . . . . . . . . . . . . . 21 90 3.6. Interface towards a Contextual Agent . . . . . . . . . . . 22 91 4. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 22 92 4.1. Interoperability with NDN operation over DTNs . . . . . . . 22 93 4.2. Interoperability with NDN operation in wired networks . . . 23 94 4.2.1. Interoperability with NLSR . . . . . . . . . . . . . . 23 95 4.2.2. Interoperability with broadcast based forwarding . . . 24 97 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 24 98 6. Implementation and Deployment Experience . . . . . . . . . . . 25 99 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 25 100 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 101 8.1 Normative References . . . . . . . . . . . . . . . . . . . 25 102 8.2 Informative References . . . . . . . . . . . . . . . . . . 26 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 105 1. Introduction 107 In a networking scenario where an increasing number of wireless 108 systems, such as end-user nodes and mobile edge nodes, are being 109 deployed, there are two networking paradigms that are highly 110 correlated to the efficiency of pervasive data sharing: Information- 111 Centric Networking (ICN), and opportunistic wireless networking. The 112 latter concerns the capability of exploiting any potential wireless 113 communication opportunity to exchange data in a multi-hop wireless 114 networks, where it is difficult to find an end-to-end path between 115 any pair of nodes at any moment in time. 117 Combining opportunistic networking with ICN principles is relevant to 118 efficiently extend the applicability of information-centric 119 networking to novel scenarios, such as affordable pervasive access; 120 low cost extension of access networks; edge computing; vehicular 121 networks. 123 This document describes the Data reAchaBility BasEd Routing (DABBER) 124 routing protocol for information-centric wireless opportunistic 125 networks. These networking architectures are operationally located on 126 the Internet fringes (Customer Premises). In such areas, networking 127 experiences intermittent connectivity and variable availability of 128 nodes due to their movement and/or due to other constrains, e.g., 129 limited battery, storage, and processing. 131 DABBER has been therefore designed to be compatible with the routing 132 deployed within ICN access networks. Its main purpose is to assist in 133 extending the reach of multi-hop transmission to opportunistic 134 environments, in a seamless and fully interoperable way. 136 It is our understanding that routing in such wireless environments 137 needs to be done based on strategies that take into consideration, at 138 a network level, the context of wireless nodes, and not just the 139 history of contacts among wireless nodes. The goal is to assist in 140 better defining opportunities for the transmission of Interest 141 packets over time and space. Such opportunities can be better 142 addressed if routing metrics take into consideration, as common in 143 opportunistic environments, measures of centrality, as well as 144 measures of node and data availability. 146 Being NDN[1][2] a well established ICN framework, the first step 147 proposed by this draft is to extend the current de facto NDN routing, 148 Named-data Link State Routing protocol (NLSR)[19][20], in a way that 149 allows the benefits of link-state approaches, while delimiting its 150 downsize in the context of the wireless medium. 152 DABBER is intended as complementing existing forwarding protocols for 153 opportunistic networks (e.g., Prophet [12], Scorp [13], dLife 154 [14][18], BubbleRap [15]). 156 1.1. Contextual Aspects 158 Prior art in forwarding solutions for opportunistic networks showed 159 that data transmission in such wireless environments needs to be done 160 based on strategies that take into consideration, at a network level, 161 the context of wireless nodes, and not just the history of contacts 162 among wireless nodes. 164 This section provides an example on how to obtain contextual 165 information that defines the availability and centrality of a 166 wireless node, based on a specific operational example that is being 167 developed in the context of the H2020 UMOBILE project [17]. 169 Contextual information is obtained in a self-learning approach, by 170 software-based agents running in wireless nodes, and not based on 171 network wide orchestration. Contextual agents are in charge of 172 computing node and link related costs concerning availability and 173 centrality metrics. Contextual agents interact with DABBER via well- 174 defined interfaces. This to say that the contextual self-learning 175 process is not an integrating part of the routing plane, as it would 176 add additional complexity to the simplified routing plane of NDN. 178 The contextual agent (named Contextual Manager, CM [7]) installed in 179 each wireless node can therefore be seen as an end-user background 180 service that seamlessly captures wireless data to characterize the 181 affinity network (roaming patterns and peers' context over time and 182 space) and the usage habits and data interests (internal node 183 information) of a node. Data is captured directly via the regular MAC 184 Layer (e.g., Wi-Fi, Bluetooth, LTE) as well as via native 185 applications for which the user configures interests or other type of 186 personal preferences. For instance, an application can request a one- 187 time configuration of categories of data interests (e.g., music, 188 food). 190 Based on the defined interface (cf. section 3.6), DABBER is able of 191 querying the local Contextual Manager about the characteristics of 192 neighbor nodes, based on two types of information: Node availability 193 (metric A); ii) Node centrality (metric C). 195 Node Availability (A) gives an estimate of the node availability 196 based on the usage of internal and external resources over time and 197 space. In what concerns external resources, one SHOULD consider, for 198 instance, indicators such as the preferred visited network and/or 199 location of the node; in what concerns internal resources, one SHOULD 200 consider the time spent per application category (e.g. per day), as 201 well as the usage of physical resources (battery status; CPU status, 202 etc). 204 Node centrality (C) provides awareness about a node's affinity 205 network neighborhood context. For instance, aspects such as the 206 traditional contact duration between neighboring nodes and add 207 information derived from network mining such as cluster distance, and 208 network diameter MAY be the basis for the computation of centrality. 210 The detailed specification of the contextual manager is out of scope 211 of this document. Nevertheless, code for such an agent is being 212 provided openly in the context of the H2020 UMOBILE project [7]. What 213 is relevant to have in mind, from a routing perspective, is that this 214 contextual plane provides weights (A and C) to assist the routing 215 protocol in ranking next hops, which is an aspect highly relevant in 216 the context of multiple path routing. We believe that contextual 217 awareness can assist NDN routing schemes in better dealing with 218 topological variability, by anticipating changes derived from prior 219 learning. 221 1.2. Applicability 223 DABBER is being developed to allow the deployment of wireless NDN 224 networks where nodes and links can be intermittently available. From 225 an end-to-end perspective we can consider two scenarios: the NDN 226 wireless network is at the fringes of the NDN core; the NDN wireless 227 network can interconnect different NDN fixed networks. 229 While the latter may support applicability scenarios typical of 230 Delay-Tolerant Networks (DTN)[21][22]for instance tunneling traffic 231 over an area lacking network deployment, the former allows the 232 extension of the applicability of information-centric networking to 233 novel scenarios such as affordable pervasive data access, low cost 234 extension of access networks, edge computing, and vehicular networks: 236 Affordable pervasive data access: 237 This scenario encompasses the implementation of NDN in personal 238 mobile nodes (e.g. smartphones) allowing users to share data and 239 messaging services by exploiting existing intermittent wireless 240 connections (e.g. Wi-Fi, Wi-Fi direct) in environment without/or 241 limited Internet access. 243 Low cost extension of access networks: 244 This scenario refers to the usage of wireless nodes (mobile or 245 fix) to extend the reach of an NDN networks while reducing CAPEX 246 costs. 248 Edge/Fog computing: 250 This scenario is related to the efforts being done to bring cloud 251 computing closer to the end-users. This scenario encompasses a 252 large set of heterogeneous (wireless and sometimes autonomous) 253 decentralized nodes able of communicating, directly or via an 254 infrastructure, in order to perform storage and processing tasks 255 without the intervention of third parties. This scenario deals 256 with nodes that might not be continuously connected to a network, 257 such as laptops, smartphones, tablets and sensors, as well as 258 nodes that may be intermittently available due to scarce 259 resources, such as wireless access routers and even Mobile Edge 260 Computing (MEC) servers. 262 V2X networks: 263 This scenario deals with the intermittent connectivity between 264 vehicles as well as between vehicles and the infrastructure. 266 1.3. NFD Adjustment to Opportunistic Networks 268 The main functionality of the Named-Data Networking Forwarding Daemon 269 (NFD) [7] is to forward Interest and Data packets. This section 270 provides a set of design considerations that need to be considered to 271 allow the operation of NFD in opportunistic wireless networks. Such 272 considerations have been implemented in a new branch of NDN, called 273 NDN-OPP [3], which code of available on GitHub 274 (https://github.com/COPELABS-SITI/ndn-opp). 276 NDN-OPP introduces a few modifications in the way NFD performs its 277 forwarding, by leveraging the concept of Faces in order to adapt the 278 operation of the NFD to the intermittent property of wireless 279 connections. This is done by the implementation of a new type of 280 face, called Opportunistic Face - OPPFace. 282 Each OPPFace is based on a system of packet queues to hide 283 intermittent connectivity from NFD: instead of dispatching packets 284 from the FIB, the OPPFace is able of delaying packet transmission 285 until the wireless face is actually connected. OPPFaces are kept in 286 the Face Table of the forwarder and their state reflects the wireless 287 connectivity status: they can be in an Up or Down state, depending 288 upon the wireless reachability towards neighbor nodes. Since packet 289 queuing is concealed inside OPPFaces, no other part of the NFD or any 290 existing forwarding strategy needs to be changed. 292 OPPFaces can be implemented by using any direct wireless/cellular 293 communication mode (e.g., Ad-Hoc Wi-Fi, Wi-Fi Direct, D2D LTE, DTN). 295 The current operational version of NDN-OPP (V1.0) makes usage of 296 group communications provided by Wi-Fi Direct. In this case there is 297 a one-to-one correspondence between an OPPFace and a neighbor node. 299 In this peer-to-peer scenario, OPPFaces can be used in two 300 transmission modes: connection-oriented, in which packets are sent to 301 a neighbor node via a reliable TCP connection over the group owner; 302 connection-less, in which packets are sent directly to a neighbor 303 node during the Wi-Fi direct service discovery phase. In the latter 304 case data transmission is limited to the size of the TXT record (900 305 bytes for Android 5.1 and above). 307 In the peer-to-peer scenario of Wi-Fi direct, DABBER operates as 308 follows: routing information is shared among all members of a Wi-Fi 309 direct group, while Interest Packets are forwarded to specific 310 neighbors. With Dabber it is the carrier of an Interest packet that 311 decides which of the neighbors will get a copy of the Interest 312 packet. Hence, with the current implementation of NDN-OPP, DABBER 313 places a copy of the Interest packet in the OPPFaces of selected 314 neighbors. In what concerns the dissemination of routing information, 315 it is ensured by: i) node mobility, meaning that nodes carry such 316 information between Wi-Fi direct groups; ii) information is passed 317 between neighbor groups via nodes that belong to more than one group. 319 In a scenario where NDN-OPP would have OPPFaces implemented based on 320 a broadcast link layer, such as ad-hoc Wi-Fi, only one OPPFace would 321 be created in each node. Such OPPFace would be used to exchange 322 packets with any neighbor node, making use of the overhearing 323 property of the wireless medium. Since with DABBER, it is the carrier 324 that decides which of the neighbors are entitle to get a certain 325 Interest packet, DABBER would need to encode in the Interest packet 326 information about the ID of the neighbors that should process the 327 overheard Interest packet. 329 This means that the operation of DABBER is the same independently of 330 the nature of the link layer protocol, the only different being the 331 number of transmissions that needs to be done at the link layer to 332 forward Interest packets and to disseminate routing information. 334 Besides the OPPFaces towards neighbor wireless nodes, NDN-OPP makes 335 use of the Wi-Fi Face, already defined in NFD, and will integrate the 336 DTN Face developed in the UMOBILE project[23]. This means that DABBER 337 is able of exploiting any available wireless Face (OPPFace, Wi-Fi 338 Face, DTN Face). Future versions of NDN-OPP will allow DAGGER to 339 exploit interfaces to other wireless access networks, such as LTE. 341 A detailed specification of NDN-OPP and OPPFaces can be found in [3]. 342 In the remainder document we will refer to OPPFaces, Wi-Fi Faces and 343 DTN Faces simply as Faces. 345 1.4. Conventions 346 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 347 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 348 document are to be interpreted as described in RFC 2119. In this 349 document, these words will appear with that interpretation only 350 when in ALL CAPS. Lower case uses of these words are not to be 351 interpreted as carrying significance described in RFC 2119. 353 2. DABBER Architecture 355 This section presents an overview of the overall DABBER protocol 356 architecture. The three major considerations to architect DABBER are: 358 i) In opportunistic networks it is not possible to know the 359 complete network topology. Hence, there is no need to disseminate 360 Adjacency information. 362 ii) In opportunistic networks it is not efficient to flood the 363 network, as shown by all prior solutions based on controlled 364 packet replication forwarding ([12][13][14][18][15]) instead of 365 broadcast as used in Epidemic routing. 367 iii) Selecting the best set of neighbors to replicate packets to, 368 may not be efficient if based only on connectivity based 369 information (e.g. inter-contact times, contact duration). 371 Node A Node B 372 +----------+ +------------+ 373 N - |1 2| - N----- |1 2| 374 | | | | 375 |3 4| - N |3 4| 376 +----------+ | +------------+ 377 | Node C 378 | +------------+ 379 ------ |1 2| 380 | | 381 |3 4| 382 +------------+ 384 RIB FIB 385 +----------------------------+ +---------------------+ 386 |Prefix Name | Face | Cost | | Prefix Name | Faces | 387 +----------------------------+ +---------------------+ 388 | N | 2 | 3 | | N | 1,2 | 389 | N | 4 | 10 | | | | 390 | N | 1 | 5 | +-------------------- + 391 +----------------------------+ 393 Figure 1: RIB and FIB Management, node A. 395 DABBER relies on the same message formats, message exchange process, 396 and same data structures (RIB and FIB), made available by NDN, and 397 used by NLSR. As shown in figure 1, both protocols are able of 398 populating the FIB with a list of next hops towards each name prefix. 399 This is done based on the information collected from neighbor nodes 400 and stored in the RIB. 402 However, NLSR needs to build a full network topology, based on 403 Adjacency Link State Advertisements (LSA), to compute shortest paths 404 towards each node in the network (based on a simple extension of the 405 Dijkstra's algorithm). After this, NLSR computes shortest paths 406 towards each data source by associating each router with name 407 prefixes, based on the information exchanged via Prefix LSAs. Such 408 name prefixes are ordered in the FIB based on the distance of the 409 path towards the data source (shortest first). 411 While NLSR relies on the dissemination of Adjacency and Prefixes 412 LSAs, DABBER only requires the dissemination of Prefix LSAs and does 413 not require the computation of shortest paths: DABBER replaces the 414 path cost used by NSLR with a data reachability cost, as described in 415 section 2.4, reducing the impact that topological changes would have 416 on the stability of routing information. 418 The computation of data reachability costs towards different data 419 sources, based on the local dissemination of name prefixes, aims to 420 avoid flooding the wireless network with Interest packets that would 421 otherwise be broadcast to all potential data sources. 423 Another difference towards NLSR is the face ranking in the FIB. While 424 NLSR ranks faces based only of the path distance towards the data 425 source, DABBER considers a set of local variables that characterize 426 the neighbors, and the time lapse between forwarding an Interest 427 packets and receiving the corresponding data packet, as described in 428 section 2.2.4. 430 2.1. Assumptions and Requirements 432 DABBER relies on the following assumptions: 434 o Mobile nodes are able of exploiting wireless connectivity. For 435 instance having NDN-OPP installed. 437 o Mobile nodes can be a source and destination of data, being able 438 of operating as a router: there is not a clear distinction, in 439 terms of routing process, between sources, destinations, and 440 routers. 442 In terms of requirements: 444 o LSAs must be exchanged based on Interest / Data messages, as in 445 NSLR. 447 o A synchronization mechanism should be used to exchange LSAs 448 among neighbor node, as in NSLR. 450 o LSAs should be used to distribute only name prefix reachability, 451 since building a network topology based on adjacency information 452 is not feasible in an opportunistic network. 454 o Multiple next-hops for each name prefix must be computed based 455 on local information that encodes data reachability. 457 o Link failure recovery must be local and hence, the recovery 458 process should be based on the operation of OPPFaces (UP/Down link 459 management). 461 o IP addresses or any other form of addressing a node in the 462 network must not be considered, as in NLSR. 464 o Selective information diffusion must be considered, in order to 465 avoid network flooding. 467 o Data sources must set the validity of name prefixes - validity v 468 - as an integer that represents the expiration date of the data. 470 2.2. Naming 472 DABBER makes use of NDN hierarchical naming scheme to identify each 473 wireless node. This strategy is similar to the one used by NLSR. The 474 difference is in the name semantics: being a routing protocol for 475 wired networks, NLSR uses names that reflect network structures and 476 operational practices, making it easy to identify routers belonging 477 to the same network, and operator realms. In NLSR each router is 478 named according to the network it resides in, the specific site it 479 belongs to, as well as an assigned router name, i.e., 480 ///. For example, /ATT/AtlantaPoP1/router3. 481 This semantics provide additional topological information to the 482 routing process. 484 In a wireless networking environment, a hierarchical naming scheme 485 still makes sense to identify to which network operator does the 486 mobile node belongs to and to the home site, in case the mobile 487 operator has more than one operational site. Since DABBER is used to 488 exchange data directly between mobile nodes in an opportunistic 489 networking scenario, it makes use of a hierarchical naming scheme 490 that reflects the way mobile roaming works: When a mobile node is 491 used outside its home, it attempts to communicate with a visited 492 mobile network. The visited network recognizes that the node does not 493 belong to any of its networks, and checks if there is a roaming 494 agreement between the home network and one of the networks of the 495 visited operator. If so the call is routed towards an international 496 transit network. 498 Based on the operation of a mobile network, the following semantics 499 is used to name DABBER nodes:////, 500 where represents the international transit network allowing 501 roaming services for the mobile operator; refers to the 502 operator providing the mobile service; is the network site of 503 the mobile operator where the node is registered; is the 504 mobile equipment. 506 The hierarchical name is used to implement a trust model to allow 507 nodes to verify the signature of routing messages, as described in 508 section 5. 510 The information included in the hierarchical name may be used to 511 select next hops belonging to the same operator network, or nodes 512 that have the same home network. It is assumed that an opportunistic 513 wireless network is build based on wireless direct connectivity 514 between nodes that may belong to different operators and home 515 networks, but that may have roaming patterns that allows them to have 516 frequent wireless contacts. 518 2.3. LSA Dissemination 520 As happens with NLSR, DABBER runs on top of NDN, making use of 521 Interest/Data packets to exchange LSAs. This means that while IP- 522 based routing protocols push updates to other routers, DABBER nodes 523 need to pull the updates. 525 As happens with NLSR, DABBER can use any underlay communication 526 channels (e.g., TCP/UDP tunnels, Link layer TXT records) to exchange 527 LSA information. 529 Moreover, DABBER benefits from NDN built-in data authenticity: since 530 a routing update is carried in an NDN data packet and every NDN data 531 packet carries a signature, a DABBER node can verify the signature of 532 each LSA message to ensure that it was generated by the claimed 533 origin node and was not tampered during dissemination. 535 Similarly to what happens with NLSR, DABBER disseminates LSAs via a 536 data synchronization mechanism (e.g. ChronoSync [9], PartialSync 537 [10]) of the local LSDB. 539 The main differences towards NLSR are: 541 o Contrary to NLSR, DABBER does not disseminate Adjacency LSAs to 542 reflect the status of the links towards neighbor nodes. 544 o As NSLR, DABBER advertises Prefix LSAs every time a new name 545 prefix is added or deleted to the LSDB. However in the case of 546 DABBER, name prefixes are advertised with a cost/metric related to 547 the validity of the associated data. 549 This peer synchronization approach is receiver-driven, meaning that a 550 node will request LSAs only when it has CPU cycles. Thus it is less 551 likely a node will be overwhelmed by a flurry of updates. In order to 552 remove obsolete LSAs, every node periodically refreshes each of its 553 own LSAs by generating a newer version. Every LSA has a lifetime 554 associated with it and will be removed from the LSDB when the 555 lifetime expires. The LSA format is shown in Figure 2. 557 Prefix LSA 558 +-----------------------------------------------------------------+ 559 | LSA | Number of |Prefix 1|Cost| ... |Prefix N|Cost| Signature | 560 | Name | Prefixes | | | | | | | 561 +-----------------------------------------------------------------+ 563 Figure 2: Prefix LSA format. 565 Each LSA used by DABBER has the name 566 ////DABBER/LSA/Prefix/. The 567 LSA is increased by 1 whenever a node creates a new version 568 of the LSA. 570 A detailed description of the LSA exchange process is provided in 571 section 3.3. 573 2.4. Multiple path Computation 575 As mentioned, DABBER considers that there is a set of potential next- 576 hops via which a name prefix N can be reached with a certain cost k. 577 This cost k represents the probability of reaching a data object 578 identified by N via a Face F, and is related to the time validity of 579 the name prefix (v). The rationale for this approach is that the 580 selection of faces that have a higher k will improve data 581 reachability. The validity of a name prefix is set by the data source 582 as an integer that represents the expiration date of the data. 584 Since different nodes can announce the same name prefix, a certain 585 name prefix may be associated with different values of k (as v shall 586 differ) over different faces, depending upon the nodes announcing 587 such name prefix: this lead to the identification of multiple next 588 hops, each one with a different cost. 590 The computation of multiple next hops is performed every time DABBER 591 has a new Prefix LSA (or a new version of an existing Prefix LSA) in 592 its LSDB (c.f. section 2.3). The sequence of operations, as described 593 in the following sub-sections are: Update of the RIB based on a face 594 selection criteria; Update of the FIB based on a face ranking 595 strategy; Update of the LSDB with the updated cost of the local 596 Prefix LSA. 598 2.4.1. Cost Computation 600 When DABBER is notified that a new Prefix LSA was entered in the LSDB 601 or an existing Prefix LSA has a new version, it computes a new cost 602 for each name prefix in such Prefix LSA. 604 DABBER computes a new cost k for a prefix N depending upon the cost 605 announced by the neighbor (e.g., 3 in the case of N announced by node 606 B in figure 1), and the relevancy of the "relation" between the two 607 neighbor nodes (e.g., node A and node B). 609 The relevancy of the "relation" between two neighbor nodes can be, 610 e.g., a measure of similarity [7], where similarity is seen as a link 611 measure, i.e., it provides a correlation cost between a node and its 612 neighbors. Or such relation can be weighted based, as is common in 613 opportunistic environments, on metrics derived from average contact 614 duration thus allowing a node to adjust the Name Prefix cost k based 615 on the probability of meeting the respective neighbor again. 617 2.4.2. RIB Update with Face Selection 619 After computing the new value of the cost k of a name prefix, as 620 described in section 2.4.1, DABBER updates the RIB entry of that name 621 prefix with the face over which the Prefix LSA was received based on 622 the logic assigned to that name prefix. 624 DABBER assigns selection logics to name prefix, such as NDN assigns 625 forwarding strategies to name prefixes. 627 There may be different available logics to choose from: 629 o Increase diversity - The new Face is included in the RIB entry, 630 if the computed cost k helps to increase diversity of the name 631 prefix. For instance the new cost k is higher than the average 632 costs already stored for that name prefix, affected by a 633 configured diversity constant. 635 o Downward Path Criterion - It is a non-equal cost multi-path 636 logic that is guaranteed to be loop-free. Based on the Downward 637 Path Criterion, the X faces (the maximum number X of desirable 638 faces can be defined by configuration) to be considered for a name 639 prefix include the one with the lowest cost k plus X-1 faces that 640 have a cost k lower than the cost that the current node has itself 641 to the name prefix. 643 o Downward Path Criterion extension - Also considers any face over 644 which the name prefix can be reached with a cost k equal to the 645 cost that the current node has itself to the name prefix. To avoid 646 packet from looping back, there is the need to add a tiebreaker, 647 which assures that traffic only crosses one direction of equal- 648 cost links. 650 2.4.3. FIB Update with Face Ranking 652 FIB updates are performed by selecting a certain number RIB entries 653 with a lower cost k, aiming to allow the forwarding strategy to use a 654 maximum number of next hops per name prefix. This maximum number of 655 FIB entries (F) is defined by configuration in order to control the 656 size of the FIB table in an environment where each node may have a 657 large set of neighbors, as is the case of an opportunistic network. 659 In order to increase the performance of any NDN forwarding strategy, 660 DABBER ranks the faces installed in the FIB, based on the 661 contextualization variables described in section 1.1, and a measure 662 of the distance towards the data source: 664 o Node centrality C, aiming to select neighbors with high 665 probability of successfully forwarding Interest packets; 667 o Node availability A, aiming to select neighbors able to process 668 Interest packets with high probability; 670 o Time-to-completion T, i.e., time lapse between forwarding an 671 Interest packets and receiving the corresponding data packet, 672 aiming to select neighbors closer to a data source. 674 The CM provides the values of C and A for each face, periodically or 675 on demand, every time the FIB is updated. The values provided by the 676 CM are stored in a FACE Table as shown in figure 3. The higher the 677 values of C and A the most preferential a face is. 679 Face table 680 +--------------------------------------------+ 681 | Face | Status | Metric C | Metric A | 682 +--------------------------------------------+ 683 | 1 | UP | 6 | 3 | 684 | 2 | DOWN | 4 | 12 | 685 | 3 | UP | 1 | 8 | 686 +--------------------------------------------+ 688 Figure 3: Face table. 690 T is measured by observing the flow of Interest and Data packets. 691 Thus, the lowest the T, the most preferential a Face is. Although 692 different nodes may have a different implementation of a face ranking 693 logic, the relevancy of T in comparison to C and A should be higher, 694 since T reflects the measured delay to reach a data source, while C 695 and A are indicators of the neighbors potential as relays. 697 2.4.4. LSDB Updates 699 The LSBD of a node starts by being updated every time a new Prefix 700 LSA is received from a neighbor node, as a consequence of the LSA 701 dissemination process described in section 2.3. 703 The reception of new Prefix LSA, or of new versions of existing 704 prefix LSA leads to the computation of a cost k to each name prefix 705 carried in the LSA, and the inclusion of such value in the RIB entry 706 corresponding to the respective name prefix as described in this 707 section. 709 After updating the RIB, and while populating the FIB, DABBER needs to 710 update in the LSDB its own Prefix LSA with the updated information 711 about the revised name prefix. The cost of the announced name prefix 712 is the lowest from all the RIB entries related to such name prefix. 714 Giving as example node A in Figure 1, it will include the following 715 Prefix LSA in its LSDB after the LSA dissemination with nodes B and 716 C: 717 o ///Node B/DABBER/LSA/Prefix/d1 718 including a cost of 3 for name prefix N 720 o ///Node C/DABBER/LSA/Prefix/d1 721 including a cost of 10 for name prefix N 723 After updating its RIB, node A will include the following Prefix LSA 724 in its LSDB: 726 o ///Node A/DABBER/LSA/Prefix/d1 727 including a cost of 3 for name prefix N 729 2.5. Loop Prevention 731 Given the multi-path nature of DABBER, the incoming Face might appear 732 among the potential next-hops for a given name prefix. For this 733 reason, DABBER applies the Incoming Face Exclusion principle [11] in 734 order to prevent forwarding Interest packets back though the Face 735 them came from, thus removing two-hop loops. 737 Furthermore, in order to detect longer forwarding loops (more than 738 two hops), DABBER relies on the nonce-based detection scheme 739 available in NDN in order to drop a looping packet as soon as it is 740 received the second time. 742 In addition, DABBER considers a loop removal mechanism, which takes 743 care of disabling the Face responsible for the looping once it is 744 detected, as described in section 3.4. 746 3. Protocol Overview 748 3.1. Overall Operation Example 750 We consider the scenario in Figure 4 to assist in the protocol 751 operation overview: namely to understand to role of DABBER to allow 752 extension of NDN operation towards wireless dynamic networks. In 753 Figure 4, nodes A, B, and C reside in an opportunistic network and 754 run DABBER, while nodes E and F are wireless edge routers running 755 another NDN routing/forwarding protocol, such as NLSR. G is a 756 wireless node running DABBER. 758 +--------------------+ 759 | +---+ | 760 | | B | . | 761 | +---+ .2+---+ | +---+ +---+ +---+ 762 |+---+ | C |3 ... | E |....| F |....| G | 763 || A |.......1+---+ | +---+ +---+ +---+ 764 |+---+ | 765 +--------------------+ 767 Figure 4: End-to-end operational example. 769 In our example, Node A starts producing some content derived, for 770 instance, from the use of an application (such as a data sharing 771 application). The produced content is stored in its local Content 772 Store with the name /NDN/video/Lisbon/nighview.mpg. Node B stored in 773 its Content Store a data object with name 774 /NDN/video/Lisbon/river.mpg, which node B received from a neighbor 775 (meaning that B have already synchronize its LSDB with such a 776 neighbor). 778 Due to the update of the Content Store, the name prefix 779 /NDN/video/Lisbon/ is stored in the LSDB of node A and B with a cost 780 of 864000 and 518400 in the case of node A and B respectively. In the 781 case of node A, the cost k of the name prefix equals the validity v 782 of the data object, e.g., v=864000 seconds (10 days) stipulated by 783 the application. In the case of node B the cost k is the result of 784 the cost computation process (cf. section 2.4). 786 From a routing perspective, storing a name prefix in the local LSDB 787 allows the node to share the respective Prefix LSA on all its Faces, 788 excepting on the Face over which the LSA was previously received, as 789 explained in section 3.3. This LSA exchange is done when the OPPFaces 790 are up, as described in section 3.2. Node C, which got a new Prefix 791 LSA from nodes A and B, will: 793 o Updates its LSDB with the Prefix LSAs received from node A and 794 node B. 796 o Updates its RIBs with two new entries for the name prefix 797 /NDN/video/Lisbon/, associated with the face towards A (face1) and 798 with the face towards B (face2): 800 o The cost of the name prefix is updated based on the metric 801 configured for node C: average inter-contact time. 803 o Let's assume that A and C encounter each other frequently, 804 and therefore the link cost is 0.8, while B and C do not meet 805 frequently and the link cost is 0.1. This means that node C 806 stores 2 new entries for prefix /NDN/video/Lisbon/ in its RIB 807 related to face2 with a cost of 51840 and related to face1 with 808 a cost of 691200. 810 o Update their FIBs with one new entry for the name prefix 811 /NDN/video/Lisbon/ with two faces: face 1 and face 2, since F 812 equals 4. 814 o Ranks the faces in the FIB entry as since the 815 information stored in the Face Table shows that node B is more 816 available that node A and has higher centrality. At the moment 817 there is no information about the time-to-completion. 819 o Updates its LSDB with a local Prefix LSA (as described in 820 section 2.4.4) including the name prefix /NDN/video/Lisbon/ and 821 the lowest cost that such prefix has on its RIB. 823 Based on this status of the FIB all interest packets that node C gets 824 for the name prefix /NDN/video/Lisbon/ will be forwards to the number 825 of faces associated to the used forwarded strategy, but respecting 826 the ranking of faces done by DABBER. 828 When node C gets in the range of router E (wireless edge router) it 829 will exchange disseminate routing information, based on some 830 interoperability issues need to be considered, as described in 831 section 4. 833 3.2. Peer Discovery and Face Setup 835 In an opportunistic network DABBER needs to manage the dynamic 836 connectivity among neighbor nodes. For this proposes the DABBER 837 protocol relies on a background process, the Connectivity Manager. 839 The current version of DABBER comes with a Connectivity Manager for 840 Wi-Fi Direct. However, such connectivity manager can be easily 841 extended to integrate other type of wireless or cellular support. The 842 description here provided is adjusted to the case of Wi-Fi Direct. 844 When booted, the Connectivity Manager starts reacting to changes in 845 the peers available within scanning range of the current node. It 846 oversees managing the connection to a Wi-Fi Direct Group and 847 automatically joins a Group if it is not part of one. 849 Upon the reception of notifications regarding changes in the peers 850 detected in the neighborhood, the Connectivity Manager updates its 851 internal peer list. If it is not currently connected to a Wi-Fi 852 Direct Group, it performs a selection heuristic to determine which 853 node to connect to. The motivation behind this selection process is 854 to attempt to minimize the number of Wi-Fi Direct Groups in a certain 855 area given that nodes can only transmit packets within the Group they 856 are currently connected to. 858 The heuristic simply favors whichever Group Owner is already detected 859 among the available peers. In the case there is exactly one Group 860 Owner, the current node attempts to join its Group. If more than one 861 or no Group Owners are available, the heuristic selects the non- 862 client node with the highest UUID. If the selected node is not the 863 current node, a connection is attempted. This heuristic guarantees 864 that the current node will never attempt to connect to a Client, thus 865 breaking an existing Group. Also, all nodes located in an area and 866 have the same view of available peers will all select the same node 867 as the Group Owner to which connection should be attempted. 869 For each node detected in a Wi-Fi Direct Group, a new instance of an 870 OPPFace is created. The status of an OPPFace tells us if the 871 connectivity link towards a specific node is up or down. Based on 872 this information, the OPPFace decides whether to simply queue a 873 packet (when OPPFace is down) or flush the queue (when OPPFace is 874 up). 876 In order to achieve this, whenever the node joins a Wi-Fi Direct 877 Group, it gets registered in the Group so that other nodes can send 878 packets to it. After this setup, all service changes detected within 879 the Group (connectivity up or down) are reflected into the Face Table 880 (cf. Figure 2). Upon disconnection from the Group, the node is 881 unregistered and the node returns to a state of waiting for a Group 882 to be joined. 884 3.3. LSA Exchange 886 DABBER performs the dissemination of LSAs based on a process able of 887 synchronizing the content of LSDBs. In this sense, all LSAs are kept 888 in the LSDB as a name set, and DABBER uses a hash of the LSA name set 889 as a compact expression of the set. Neighbor nodes use the hashes of 890 their LSA name sets to detect inconsistencies in their sets. For this 891 reason, neighbor nodes exchange hashes of the LSDB as soon as 892 OPPFaces are UP. 894 Current version of DABBER makes use of ChronoSync as synchronization 895 mechanism. Chronosync allows DABBER to define a collection of named 896 data in a local repo as a slice. LSA information are synchronized 897 among neighbor nodes, since Chronosync keeps the repo slice 898 containing the LSA information in sync with identically defined 899 slices in neighboring repositories. 901 If a new LSA name is detected in a repo, ChronoSync notifies DABBER 902 to retrieve the corresponding LSA in order to update the local LSDB. 903 DABBER can also request new LSAs from Chronosync when resources (e.g. 904 CPU cycles) are available. 906 Figure 5 shows how an LSA is disseminated between two neighbor nodes 907 A and B, when the OPPFace is UP. To synchronize the slice 908 representing the LSDB information in the repo, ChronoSync, on each 909 node, periodically sends Sync Interests with the hash of its LSA name 910 set / slice (step 1). When Node A has a new Prefix LSA in its LSDB, 911 DABBER writes it in the Chronosync slice (step 2). At this moment, 912 the hash value of the LSA slide of node A becomes different from that 913 of node B. As a consequence, the Chronosync in node A replies to the 914 Sync Interest of node B with a Sync Reply with the new hash value of 915 its local LSA slice (step 3). The Chronosync in node B identifies the 916 LSA that needs to be synchronized and notifies DABBER about the 917 missing LSA, and updates its LSA name set (step 4). Since DABBER on 918 node B has been notified of the missing LSA, DABBER sends an LSA 919 Interest message to retrieve the missing LSA (step 5). DABBER on node 920 A sends the missing data in a LSA Data message (step 6). When DABBER 921 on node B receives the LSA data, it inserts the LSA into its LSDB. 922 Chronosync on nodes A and B compute a new hash for updated the set 923 and send a new Sync Interest with the new hash (step 7). 925 Node A Node B 926 +----------------------------+ +----------------------------+ 927 | +-------------+ | |+-------------+ | 928 | DABBER | Chronosync | | || Chronosync | DABBER | 929 | +-------------+ | |+-------------+ | 930 +----------------------------+ +----------------------------+ 931 | | Sync Interest (1) | | 932 | |------------------->| | 933 | |<-------------------| | 934 | New LSA (2)| | | 935 |----------> | | | 936 | | Sync Reply (3) | | 937 | |------------------->| | 938 | | | Notify (4) | 939 | | |------------->| 940 | | LSA Interest (5) | | 941 |<-----------|--------------------|--------------| 942 | | LSA Data (6) | | 943 |------------|--------------------|------------->| 944 | | | | 945 | | Sync Interest (7) | | 946 | |------------------->| | 947 | |<-------------------| | 949 Figure 5: LSA exchange process. 951 When more than one LSA needs to be synchronized, the issued LSA 952 Interest packet will contain information about as many LSAs as 953 allowed by the Link maximum transmission unit. In the same sense one 954 LSA Data packet may include also be used to transport information 955 about more than one LSA. 957 3.4. Loop Avoidance 959 In addition to the loop avoidance mechanism of NDN, DABBER considers 960 a loop removal mechanism, which takes care of disabling the Face 961 responsible for the looping once it is detected. 963 3.5. Failure and Recovery 965 As described in section 3.2, DABBER relies on a connectivity manager 966 that is able to react to changes in the peers available within the 967 wireless scanning range of the current node. 969 Upon detection of a Wi-Fi Direct Group, the connectivity manager 970 automatically joins that Group, if it is not part of one. 972 Upon the reception of notifications regarding changes in the peers 973 detected in the neighborhood, the Connectivity Manager updates its 974 internal peer list. 976 3.6. Interface towards a Contextual Agent 978 The interface between DABBER and CM provides the former with periodic 979 information concerning a node's centrality (C) and a node's 980 availability (A), as well as with a similarity weight (I) between 981 peers (link relevancy). 983 This interface integrates premises to perform specific requests to 984 get the computed values C, U for a list of peers provided by DABBER. 985 The peers are identified by hashed MACs. 987 The interface integrates also a premise to provide a similarity 988 weight (I) between two peers passed by DABBER to the CM. For 989 instance, if DABBER requests similarity between node A (sender) and 990 node B (potential successor), then the CM computes similarity for 991 both nodes based on a specific period of time. Such analysis can 992 assist in a better selection of peers for data transmission, for 993 instance. 995 4. Interoperability 997 As mentioned in section 1.2 DABBER is being developed to allow the 998 deployment of wireless NDN networks where nodes and links can be 999 intermittently available. In this section we analyze the 1000 interoperability of DABBER in two scenarios: the NDN wireless network 1001 is at the fringes of a wired NDN core; the NDN wireless network can 1002 interconnect topologically separated NDN networks or hosts, via a 1003 DTN. 1005 4.1. Interoperability with NDN operation over DTNs 1007 In this sub-section, we review the deployment of DABBER over existing 1008 DTNs. We only consider deployment scenarios where NDN is deployed as 1009 an overlay over a DTN. In this case, the existing DTN infrastructure 1010 and implementation are leveraged to extend NDN operation in 1011 challenged networks. We consider scenarios such as data mulling, 1012 services to remote locations, and interconnecting different NDN hosts 1013 (fixed or mobile)[23]. 1015 In such challenged network topologies, OPPFaces may not be able to 1016 cope well with long delays or disruption due to frequent 1017 disconnections and node mobility, severely hampering network 1018 operations. A DTN face integrated into NDN-OPP provides the latter 1019 with a robust communications platform supporting communications in 1020 these conditions, by providing the option to propagate Interests to, 1021 and return Data from, remote NDN hosts or networks. These are assumed 1022 to typically reside in access points and wireless edge routers, or 1023 mobile devices and have a corresponding DTN face implementation. 1025 DABBER will employ the DTN face, either in a hop-by-hop or a multi- 1026 hop fashion, when it senses, through the connectivity manager, that 1027 the OPPFaces do not provide a high probability of successful data 1028 delivery (e.g. Time-to-completion is too high). As DTN faces operate 1029 as regular faces, cost computation and face ranking/selection is 1030 performed using the procedure described in section 2.4. 1032 4.2. Interoperability with NDN operation in wired networks 1034 In this sub-section we analyze the interoperability of DABBER with 1035 two potential configurations of an NDN access network based on: a 1036 routing protocol able of disseminating name prefix information, such 1037 as NLSR; a broadcast based forwarding approach. 1039 4.2.1. Interoperability with NLSR 1041 The LSA dissemination mechanism described in section 3.3 is used to 1042 ensure interoperability with NLSR. Such mechanism ensures the 1043 interoperability between a DABBER node and a NLSR edge router, since 1044 the specification used by DABBER follows the same message structure 1045 and sequence of the mechanism used by NLSR [19][20]. 1047 However, when DABBER is executing the LSA dissemination procedure 1048 over a Wi-Fi face (towards a NLSR edge router), the following updates 1049 to the procedure described in section 3.3 need to be done in order to 1050 account for the changes between DABBER and NLSR as stated in section 1051 2.3: 1053 o When DABBER gets an Interest packet related to a Prefix LSA, 1054 DABBER excludes the information about the cost of each name 1055 prefix. 1057 o When DABBER gets a Data packet related to a Prefix LSA, it had 1058 to each name prefix a standard cost of 86400 (corresponding to a 1059 validity of 1 day). 1061 o DABBER will ignore all notifications that Chronosync will send 1062 it related to Adjacency LSAs. 1064 4.2.2. Interoperability with broadcast based forwarding 1066 Broadcast-based forwarding is a common mechanism in the design of 1067 some networks, such as switched Ethernet and mobile ad-hoc networks. 1068 In NDN networks this means that NFD broadcasts Interest packets that 1069 do not match an entry in the FIB, inserting then into the FIB the 1070 forwarding path learned through observation of Data return paths. The 1071 main challenge in broadcast based forwarding schemes is the prefix 1072 granularity problem: determine the name prefix of an inserted FIB 1073 entry from the Data name. Several solutions exist [16], including the 1074 announcements of name prefixes, as done by DABBER. 1076 In any case DABBER interoperability with such NDN networks relies on 1077 the following considerations: 1079 o When in contact with a wireless edge router, DABBER always 1080 forward Interest packet towards the Wi-Fi Face, even when the 1081 Interest packet does not match an entry in the FIB. o Interest 1082 packets received from a wireless edge router will not be 1083 broadcast. Interest packets will be forwarded if they match an 1084 entry in the FIB, or dropped otherwise. 1086 5. Security Considerations 1088 As happens with NLSR, DABBER routing messages are carried in NDN data 1089 packets containing a signature. Hence, a DABBER node can verify the 1090 signature of each routing message to ensure that it was generated by 1091 the claimed origin node and was not tampered with during 1092 dissemination. For this propose, DABBER makes use of a hierarchical 1093 trust model for routing, as used by NLSR within a single domain, to 1094 verify the keys used to sign the routing messages. 1096 Following the name structure described in section 2.2, DABBER models 1097 the trust management as a five-level hierarch, as in NLSR, although 1098 reflecting a different administrative structure: represents 1099 the authority responsible by the international transit network 1100 allowing roaming services; represents the operator 1101 providing the mobile service; represents the network site of 1102 the mobile operator where the node is registered; represents 1103 the mobile equipment. Each node can create a DABBER process that 1104 produces LSAs. 1106 With this hierarchical trust model, one can establish a chain of keys 1107 to authenticate LSAs. Specifically, a LSA must be signed by a valid 1108 DABBER process, which runs on the same node where the LSA was 1109 originated. To become a valid DABBER process, the process key must be 1110 signed by the corresponding node key, which in turn should be signed 1111 by the registered home network of the network operator. Each home 1112 network key must be signed by the operator key, which must be 1113 certified by the network authority using the network key, which is 1114 called trust anchor in NDN. 1116 Since keys must be retrieved in order to verify routing updates, 1117 DABBER allows each node to retrieve keys from its neighbors. This 1118 means that a DABBER node will use the NDN Interest/Data exchange 1119 process to gathers keys from all its direct neighbors. Upon the 1120 reception of an Interest of the type //broadcast/KEYS each 1121 neighbor looks up the requested keys in their local key storage and 1122 return the key if it is found. In case a neighbor does not have the 1123 requested key, the neighbor can further query its neighbors for such 1124 key. The used key retrieval process makes use of a broadcast 1125 forwarding strategy, stopping at nodes who either own or cache the 1126 requested keys. 1128 6. Implementation and Deployment Experience 1130 Currently DABBER is being implemented as the routing scheme for the 1131 NDN framework for Opportunistic Networks (NDN-OPP) [3]. NDN-OPP is an 1132 extension of the NDN Android implementation, aiming to support NDN 1133 communication in wireless networks by exploiting direct communication 1134 between wireless nodes, as well as intermittent Wi-Fi connectivity to 1135 the Internet (NDN global test-bed). 1137 NDN-OPP has been demonstrated in ACM ICN 2017 in Berlin [4], as well 1138 as in the NDNComm in Memphis [5]. NDN-OPP code is available in 1139 GitHub: https://github.com/COPELABS-SITI/ndn-opp 1141 7. Acknowledgments 1143 The research leading to these results has received funding from the 1144 European Union (EU) Horizon 2020 research and innovation programmer 1145 under grant agreement No 645124(Action full title: Universal, mobile- 1146 centric and opportunistic communications architecture, Action 1147 Acronym: UMOBILE). 1149 We thank all contributors, as well as the valuable comments offered 1150 by Lixia Zhang (UCLA) and Lan Wang (University of Memphis) to improve 1151 this draft. 1153 8. References 1155 8.1 Normative References 1157 [1] Lixia Zhang, Deborah Estrin, Jeffrey Burke, Van Jacobson, James 1158 D. Thornton, Diana K. Smetters, Beichuan Zhang, Gene Tsudik, KC 1159 Claffy, Dmitri Krioukov, Dan Massey, Christos Papadopoulos, 1160 Tarek Abdelzaher, Lan Wang, Patrick Crowley, Edmund Yeh "Named 1161 Data Networking", NDN Technical Report NDN-001, October 2010. 1163 [2] A. Afanasyev, J. Shi, B. Zhang, L. Zhang, I. Moiseenko, Y. Yu, W. 1164 Shang, Y. Li, S. Mastorakis, Y. Huang, J. P. Abraham, E. 1165 Newberry, S. DiBenedetto, C. Fan, C. Papadopoulos, D. Pesavento, 1166 G. Grassi, G. Pau, H. Zhang, T. Song, H. Yuan, H. B. Abraham, P. 1167 Crowley, S. O. Amin, V. Lehman, M. Chowdhury, and L. Wang, "NFD 1168 Developer's Guide", NDN, Technical Report NDN-0021, February 1169 2018. 1171 [3] Miguel Tavares, Paulo Mendes, "NDN-Opp: Named-Data Networking in 1172 Opportunistic Networks", Technical Report COPE-SITI-TR-18-01, 1173 January 2018. 1175 8.2 Informative References 1177 [4] Seweryn Dynerowicz, Paulo Mendes, "Named-Data Networking in 1178 Opportunistic Networks", in ACM ICN, Berlin, Germany, September 1179 2017. 1181 [5] Seweryn Dynerowicz, Omar Aponte, Paulo Mendes, "NDN Operation in 1182 Opportunistic Wireless Networks", in NDNcomm, Memphis, USA, 1183 March 2017 1185 [6] Christos-Alexandros Sarros, Sotiris Diamantopoulos, Sergi Rene, 1186 Ioannis Psaras, Adisorn Lertsinsrubtavee, Carlos Molina-Jimenez, 1187 Paulo Mendes, Rute Sofia, Arjuna Sathiaseelan, George Pavlou, 1188 Jon Crowcroft, Vassilis Tsaoussidis, "Connecting the Edges: A 1189 Universal, Mobile centric and Opportunistic Communications 1190 Architecture", IEEE Communication Magazine, February 2018 1192 [7] Rute C. Sofia, Igor Santos, Jose Soares, Sotiris Diamantopoulos, 1193 Christos-Alexandro Sarros, Dimitris Vardalis, Vassilis 1194 Tsaoussidis, Angela; d'Angelo, "UMOBILE D4.5 - Report on Data 1195 Collection and Inference Models" Technical Report, September 1196 2018. 1198 [8] NDN Project, "NFD Developer's Guide", Technical Report NDN-0021, 1199 October 2016. 1201 [9] Zhenkai Zhu and Alexander Afanasyev, "Let's ChronoSync: 1202 Decentralized Dataset State Synchronization in Named Data 1203 Networking", in Proc. IEEE ICNP, Goettingen, Germany, Oct 2013 1205 [10] Minsheng Zhang, Vince Lehman, and Lan Wang, "PartialSync: 1206 Efficient Synchronization of a Partial Namespace in NDN", NDN 1207 Technical Report NDN-0039, June 2016. 1209 [11] Klaus Schneider, Beichuan Zhang, "How to Establish Loop-Free 1210 Multipath Routes in Named Data Networking", NDN Technical Report 1211 NDN-0044, April 2017. 1213 [12] A. Lindgren, A. Doria, E. Davies, S. Grasic, "Probabilistic 1214 Routing Protocol for Intermittently Connected Networks, IETF RFC 1215 6693, Aug 2012. 1217 [13] Waldir Moreira, Paulo Mendes, Susana Sargento, "Social-aware 1218 Opportunistic Routing Protocol based on User's Interactions and 1219 Interests", in Proc. of AdhocNets, Barcelona, Spain, October 1220 2013 1222 [14] Waldir Moreira, Paulo Mendes, Susana Sargento, "Opportunistic 1223 Routing based on daily routines", in Proc. of IEEE WoWMoM 1224 workshop on autonomic and opportunistic communications, San 1225 Francisco, USA, June, 2012 1227 [15] P. Hui, J. Crowcroft, and E. Yoneki, "Bubble rap: social-based 1228 forwarding in delay tolerant networks," Mobile Computing, IEEE 1229 Transactions on, vol. 10, pp. 1576-1589, November, 2011. 1231 [16] Junxiao Shi, Eric Newberry, Beichuan Zhang, "On Broadcast-based 1232 Self-Learning in Named Data Networking", in Proc. Of IFIP 1233 Networking, Stockholm, Sweden, June 2017 1235 [17] The H2020 UMOBILE project. Grant number 645124, 2015-2018. 1236 Available via http://www.umobile-project.eu/ 1238 [18] Waldir Moreira, Paulo Mendes and Eduardo Cerqueira, 1239 "Opportunistic Routing based on Users Daily Life Routine", IETF 1241 [19] Vince Lehman, A K M Mahmudul Hoque, Yingdi Yu, Lan Wang, 1242 Beichuan Zhang, Lixia Zhang "A Secure Link State Routing 1243 Protocol for NDN", NDN Technical Report NDN-0037, January 2016. 1245 [20] Vince Lehman, Muktadir Chowdhury, Nicholas Gordon, Ashlesh 1246 Gawande, "NLSR Developer's Guide", November 2017. 1248 [21] V. Cerf, S. Burleigh, A. Hooke, L. Torgerson, R. Durst, K. 1249 Scott, K. Fall, H. Weiss, "Delay-Tolerant Networking 1250 Architecture", IETF RFC 4838, April 2007 1252 [22] K. Scott, S. Burleigh, "Bundle Protocol Specification", IETF RFC 1253 5050, November 2007 1255 [23] C.A. Sarros, A. Lertsinsrubtavee, C. Molina-Jimenez, K. 1256 Prasopoulos, S. Diamantopoulos, D. Vardalis, A. Sathiaseelan, 1257 "ICN-based Edge Service Deployment in Challenged Networks" 1258 (demo), in Proceedings of the 4th ACM Conference on Information- 1259 Centric Networking, Berlin, Germany, September 26-28, 2017 1261 Authors' Addresses 1263 Paulo Mendes 1264 COPELABS, Universidade Lusofona 1265 Campo Grande, 376 1266 1749-024 Lisboa 1267 Portugal 1268 Email: paulo.mendes@ulusofona.pt 1269 URI: http://www.paulomilheiromendes.com 1271 Rute Sofia 1272 Senception 1273 Av. da Republica 6, 7 Esq 1274 1050-191 Lisboa 1275 Portugal 1276 Email: rute.sofia@senception.com 1277 URI: http://www.rutesofia.com 1279 Vassilis Tsaoussidis 1280 Democritus University of Thrace 1281 University Campus 1282 69100 Komotini 1283 Greece 1284 Email: vtsaousi@ee.duth.gr 1286 Sotiris Diamantopoulos 1287 Democritus University of Thrace 1288 University Campus 1289 69100 Komotini 1290 Greece 1291 Email: diamantopoulos.sotiris@gmail.com 1293 Christos-Alexandros Sarros 1294 Democritus University of Thrace 1295 University Campus 1296 69100 Komotini 1297 Greece 1298 csarros@ee.duth.gr