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