idnits 2.17.1 draft-mendes-icnrg-dabber-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 15, 2020) is 1319 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Mendes, Ed. 3 Internet-Draft Airbus 4 Intended status: Experimental R. Sofia 5 Expires: March 19, 2021 fortiss GmbH 6 V. Tsaoussidis 7 Democritus University of Thrace 8 C. Borrego 9 Autonomous University of Barcelona 10 September 15, 2020 12 Information-centric Routing for Opportunistic Wireless Networks 13 draft-mendes-icnrg-dabber-05 15 Abstract 17 This draft describes the Data reAchaBility BasEd Routing (DABBER) 18 protocol. DABBER aims to provide a name-based routing solution to 19 support the operation of Information-centric Networking frameworks in 20 opportunistic wireless networks. By "opportunistic wireless 21 networks" it is meant multi-hop wireless networks where finding an 22 end-to-end path between any pair of nodes at any moment in time may 23 be a challenge. The goal is to assist in better defining 24 opportunities for the transmission of Interest packets in a store- 25 carry-and-forward manner, based on a proactive approach. The 26 document describes how to integrate DABBER in a networking node that 27 implements some ICN approach, such as Named-Data Networking (NDN) or 28 Content Centric Networking (CCN), along with the specification of the 29 proactive approach based on the dissemination of name-prefix 30 information. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on March 19, 2021. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Assumptions and Design Choices . . . . . . . . . . . . . 4 68 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Applicability Examples . . . . . . . . . . . . . . . . . . . 4 70 3. DABBER Architecture . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Extensions to NFD . . . . . . . . . . . . . . . . . . . . 6 72 3.2. Routing Engine . . . . . . . . . . . . . . . . . . . . . 7 73 4. DABBER Protocol Design . . . . . . . . . . . . . . . . . . . 8 74 4.1. Name Prefix Dissemination . . . . . . . . . . . . . . . . 10 75 4.2. Name Prefix Cost Computation . . . . . . . . . . . . . . 13 76 4.3. Update of Internal Structures . . . . . . . . . . . . . . 15 77 4.4. Update of NFD Structures . . . . . . . . . . . . . . . . 15 78 4.5. Packet Format . . . . . . . . . . . . . . . . . . . . . . 16 79 5. DABBER Operational Example . . . . . . . . . . . . . . . . . 16 80 6. DABBER Operational Considerations . . . . . . . . . . . . . . 17 81 6.1. Context Awareness . . . . . . . . . . . . . . . . . . . . 18 82 6.2. Integration with Wi-Fi Direct . . . . . . . . . . . . . . 19 83 6.3. Integration with DTN . . . . . . . . . . . . . . . . . . 20 84 6.4. Producer Mobility . . . . . . . . . . . . . . . . . . . . 20 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 86 7.1. Authenticity . . . . . . . . . . . . . . . . . . . . . . 22 87 7.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 22 88 7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 90 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 92 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 93 10.2. Informative References . . . . . . . . . . . . . . . . . 24 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 96 1. Introduction 98 This document provides a specification for DABBER, an opportunistic 99 wireless routing protocol that provides a name-based routing solution 100 for the operation of Information-Centric Networking (ICN) [RFC7476] 101 in wireless networks, including opportunistic wireless environments. 102 The term opportunistic wireless networks primarily refers to multi- 103 hop wireless networks, where finding an end-to-end path between any 104 pair of nodes at any moment in time may be a challenge, given that 105 networking nodes availability depends upon different mobility 106 patterns and wireless links are intermittently available due to 107 changes in the environment or changes in the position of the nodes 108 terminating the link. Examples of such wireless environments 109 encompass mobile crowd sensing and Internet of Things, where things 110 are mobile devices, or sensors, including those operating in 111 terrestrial or non-terrestrial networks that integrate smart 112 satellite constellations. 114 The deployment of information centric wireless networks by applying 115 NDN or CCN alone, inevitably leads to network flooding, due to the 116 lack of knowledge about the best set of paths to reach data holders. 117 As a basic NDN/CCN approach the first set of Interest packets are 118 broadcasted in order to identify the interfaces that lead to a data 119 holder. DABBER aims to prevent such flooding by allowing data 120 holders to announce the name prefix of the data sets they hold. This 121 allows networking nodes to know which are the appropriate interfaces 122 to reach a certain data set prior to the arrival of the corresponding 123 Interest packets. The expected result is the reduction of both 124 network overhead and latency of Interest packets. 126 It is our understanding that routing in such wireless environments 127 needs to be done based on strategies that take into consideration, at 128 a network level, the context of wireless nodes (e.g., availability, 129 centrality), and not just the history of contacts among wireless 130 nodes, as it is often the case in opportunistic routing [Dlife] 131 [Dlife-draft] [Scorp]. The goal is to better determine windows of 132 opportunity to transmit Interest and Data packets, while opportunity 133 reflects both time and space. 135 DABBER is devised to be easily integrated with the data plane of CCN/ 136 NDN [NFD], since these are well established distributed ICN 137 frameworks. 139 A DABBER [DABBER18] proof-of concept implementation is available via 140 GitHub [DABBER18-1] and via Google Play [DABBER18-2]. DABBER has 141 been tested in emergency scenarios with intermittent connectivity 142 based on a novel NDN instant messenger, the Oi! Application for 143 Android [OI]. 145 1.1. Assumptions and Design Choices 147 DABBER relies on the following assumptions with regard to 148 opportunistic wireless environments: 150 o Nodes are mobile. 152 o Nodes overhear each other. 154 o Nodes can be data sources, data destinations, or forwarders. 156 o Nodes may decide to be the custodians of data transmissions based 157 on a set of criteria, such as local available resources. 159 o Nodes do not have a complete topology view. 161 DABBER relies on the following major design choices to develop a 162 name-based routing protocol for opportunistic wireless network: 164 o DABBER must avoid the network being flooded by Interest packets. 166 o DABBER is based on the distribution of name prefix (data 167 reachability) only, since adjacency information may present high 168 variability. 170 o DABBER is based on local information about the context of a node, 171 in order to support the selection of the most suitable neighbours to 172 forward Interest packets. 174 o DABBER avoids the definition of new messages by making usage of 175 synchronization mechanisms already developed for NDN, such as 176 ChronoSync [ChronoSync][PartialSync]. 178 1.2. Conventions 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in RFC 2119. 184 2. Applicability Examples 186 Mobile Crowd Sensing: This scenario encompasses the implementation of 187 NDN/CCN in personal mobile nodes (e.g., smartphones) allowing users 188 to share data and messaging services by exploiting existing 189 intermittent wireless connections (e.g., Wi-Fi, Wi-Fi Direct) in an 190 environment without/or limited Internet access. These scenarios are 191 also relevant in dense and remote areas. 193 Smart Satellite Constellation Communication: Delay Tolerant 194 Networking (DTN) [RFC4838] is acknowledged as a relevant technology 195 also for future smart satellite constellations. ICN adds in the 196 support for intermittent connectivity, and relevant properties to 197 support mobility and integrated security. 199 People-to-people Communication in Emergency Scenarios: A routing 200 solution such as DABBER assists in supporting local data exchange 201 across entities in a way that is agnostic to devices capabilities and 202 identity [Umobile]. 204 Internet of Things: The Pub/Sub receiver-driven nature of ICN brings 205 in recognizable advantages to the Internet of Things, in particular 206 involving mobile nodes, such as fleets of AGVs, UAVs. 208 3. DABBER Architecture 210 R relies on the same data structures made available by the Named Data 211 Networking Forwarding Daemon [NFD], namely the Routing Information 212 Base (RIB), the Forwarding Information Base (FIB), and the Pending 213 Intent Table (PIT), as illustrated in figure 1. 215 DABBER brings no changes to the operation of NFD. However, 216 augmenting NFD with a routing engine for wireless networks requires 217 the inclusion of three new components to NFD. This extended NFD is 218 called NDN-OPP (NDN for Opportunistic networks) [NDN-OPP], as shown 219 in figure 1. 221 This section provides a description of the extensions included in NFD 222 as well as the new components of the DABBER routing engine. 224 +--------------+ +--------------------------- + +----------+ 225 |NDN-OPP | | DABBER | |Contextual| 226 | +---------+ | | +---------------+ |-------| Manager | 227 | |Add_Route|<--| |--->|Neighbor Mng |<-| | +----------+ 228 | +---------+ | | | | +---------------+ | 229 | | +------+ | | | | | | | 230 | | |NFD | | | | | | | | 231 | | | +---+| | | | | v v | 232 | |-->|RIB|| | | | | +----------+ +--------+ | 233 | | +---+| | |------|RIB-Update|<-|CompCost|<|| 234 | | +---+| | | | +----------+ +--------+ || 235 | | |FIB|| | | | | || 236 | | +---+| | | | v +--------+ || 237 | | +---+| | | | +------+ |Name_Mng|---|| 238 | | |PIT|| | | | | LSDB |<--->+--------+ | 239 | | +---+|<|| | | +------+<------| | 240 | +------+ || | | v | 241 | +-------+-|| | | +-------+ | 242 | |Pkt_Mng|<-----| | | PSync | | 243 | |>+-------+ | | +-------+ | 244 | | | +----------------------------+ 245 |+--------+ | 246 ||OppFace | | 247 +--------------+ 249 Figure 1: DABBER Architecture. 251 3.1. Extensions to NFD 253 In order to augment NFD with a routing engine to allow for the 254 deployment of NDN/CNN in wireless networks three new elements were 255 included in NFD: a method to add routes to the RIB (Add_route in 256 figure 1); a method to gather information (carried names) and status 257 (time of reception) of Interest and Data messages (Pkt_Mng in figure 258 1); a new face able to handle the intermittent nature of wireless 259 links, called Opportunistic Face (OPPFace) (c.f figure 1). 261 An OPPFace is a virtual face based on a system of packet queues to 262 hide intermittent connectivity. An OPPFace is created for each 263 neighbor node, where a neighbor node is any node that the current 264 node has ever contacted to directly (i.e. over one radio hop). 265 OPPFaces are kept in the Face Table and their state reflects the 266 wireless connectivity status towards the respective neighbor: they 267 can be in an Up or Down state, depending upon the wireless 268 reachability the corresponding neighbor node. 270 When packets are dispatched based on the information stored in the 271 FIB, an OPPFace is able to delay packet transmission until there is 272 wireless connectivity to the correspondent neighbor: the OPPFace 273 simply queue packets, when OPPFace is Down, or flush the queue, when 274 OPPFace is Up. Since packet queuing is concealed inside OPPFaces, 275 existing forwarding strategies do not need to be changed. 277 OPPFaces can be implemented by using any direct wireless 278 communication mode (Infrastructured, Ad-Hoc, and Direct mode). The 279 current implementation of NDN-OPP for Android devices 280 [NDN-OPP-Android] makes usage of group communications provided by Wi- 281 Fi Direct [NDN-emergency][NDN-opportunisticnets]. More information 282 about the integration of NDN-OPP with Wi-Fi Direct is provided in 283 section 6.2. 285 3.2. Routing Engine 287 DABBER is a name-based routing protocol that allows nodes to exchange 288 information about name reachability in order to select the most 289 suitable neighbours to forward Interest messages. 291 The operation of the DABBER routing engine is performed based on the 292 following components, illustrated in figure 1: 294 o Neighbor_Management: Keep updated information about neighbours in a 295 Neighbor Table. A neighbor entry in that table has information about 296 the neighbor availability, centrality and similarity, as well as 297 about the delay that Interest packets suffer when forwarded via a 298 certain neighbour. The information about neighbours is used to 299 compute the cost of each name prefix announced by them, while the 300 information about the delay of Interest packets is used to update the 301 weights of the neighbors entries in the RIB. The delay of Interest 302 packets is a measure of the time difference between sending an 303 Interest packet and receiving the corresponding Data packet, based on 304 information collected from the Pkt_Mng module of NDN-OPP. The 305 information about neighbor availability, centrality and similarity is 306 collected by an external entity, as described in section 6.1. 308 o Compute_Name_Cost: This module computes the cost associated with 309 each name prefix as a function of the node similarity of the neighbor 310 announcing the name prefix, and the cost received in the 311 announcement. That cost is used to update the entry of that name 312 prefix / Neighbor in the DABBER internal Routing Table. 314 o Name_Prefix_Management: This module is responsible to remove and 315 add Link State Announcement (LSA) into the Link State DataBase (LSDB) 316 used by PSync. New LSAs present in the LSDB (announced by a 317 neighbor) are removed in order to pass the following tuples to the 318 module responsible to compute the costs of name prefixes: Name 319 prefix; Cost; Neighbor. 321 o RIB_Update: This module keeps updated information about the cost of 322 the name prefixes that will be used to populate the NFD RIB. The 323 information about each name prefix is kept in a local Routing 324 Table based on the tuple: Name prefix; Cost; Neighbor. The cost 325 variable is a function of the cost provided by the Compute_Name_Cost 326 module, plus the information about the availability and centrality of 327 the neighbor, provided by the Neighbor_Management module. In defined 328 periods of time the RIB_Update modules will use the content of the 329 local Routing Table to populate the NFD RIB as well as to insert new 330 LSA into the LSDB. 332 o LSDB: The Link State DataBase is the structure used by the PSync to 333 keep all the information to be synchronized among neighbor nodes. By 334 placing LSAs into the LSDB, DABBER ensures that such information is 335 passed to all neighbours without the need to define a new set of 336 messages for the exchange of routing information. 338 Between PSync and ChronoSync, DABBER makes use of the former since it 339 is designed to support partial dataset synchronization. This means 340 that PSync allows a node to subscribe to a subset of data streams, 341 where a data stream is a sequence of data items under a common name 342 prefix. Hence, by avoiding full sync operations of a LSDB in which 343 only a few entries may be new, PSync helps to improve DABBER 344 performance over networks in which wireless links are intermittently 345 available. 347 4. DABBER Protocol Design 349 Being developed for wireless networks, DABBER does not rely on the 350 dissemination of Adjacency Link State Advertisements that reflect the 351 status of the links towards neighbor nodes; DABBER only requires the 352 dissemination of Prefix LSAs. DABBER does not require the 353 computation of shortest paths taking into account adjacency 354 information. Instead DABBER replaces the path cost (sum of the 355 weights of all the involved links) used in fixed networks with the 356 computation of data reachability cost based on local available 357 information, reducing the impact that topological changes would have 358 on the stability of routing information. The assumption behind this 359 rational is that the position and validity of the data announced by a 360 data holder changes less than the conditions in all the links making 361 all potential paths. 363 By exchanging Prefix LSAs each device becomes aware of potential 364 next-hops via which a name prefix N can be reached with a certain 365 cost k. This cost k represents the probability of reaching a data 366 object identified by N via a Face F, and is related to the time 367 validity of the name prefix (v). The rationale for this approach is 368 that the selection of faces that have a lower cost k (higher validity 369 v) will improve data reachability. The validity of a name prefix is 370 set by the data source as an integer that represents the expiration 371 date of the data. 373 Since different devices can announce the same name prefix, a certain 374 name prefix may be associated with different values of k (as v shall 375 differ) over different faces, depending upon the nodes announcing 376 such name prefix: this lead to the identification of multiple next 377 hops, each one with a different cost. 379 The computation of multiple next hops is performed every time DABBER 380 has a new Name Prefix LSA (or a new version of an existing Name 381 Prefix LSA) in its LSDB. 383 The computation of multiple next hops is performed every time DABBER 384 has a new Name Prefix LSA (or a new version of an existing Name 385 Prefix LSA) in its LSDB. 387 With this in mind, DABBER was designed with the following sequence of 388 operations, as described in the following subsections: 390 1. Name prefix dissemination. 392 2. Name prefix cost computation. 394 3. Update of internal structures (DABBER routing table and LSDB) 395 with the data reachability information of the current node towards 396 the new Name Prefix. 398 4. Update of NFD structure (RIB) based on the DABBER internal 399 routing table. 401 Periodically DABBER updates the validity values of all Name Prefixes 402 in its internal routing table, performing the consequent updates of 403 the local LSDB and RIB, and needed. 405 The updated RIB information is used by NFD to update its FIB, which 406 is used to forward Interest packets, based on the normal operation of 407 NFD. However, independently of the used forwarding strategy, the 408 ranking of faces done by DABBER on the RIB should be respected. For 409 instance an unicast forwarding strategy should use the most important 410 face (lower cost), while a multicast forwarding strategy will use all 411 the faces indicated for the name prefix. After selecting the best 412 set of faces, a copy of the Interest packet is sent to the OPPFaces 413 of the selected faces. The state of an OPPFace reflects the fact 414 that the corresponding neighbor device is currently reachable or not. 415 Based on this information, the OPPFace decides whether to simply 416 queue the packet or attempt a transmission over the associated 417 Opportunistic Channel. 419 In what concerns Data packets, they are forwarded following the 420 normal operation of NFD, that is, following the information stored in 421 the PIT. 423 4.1. Name Prefix Dissemination 425 DABBER was designed to exploit the synchronization mechanisms made 426 available by NDN, such as PSync to control the dissemination of name 427 prefixes without the need to define neither new messages nor new 428 message passing mechanisms. 430 This means that while IP-based routing protocols push updates to 431 other routers, DABBER devices pull updates. DABBER can use any 432 underlay communication channels (e.g., TCP/UDP tunnels, Link layer 433 TXT records) to exchange LSA information via an existing mechanism, 434 such as PSync. 436 By using Interest/Data packets (exchanged by PSync), DABBER benefits 437 from CCN/NDN built-in data authenticity to exchange routing 438 information: since a routing update is carried in an Data packet and 439 every Data packet carries a signature, a DABBER device can verify the 440 signature of each LSA to ensure that it was generated by the claimed 441 origin node and was not tampered during dissemination. 443 Prefix LSA 444 +----------------------------------------------------+ 445 |LSA |Number of|Prefix 1|Cost|...|Prefix N|Cost|Sign.| 446 |Name|Prefixes | | | | | | | 447 +----------------------------------------------------+ 449 Figure 2: Prefix LSA format. 451 DABBER advertises Prefix LSAs every time a new name prefix is added 452 or deleted to the LSA DataBase (LSDB). Name prefixes are advertised 453 with a cost metric related to the validity of the associated data, as 454 shown in Figure 2. Each LSA used by DABBER has the name 455 DID/DABBER/LSA/Prefix/version. The DID is described by a scheme 456 based on URIs. It can be for instance network/operator/home/node/. 457 The version field is increased by 1 whenever a device creates a new 458 version of the LSA. 460 DABBER disseminates LSAs via a data synchronization mechanism (e.g. 461 PSync) of the local LSDB. This peer synchronization approach is 462 receiver-driven, meaning that a device requests LSAs only when it has 463 CPU cycles. Thus it is less likely a device will be overwhelmed by a 464 flurry of updates. In order to reduce the amount of transferred 465 data, DABBER removes obsolete LSAs from the LSDB by periodically 466 refreshing each of its own LSAs by generating a newer version. Every 467 LSA has a lifetime associated with it and will be removed from the 468 LSDB when the lifetime expires. 470 DABBER performs the dissemination of LSAs based on a process able to 471 synchronize the content of LSDBs. In this sense, all LSAs are kept 472 in the LSDB as a name set, and DABBER uses a hash of the LSA name set 473 as a compact expression of the set. Neighbor nodes use the hashes of 474 their LSA name sets to detect inconsistencies in their sets. For 475 this reason, neighbor nodes exchange hashes of the LSDB as soon as 476 OPPFaces are up. 478 Current version of DABBER makes use of PSync as a synchronization 479 mechanism. PSync allows DABBER to define a collection of named data 480 in a local repo as a slice. LSA information is synchronized among 481 neighbor nodes, since PSync keeps the repo slice containing the LSA 482 information in sync with identically defined slices in neighboring 483 repositories. 485 If a new LSA name is detected in a repo, PSync notifies DABBER to 486 retrieve the corresponding LSA in order to update the local LSDB. 487 DABBER can also request new LSAs from PSync when resources (e.g. CPU 488 cycles) are available. 490 Node A Node B 491 +------------------------+ +---------------------------+ 492 | +-------------+ | |+-------------+ | 493 | DABBER | Psync | | || Psync | DABBER | 494 | +-------------+ | |+-------------+ | 495 +------------------------+ +---------------------------+ 496 | | Sync Interest (1) | | 497 | |------------------->| | 498 | |<-------------------| | 499 | New LSA (2)| | | 500 |----------->| | | 501 | | Sync Reply (3) | | 502 | |------------------->| | 503 | | | Notify (4) | 504 | | |----------->| 505 | | LSA Interest (5) | | 506 |<-----------|--------------------|------------| 507 | | LSA Data (6) | | 508 |------------|--------------------|----------->| 509 | | | | 510 | | Sync Interest (7) | | 511 | |------------------->| | 512 | |<-------------------| | 514 Figure 3: LSA exchange process. 516 Figure 3 shows how an LSA is disseminated between two neighbor nodes 517 A and B, when the OPPFace is up. To synchronize the slice 518 representing the LSDB information in the repo, PSync, on each node, 519 periodically sends Sync Interests with the hash of its LSA name set / 520 slice (step 1). When Node A has a new Prefix LSA in its LSDB, DABBER 521 writes it in the Chronosync slice (step 2). At this moment, the hash 522 value of the LSA slide of node A becomes different from that of node 523 B. As a consequence, the PSync in node A replies to the Sync 524 Interest of node B with a Sync Reply with the new hash value of its 525 local LSA slice (step 3). The PSync in node B identifies the LSA 526 that needs to be synchronized and notifies DABBER about the missing 527 LSA, and updates its LSA name set (step 4). Since DABBER on node B 528 has been notified of the missing LSA, DABBER sends an LSA Interest 529 message to retrieve the missing LSA (step 5). DABBER on node A sends 530 the missing data in a LSA Data message (step 6). When DABBER on node 531 B receives the LSA data, it inserts the LSA into its LSDB. PSync on 532 nodes A and B compute a new hash for updating the set and send a new 533 Sync Interest with the new hash (step 7). 535 When more than one LSA needs to be synchronized, the issued LSA 536 Interest packet will contain information about as many LSAs as 537 allowed by the Link maximum transmission unit. In the same sense one 538 LSA Data packet may also be used to transport information about more 539 than one LSA. 541 4.2. Name Prefix Cost Computation 543 When DABBER is notified that a new Prefix LSA was registered in the 544 LSDB or an existing Prefix LSA has a new version, it computes a new 545 cost for each name prefix in such Prefix LSA. The cost of a name 546 prefix is given by its validity. 548 DABBER starts by computing a new validity v for a prefix N depending 549 upon the validity announced by the neighbor, and the relevancy of the 550 association between the two neighbor nodes (e.g., node A and node B). 551 The cost of the Name Prefix, passed to NFD, will then be computed as 552 an inversely proportional value to its validity. 554 The relevance of the association between two neighbor nodes can be, 555 e.g., a measure of similarity, where similarity is seen as a link 556 measure, i.e., it provides a correlation cost between a node and its 557 neighbors. Or such relation can be weighted based on metrics derived 558 from average contact duration thus allowing a node to adjust the Name 559 Prefix validity based on the probability of meeting the respective 560 neighbor again. The "relation" between two neighbor nodes is 561 computed based on the three metrics (A, C, and S) provided by the 562 local contextual manager, plus a metric computed by DABBER itself: 563 the time reachability. 565 The variable considered by DABBER for the computation of the 566 validity/cost of a Name prefix passed by a neighbor Na are: 568 o Validity (V) - Represents the expiration date of the data 569 associated with the Name Prefix. Currently it is the UNIX Timestamp 570 (10 digit integer). 572 o Similarity metric (S) towards the neighbor Na, as passed by the 573 contextual manager (S >= 0), aiming to select neighbors with whom the 574 current node has a good communication link. 576 o Availability metric (A) towards the neighbor Na, as passed by the 577 contextual manager ( 0 < A < 1), aiming to select neighbors able to 578 process Interest packets with high probability. 580 o Centrality metric (C) towards the neighbor Na, as passed by an 581 external context-aware agent (rf. to section 6.1, C >= 0), aiming to 582 select neighbors with high probability of successfully forwarding 583 Interest packets. 585 o Time reachability (T) which corresponds to the RTT between sending 586 an Interest packet towards the source of such Name Prefix and 587 receiving a data packet. (0 < T < 1). Currently the value of T is 588 computed as (current time when data packet is received - time when 589 Interest packet was sent) / Validity of Name Prefix. Time 590 reachability allows DABBER to select next hops that lead to closer 591 sources. 593 Neighbor table 594 +------------------------------------------------------+ 595 | Face | Status | Metric C | Metric A | Metric S | 596 +------------------------------------------------------+ 597 | 1 | UP | 6 | 0.3 | 12 | 598 | 2 | DOWN | 4 | 0.8 | 8 | 599 | 3 | UP | 1 | 0.8 | 9 | 600 +------------------------------------------------------+ 602 Figure 4: Neighbor table. 604 The values C, A and S provided by the contextual manager are stored 605 in a Neighbor Table (c.f. Figure 4) indexed by the number of faces. 606 The higher the values of C, A and S, the most preferential a neighbor 607 is. 609 T is measured by observing the flow of Interest and Data packets. 610 Thus, the lowest the T, the most preferential a Face is. Although 611 different nodes may have a different implementation of a face ranking 612 logic, the relevancy of T in comparison to C and A should be higher, 613 since T reflects the measured delay to reach a data source, while C 614 and A are indicators of the neighbors potential as relays. 616 Based on the above mentioned metrics the Validity of a new Name 617 Prefix (V) is updated based on two operations: 619 o V' = f (V, S') = trunc (V * S'), where: 621 S' = (S - Smin) / (Smax - Smin); Smin = 0 and Smax = max (Smax, C) 623 o V'' = f (V', C', A, T) = 0.3* trunc (V' * (C'+A)) + 0.7 * trunc (V' 624 * T), where: 626 C' = (C - Cmin) / (Cmax - Cmin); Where Cmin = 0 and Cmax = max (Cmax, 627 C) 629 The computation of V' is done by the Compute_Name_Cost module, while 630 the execution of V'' is done by the RIB_Update module (c.f. figure 631 1). The value of V'' may be updated more often than V', since it is 632 assumed that the properties of the neighbours (C,A) as well as the 633 delay to a data holder (T) may vary more than the new announcement 634 from neighbours with an updated value of V. 636 4.3. Update of Internal Structures 638 After the computation of the cost of the Name Prefix taking into 639 account the relation of the current node with the neighbor announcing 640 it, DABBER updates its internal routing table (operation done by the 641 RIB_Update module) and its LSDB. The information on the routing 642 table will be used to update the RIB of the local NFD and the 643 information of the LSDB will be announced to all neighbors by PSync. 645 To update the Internal routing table, DABBER adds an entry (Na, V'') 646 for the Name Prefix received from Na, where V'' is the computed cost 647 of the name prefix. The routing table is then ordered by name prefix 648 in decreased order of validity. 650 Since the current node will also disseminate the received Name 651 Prefix, DABBER updates the cost of the Name Prefix in the LSA stored 652 in its local LSDB in order to consider the computed value V''. For 653 this, DABBER can use two methods: 655 o Maximal method: Cost of Name Prefix = max (V'', current cost on 656 LSA). 658 o Average method: Cost of Name Prefix = max (average (cost of Name 659 Prefix entries on local routing table), current cost on LSA). 661 4.4. Update of NFD Structures 663 After computing the new value of the cost of a name prefix, DABBER 664 updates the RIB entry of that name prefix with the face over which 665 the Name Prefix LSA was received and the new computed cost. The cost 666 (k) of the Name Prefix to be stored in the RIB is computed based on 667 its validity V'' as k = trunc (100/V''). 669 DABBER updates the RIB on NFD with the cost k based on three possible 670 logics: 672 o Increase diversity - The new Face is included in the RIB entry, if 673 the computed cost k helps to increase diversity of the name prefix. 674 For instance the new cost k is higher than the average costs already 675 stored for that name prefix, affected by a configured diversity 676 constant. This logic includes all neighbors with cost = trunc (100/ 677 V''), such that 1/V'' - Avr (Costs in RIB for N) > X (predefined 678 value). 680 o Downward Path Criterion - It is a non-equal cost multi-path logic 681 that is guaranteed to be loop-free. Based on the Downward Path 682 Criterion, the X faces (the maximum number X of desirable faces can 683 be defined by configuration) to be considered for a name prefix 684 include the one with the lowest cost k plus X-1 faces that have a 685 cost k lower than the cost that the current node has itself to the 686 name prefix. This logic includes X neighbors with cost = trunc(100/ 687 V''), such that cost is the lowest value of 1/V'' or cost < 1/ V. 689 o Downward Path Criterion extension - Also considers any face over 690 which the name prefix can be reached with a cost k equal to the cost 691 that the current node has itself to the name prefix. To avoid 692 packets from looping back, there is the need to add a tiebreaker, 693 which assures that traffic only crosses one direction of equal-cost 694 links. This logic includes X neighbors with cost = trunc (100/V''), 695 such that cost is the lowest value of 1/V'' or cost <=1/ V. 697 In any case the deployment of a DABBER network relies on having all 698 nodes implemented with the same logic. 700 4.5. Packet Format 702 DABBER nodes exchange Prefix LSAs by means of a synchronization 703 mechanism such as PSync, without the need to create new packets for 704 the exchange of routing information. 706 5. DABBER Operational Example 708 In order to illustrate the proactive routing method defined by 709 DABBER, let's consider Figure 5, where nodes A, B, and C reside in an 710 wireless node running DABBER, while nodes E and F are wireless edge 711 routers running another ICN routing protocol; G is a wireless node 712 running DABBER. 714 +--------------------+ 715 | +---+ | 716 | | B | . | 717 | +---+ .2+---+ | +---+ +---+ +---+ 718 |+---+ | C |3 ... | E |....| F |....| G | 719 || A |.......1+---+ | +---+ +---+ +---+ 720 |+---+ | 721 +--------------------+ 723 Figure 5: End-to-end operational example. 725 In our example, Node A starts producing some content derived, for 726 instance, from the use of an application (such as a data sharing 727 application). The produced content is stored in its local Content 728 Store with the name /NDN/video/Lisbon/nighview.mpg. Node B stores in 729 its Content Store a data object with name /NDN/video/Lisbon/ 730 river.mpg, which node B received from a neighbor (meaning that B has 731 already synchronized its LSDB with such a neighbor). 733 Due to the update of the Content Store, the name prefix /NDN/video/ 734 Lisbon/ is stored in the LSDB of node A and B with a validity of 735 864000 and 518400 in the case of node A and B respectively. In the 736 case of node A, the cost k of the name prefix equals the validity v 737 of the data object, e.g., v=864000 seconds (10 days) stipulated by 738 the application. In the case of node B the validity is the result of 739 the computation of the cost of the name prefix. 741 From a routing perspective, storing a name prefix in the local LSDB 742 allows the node to share the respective Prefix LSA on all its Faces, 743 excepting on the Face over which the LSA was previously received. 744 This LSA exchange is done when the OPPFaces are up. This means that 745 Node C, which got a new Prefix LSA from nodes A and B, will: 747 o Update its LSDB with the Prefix LSAs received from node A and node 748 B. 750 o Update its internal routing table with two new entries for the name 751 prefix /NDN/video/Lisbon/, associated with the face towards A (face1) 752 and with the face towards B (face2), after computing the values of V' 753 and V'' for the received validity values: 755 o The validity of the name prefix is updated based on the metric 756 configured for node C: average inter-contact time. 758 o Let's assume that A and C encounter each other frequently, while B 759 and C do not meet frequently. This means that the two entries on the 760 routing table of node C for prefix /NDN/video/Lisbon/ will have a 761 validity/cost for A higher than the one for B. 763 o Update its LSDB with the validity of the current node towards the 764 Name Prefix following the maximal or average methods. 766 o Update the RIB with one new entry for the name prefix /NDN/video/ 767 Lisbon/ with two faces (face 1 and face 2) with a cost inversely 768 proportional to the validity of the Name Prefix. 770 6. DABBER Operational Considerations 771 6.1. Context Awareness 773 DABBER defines routing and forwarding strategies that take into 774 consideration, at a network level, the context of wireless nodes, and 775 not just the history of contacts among wireless nodes. Contextual 776 information is obtained in a self-learning approach, by software- 777 based agents running in each networked device, and not based on 778 network wide orchestration. Contextual agents are in charge of 779 computing nodes and link related costs concerning availability and 780 centrality metrics. Contextual agents interact with DABBER via a 781 well-defined interface: the contextual self-learning process is not 782 an integrating part of the DABBER routing framework. 784 The contextual agent (named Contextual Manager [UmobileD45]) 785 installed in each device can therefore be seen as an end-user 786 background service that seamlessly captures wireless data to 787 characterize the affinity network (roaming patterns and peers' 788 context over time and space) and the usage habits and data interests 789 (internal node information) of a node. Data is captured directly via 790 the regular MAC Layer (e.g., Wi-Fi, Bluetooth, LTE) as well as via 791 native applications for which the user configures interests or other 792 type of personal preferences. For instance, an application can 793 request a one-time configuration of categories of data interests 794 (e.g., music, food). 796 Based on the defined interface, DABBER is able of querying the local 797 Contextual Manager about the characteristics of neighbor nodes, based 798 on three types of information: i) Node availability (metric A); ii) 799 Node centrality (metric C); iii) Node similarity (metric S): 801 o Node Availability (A) gives an estimate of the node availability 802 based on the usage of internal resources over time and space, as well 803 as the usage of physical resources (battery status; CPU status, 804 etc.). 806 o Node Centrality (C) provides awareness about the node's affinity 807 network neighborhood context. This means that a list is kept with 808 the following information about each neighbor: neighbour's node 809 degree (number of nodes contacted in a predefined time window); 810 Frequency of contacts between the neighbor and other nodes; Duration 811 of each contact between the neighbor and other nodes; Importance of 812 encountered nodes. 814 The Contextual Manager keeps values for the mentioned metrics for 815 different periods of time. Encountered nodes can be of different 816 types, such as other mobile devices or wireless access points, for 817 instance. 819 6.2. Integration with Wi-Fi Direct 821 When Wi-Fi Direct is used on the MAC layer, there is a one-to-one 822 correspondence between an OPPFace and a neighbor node (for each node 823 detected in a Wi-Fi Direct Group, a new instance of an OPPFace is 824 created). In this peer-to-peer scenario, OPPFaces can be used in two 825 transmission modes: connection-oriented, in which packets are sent to 826 a neighbor node via a reliable TCP connection over the group owner; 827 connection-less, in which packets are sent directly to a neighbor 828 node during the Wi-Fi direct service discovery phase. In the latter 829 case data transmission is limited to the size of the TXT record (900 830 bytes for Android 5.1 and above). This type of communication is used 831 to exchange small packets that require fast transmission (e.g. 832 emergency apps, Chronosync status messages). The connection-less 833 solution allows peers to exchange a short number of bytes without the 834 establishment of a TCP socket. 836 In the peer-to-peer scenario of Wi-Fi direct, DABBER operates as 837 follows: routing information is shared among all members of a Wi-Fi 838 direct group, while Interest Packets are forwarded to specific 839 neighbors. With Dabber it is the carrier of an Interest packet that 840 decides which of the neighbors will get a copy of the Interest 841 packet. Hence, with the current implementation of NDN-OPP, DABBER 842 places a copy of the Interest packet in the OPPFaces of selected 843 neighbors. In what concerns the dissemination of routing 844 information, it is ensured by: i) node mobility, meaning that nodes 845 carry such information between Wi-Fi direct groups; ii) information 846 is passed between neighbor groups via nodes that belong to more than 847 one group. 849 Based on the reception of notifications of Wi-Fi Direct regarding 850 changes in the peers detected in the neighborhood, DABBER is able to 851 update its internal peer list (Neighbor Table). If it is not 852 currently connected to a Wi-Fi Direct Group, it performs a selection 853 heuristic to determine which node to connect to. The motivation 854 behind this selection process is to attempt to minimize the number of 855 Wi-Fi Direct Groups in a certain area given that nodes can only 856 transmit packets within the Group they are currently connected to. 858 By defining OPPFaces implemented based on a broadcast link layer such 859 as ad-hoc Wi-Fi, DABBER will need to create only one OPPFace in each 860 networked device. Such OPPFace would be used to exchange packets 861 with any neighbor node, making use of the overhearing property of the 862 wireless medium. Since with DABBER, it is the carrier that decides 863 which of the neighbors are entitled to get a certain Interest packet, 864 DABBER would need to encode in the Interest packet information about 865 the ID of the neighbors that should process the overheard Interest 866 packet. 868 6.3. Integration with DTN 870 By defining a new DTNFace implemented based on the bundle layer, 871 DABBER could make use of the end-to-end protocol, block formats, and 872 abstract service description for the exchange of messages (bundles) 873 described in the DTN architecture. A DTNFace could provide a robust 874 communications platform for the transmission of Data packets towards 875 the consumer node, making usage of any available custodian nodes. 877 The bundle protocol [RFC5050] introduces the concept of a "bundle 878 agent" that manages the interface between applications and the 879 "convergence layers" that provide the transport of bundles between 880 nodes during communication opportunities. A DTNFace would extends 881 the bundle agent aiming to control the actions of the bundle agent 882 during communication opportunities. 884 A new DTNFace would aim to control the reception and delivery of 885 bundles, which are placed in a queue during the forwarding of Data 886 packets. A DTNFace would allows the routing process to be aware of 887 the bundles placed at the node, and allows it to inform the bundle 888 agent about the bundles to be sent to a neighbor node. Therefore, 889 the bundle agent implemented in a DTNFace would need to provide the 890 following interface/functionality to the forwarding process: 892 o Get Bundle List: Returns a list of the stored bundles and their 893 attributes to the routing agent. 895 o Send Bundle: Notifies the bundle agent to send a specified bundle. 897 o Drop Bundle Advice: Advises the bundle agent that a specified 898 bundle may be dropped by the bundle agent if appropriate. 900 o Acked Bundle Notification: Bundle agent informs routing agent 901 whether a bundle has been delivered to its final destination and time 902 of delivery. 904 6.4. Producer Mobility 906 As NDN uses a publish/subscribe communication model, where request 907 resolution and data transfer are decoupled, it is especially relevant 908 to solve the problem of data producer mobility. Supporting producer 909 mobility requires, first of all, finding the new location of the 910 source each time data sources move, and, second, updating the name 911 resolution system according to the new location, in order to maintain 912 the consistency of NDN forwarding. 914 This could be achieved by using a dissemination method to efficiently 915 discover data sources by replicating Interest messages in an 916 efficient way that avoids network flooding [Optimal-stopping]. 918 With this new feature the prospective forwarders for a given Interest 919 message are limited in number and carefully selected in terms of 920 three criteria: 922 o Centrality: how well connected a node is in the network. The more 923 central a node is, the bigger the chances are to find a data source. 925 o Reliability: the likeliness of a node does not drop messages. The 926 more reliable a node is, the least probable is that the Interest 927 message will be discarded. 929 o Similarity: how alike the contacted candidate node is in terms of 930 shared acquaintances. The less similar, the more likely is that it 931 will find different nodes in the future. 933 In the current version of DABBER, the degree of diffusion of Interest 934 packets depends on the logic used to update the RIB on NFD (Increase 935 diversity, Downward Path Criterion, Downward Path Criterion 936 extension). It may happen that the diffusion degree could still lead 937 to some overhead. In this case DABBER could be extended to allow 938 nodes to select the most suitable node among all of the neighbors to 939 forward the Interest message based on an optimal stopping approach. 940 This strategy relies on the existence of an optimal set of stopping 941 values such that the nth discoverer node for a certain Interest 942 message is the first contacted node which is the best of all the 943 previously explored nodes, if the node has contacted the first 944 stopping value. If this node is not found, then it will be the first 945 node which is the second best of all the previous nodes, if the node 946 has contacted the second stopping value, and so on. Otherwise, if 947 these nodes are not found, then, the nth discoverer node will be the 948 last nth node before reaching the last contacted node. This makes 949 the dissemination of the Interest messages in Mobile NDNs efficient, 950 even, and pervasive all over the network, increasing the delivery 951 ratio while decreasing the network overhead. 953 7. Security Considerations 955 DABBER follows the CCN/NDN security framework built on public-key 956 cryptography, allows it to secure the exchange of routing messages, 957 by being able of verifying the authenticity of routing messages. 958 Moreover, DABBER ensures the right level of privacy of the involved 959 entities, who provide local information to support routing decisions. 961 Routing security can be achieved not only by signing routing 962 messages, but also by allowing the usage of multiple paths, as done 963 by DABBER: when an anomaly is detected routers can retrieve the data 964 through alternative paths. 966 Besides the presented security and privacy considerations, the issue 967 of Denial of Service (DoS) needs to be properly addressed. An 968 example is when a malicious user sends a high rate of broadcast 969 messages aiming to exhaust available forwarding resources. 971 The remainder of this section provides initial insights about the 972 methods used by DABBER to ensure the authenticity, confidentiality of 973 the routing message exchange as well as the privacy of the involved 974 entities. 976 7.1. Authenticity 978 DABBER routing messages are carried in Data packets containing a 979 signature. Hence, a DABBER device can verify the signature of each 980 routing message to ensure that it was generated by the claimed origin 981 node and was not tampered with during dissemination. For this 982 purpose, DABBER makes use of a hierarchical trust model for routing 983 to verify the keys used to sign the routing messages. 985 DABBER can model a trust management as a five-level hierarchy, 986 although reflecting a different administrative structure: represents 987 the authority responsible by the international transit network 988 allowing roaming services; represents the operator providing the 989 mobile service; represents the network site of the mobile operator 990 where the node is registered; represents the mobile equipment. Each 991 node can create a DABBER process that produces LSAs. 993 Since keys must be retrieved in order to verify routing updates, 994 DABBER allows each node to retrieve keys from its neighbors. This 995 means that a DABBER node will use the Interest/Data exchange process 996 to gather keys from all its direct neighbors. Upon the reception of 997 an Interest of the type //broadcast/KEYS each neighbor looks up the 998 requested keys in their local key storage and returns the key if it 999 is found. In case a neighbor does not have the requested key, the 1000 neighbor can further query its neighbors for such key. The used key 1001 retrieval process makes use of a broadcast forwarding strategy, 1002 stopping at nodes who either own or cache the requested keys. 1004 7.2. Confidentiality 1006 Although being deployed under the control of an operator, DABBER 1007 allows its network to be extended beyond the reach of its 1008 infrastructure network, into scenarios where wireless communications 1009 between involved DABBER devices/router may be spoofed. Hence, DABBER 1010 requires routing data confidentiality to ensure the setup of a secure 1011 communication topology. 1013 DABBER basic approach relies on the usage of encryption to protect 1014 the confidentiality of routing messages. By taking advantage of the 1015 semantically meaningful names DABBER relies on approaches such as 1016 Named-based Access Control (NAC) [NAC]. NAC provides content 1017 confidentiality and access control based on a combination of 1018 symmetric and asymmetric cryptography algorithms, while using NDN's 1019 data-centric security and naming convention to automate data access 1020 control. 1022 Being implemented in wireless devices that may energy constraint, it 1023 will be important to verify the efficiency of the cryptographic 1024 solution, namely since the generation of asymmetric key pairs as well 1025 as the symmetric and asymmetric encryption/decryption operations may 1026 be expensive in terms of the usage of resources. 1028 7.3. Privacy 1030 In DABBER, forwarding decisions are taken into account using 1031 different metrics such as centrality and similarity. While these 1032 metrics may be efficient in terms of node selection, they can breach 1033 privacy of network users carrying networked devices by inferring 1034 social related information such as position inside groups, as well as 1035 information about the devices themselves. 1037 If exchanged as clear text, the information carried in routing 1038 metrics may potentially compromise the privacy of users. A way of 1039 preserving the privacy of the users in DABBER could pass by using 1040 homomorphic encryption for information-centric wireless Ad Hoc 1041 Networks. 1043 With homomorphic encryption forwarding decisions are made by 1044 performing calculations on encrypted forwarding metric values without 1045 decrypting them first, while maintaining low overhead and delays. As 1046 a result, forwarding decisions can be taken preserving the user's 1047 privacy. For these purposes, homomorphic encryption is extremely 1048 useful. This cryptographic scheme allows computations on ciphertexts 1049 and generates encrypted results that, when decrypted, match the 1050 results of the operations as if they had been performed on 1051 plaintexts. 1053 8. IANA Considerations 1055 This document has no actions for IANA. 1057 9. Acknowledgments 1059 The research leading to these results received funding from the 1060 European Union (EU) Horizon 2020 research and innovation programmer 1061 under grant agreement No 645124(Action full title: Universal, mobile- 1062 centric and opportunistic communications architecture, Action 1063 Acronym: UMOBILE). 1065 10. References 1067 10.1. Normative References 1069 [DABBER18] 1070 Mendes, P., Sofia, R., Soares, J., Tsaoussidis, V., and S. 1071 Diamantopoulos, "Information-centric Routing for 1072 Opportunistic Wireless Networks", in Proc. of ACM 1073 Information Centric Networking , September 2018. 1075 [DABBER18-1] 1076 DABBER Development Team, "DABBER Source Code", 1077 https://github.com/COPELABS-SITI/ndn-opp/tree/dabber , 1078 September 2020. 1080 [DABBER18-2] 1081 DABBER Development Team, "DABBER Android", 1082 https://play.google.com/store/apps/ 1083 details?id=pt.ulusofona.copelabs.ndn , September 2020. 1085 [NDN-OPP] Tavares, M. and P. Mendes, "NDN-Opp: Named-Data Networking 1086 in Opportunistic Networks", Technical Report COPE-SITI-TR- 1087 18-01 , January 2018. 1089 [NFD] A. Afanasyev, et al, "NFD Developer's Guide", NDN 1090 Technical Report NDN-001 , October 2010. 1092 10.2. Informative References 1094 [ChronoSync] 1095 Zhu, Z. and A. Afanasyev, "Lets ChronoSync:Decentralized 1096 Dataset State Synchronization in Named Data Networking", 1097 in Proc. IEEE ICNP , October 2013. 1099 [Dlife] Moreira, W., Mendes, P., and S. Sargento, "Opportunistic 1100 Routing based on daily routines", in Proc. of IEEE WoWMoM 1101 workshop on autonomic and opportunistic communications, 1102 San Francisco, USA , June 2012. 1104 [Dlife-draft] 1105 Moreira, W., Mendes, P., and E. Cerqueira, "Opportunistic 1106 Routing based on Users Daily Life Routine", IETF Internet 1107 Draft (draft-moreira-dlife-04) , May 2014. 1109 [NAC] Z. Zhang, et al, "NAC: Automating Access Control via Named 1110 Data", in IEEE MILCOM , October 2018. 1112 [NDN-emergency] 1113 Tavares, M., Aponte, O., and P. Mendes, "Named-data 1114 Emergency Network Services", in ACM MOBISYS, Munich, 1115 Germany , June 2018. 1117 [NDN-OPP-Android] 1118 NDN-OPP Development Team, "NDN-OPP Android", 1119 https://github.com/COPELABS-SITI/ndn-opp , September 2020. 1121 [NDN-opportunisticnets] 1122 Dynerowicz, S. and P. Mendes, "Named-Data Networking in 1123 Opportunistic Networks", ACM ICN, Berlin, Germany , 1124 September 2017. 1126 [OI] Lopes, L., C. Sofia, R., Mendes, P., and W. Moreira, "Oi! 1127 Opportunistic Data Transmission Based on Wi-Fi Direct", in 1128 Proc. of IEEE INFOCOM , April 2016. 1130 [Optimal-stopping] 1131 Borrego, C., Amado, M., Molinaro, A., Mendes, P., C. 1132 Sofia, R., Magaia, N., and J. Borrel, "Forwarding in 1133 Opportunistic Information-Centric Networks: An Optimal 1134 Stopping Approach", IEEE Communications Magazine, 58(5), 1135 56-61 , 2020. 1137 [PartialSync] 1138 Zhang, M., Lehman, V., and L. Wang, "PartialSync:Efficient 1139 Synchronization of a Partial Namespace in NDN", NDN 1140 Technical Report NDN-0039 , June 2016. 1142 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 1143 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 1144 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 1145 April 2007, . 1147 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 1148 Specification", RFC 5050, DOI 10.17487/RFC5050, November 1149 2007, . 1151 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 1152 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 1153 "Information-Centric Networking: Baseline Scenarios", 1154 RFC 7476, DOI 10.17487/RFC7476, March 2015, 1155 . 1157 [Scorp] Moreira, W., Mendes, P., and S. Sargento, "Social-aware 1158 Opportunistic Routing Protocol based on User's 1159 Interactions and Interests", in Proc. of AdhocNets, 1160 Barcelona, Spain , October 2013. 1162 [Umobile] C. Sarros, et al, "Connecting the Edges: A Universal, 1163 Mobile centric and Opportunistic Communications 1164 Architecture", IEEE Communication Magazine , February 1165 2018. 1167 [UmobileD45] 1168 R. Sofia, et al, "UMOBILE D45 - Report on Data Collection 1169 and Inference Models", Umobile Technical Report , 1170 September 2018. 1172 Authors' Addresses 1174 Paulo Mendes (editor) 1175 Airbus 1176 Willy-Messerschmitt Strasse 1 1177 Munich 81663 1178 Germany 1180 Email: paulo.mendes@airbus.com 1181 URI: http://www.paulomilheiromendes.com 1183 Rute C. Sofia 1184 fortiss GmbH 1185 Guerickestrasse 25 1186 Munich 80805 1187 Germany 1189 Email: sofia@fortiss.org 1190 URI: http://www.rutesofia.com 1191 Vassilis Tsaoussidis 1192 Democritus University of Thrace 1193 University Campus 1194 Komotini 69100 1195 Greece 1197 Email: vtsaousi@ee.duth.gr 1199 Carlos Borrego 1200 Autonomous University of Barcelona 1201 Department of Information and Communications Engineering 1202 Bellaterra 08193 1203 Spain 1205 Email: carlos.borrego@uab.cat