idnits 2.17.1 draft-mendes-icnrg-dabber-04.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 date (March 15, 2020) is 1503 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1614 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Mendes, Ed. 2 Internet-Draft Airbus 3 Intended status: Experimental R. Sofia 4 Expires: September 16, 2020 fortiss GmbH 5 V. Tsaoussidis 6 Democritus University of Thrace 7 C. Borrego 8 Autonomous University of Barcelona 9 March 15, 2020 11 Information-centric Routing for Opportunistic Wireless Networks 12 draft-mendes-icnrg-dabber-04 14 Abstract 16 This draft describes the Data reAchaBility BasEd Routing (DABBER) 17 protocol, which aims to extend the operation of distributed 18 Information Centric Networking frameworks to opportunistic wireless 19 networks such as Delay Tolerant Networks. By "opportunistic wireless 20 networks" it is meant multi-hop wireless networks where finding an 21 end-to-end path between any pair of nodes at any moment in time may 22 be a challenge. The goal is to assist in better defining 23 opportunities for the transmission of Interest and Data packets in a 24 store-carry-and-forward manner, based on a combination of proactive 25 and reactive approaches. The document presents an architectural 26 overview of DABBER followed by the specification of the proactive 27 approach based on the dissemination of name-prefix information, and 28 the reactive approach based on the encounters probability. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 16, 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 66 1.2. Assumptions and Requirements . . . . . . . . . . . . . . 5 67 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 68 2. DABBER Architecture . . . . . . . . . . . . . . . . . . . . . 6 69 2.1. Routing and Forwarding . . . . . . . . . . . . . . . . . 6 70 2.2. Contextual Awareness . . . . . . . . . . . . . . . . . . 8 71 2.3. Device Identifiers . . . . . . . . . . . . . . . . . . . 9 72 2.4. Faces . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 2.4.1. OPPFace . . . . . . . . . . . . . . . . . . . . . . . 10 74 2.4.2. DTNFace . . . . . . . . . . . . . . . . . . . . . . . 12 75 2.4.3. CMFace . . . . . . . . . . . . . . . . . . . . . . . 13 76 3. Routing of Name Prefixes . . . . . . . . . . . . . . . . . . 13 77 3.1. LSA Dissemination . . . . . . . . . . . . . . . . . . . . 13 78 3.2. Multiple path Computation . . . . . . . . . . . . . . . . 15 79 3.2.1. Name Prefix Cost Computation . . . . . . . . . . . . 16 80 3.2.2. Update of DABBER internal routing table and LSDB . . 18 81 3.2.3. Update of RIB on NFD . . . . . . . . . . . . . . . . 19 82 3.3. Routing Operation Example . . . . . . . . . . . . . . . . 19 83 4. Forwarding of Interest Packets . . . . . . . . . . . . . . . 21 84 5. Forwarding of Data Packets . . . . . . . . . . . . . . . . . 22 85 5.1. Time-Evolving Contact Duration . . . . . . . . . . . . . 24 86 5.2. TECD Importance . . . . . . . . . . . . . . . . . . . . . 25 87 5.3. Forwarding strategy . . . . . . . . . . . . . . . . . . . 26 88 5.3.1. Basic Strategy . . . . . . . . . . . . . . . . . . . 26 89 5.3.2. Prioritized Strategy . . . . . . . . . . . . . . . . 27 90 6. Protocol Addictional Functionality . . . . . . . . . . . . . 27 91 6.1. Adjustment to data source mobility . . . . . . . . . . . 27 92 7. Interoperability . . . . . . . . . . . . . . . . . . . . . . 28 93 7.1. Interoperability with ICN routing . . . . . . . . . . . . 28 94 7.2. Interoperability with broadcast based forwarding . . . . 29 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 97 8.1. Authenticity . . . . . . . . . . . . . . . . . . . . . . 30 98 8.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 30 99 8.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 31 100 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 101 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 102 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 103 11.1. Normative References . . . . . . . . . . . . . . . . . . 32 104 11.2. Informative References . . . . . . . . . . . . . . . . . 32 105 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 108 1. Introduction 110 In a networking scenario where an increasing number of wireless 111 systems, such as end-user nodes and mobile edge nodes, are being 112 deployed, there are two networking paradigms that are highly 113 correlated to the efficiency of pervasive data sharing: Information- 114 Centric Networking (ICN)[RFC7476], and Delay tolerant Networking 115 (DTN) [RFC4838]. The latter concerns the capability of exploiting 116 any potential wireless communication opportunity to exchange data in 117 a multi-hop wireless networks, where it is difficult to find an end- 118 to-end path between any pair of nodes at any moment in time. 120 Combining ICN and DTN is relevant to efficiently extend the 121 applicability of information-centric networking to novel scenarios, 122 such as affordable pervasive access; low cost extension of access 123 networks; edge computing; vehicular networks. 125 This document describes the Data reAchaBility BasEd Routing (DABBER) 126 routing protocol aiming to support information-centric delay-tolerant 127 networks (ICDTN) [ICN-routing-opp]. These networks are operationally 128 located on the Internet fringes. In such areas, networking 129 experiences intermittent connectivity and variable availability of 130 nodes due to their movement and/or due to other constrains, e.g., 131 limited battery, storage, and processing. 133 It is our understanding that routing in such wireless environments 134 needs to be done based on strategies that take into consideration, at 135 a network level, the context of wireless nodes (e.g. availability, 136 centrality), and not just the history of contacts among wireless 137 nodes. The goal is to assist in better defining opportunities for 138 the transmission of Interest and Data packets over time and space: 139 DABBER focus on a data plane similar to the one use by CCN/NDN [NFD], 140 since these are well established distributed ICN frameworks. 142 DABBER brings ICN and DTN together by combining a proactive approach 143 to forward Interest packets based on the dissemination of name-prefix 144 information, with a reactive approach to forward Data packets based 145 on information collected about custodians and based on encounters 146 probability. The dissemination of name-prefixes and the 147 dissemination of Data packets is done based on the context of nodes, 148 and not just the history of contacts among wireless nodes. 150 1.1. Applicability 152 DABBER is being developed to allow the deployment of ICDTN where 153 nodes and links can be intermittently available, such as in the case 154 of emergency situations [NDN-emergency]. From an end-to-end 155 perspective we can consider two scenarios: the NDN wireless network 156 is at the fringes of the NDN core; the NDN wireless network can 157 interconnect different NDN fixed networks. 159 While the latter may support applicability scenarios typical of 160 Delay-Tolerant Networks (DTN) for instance tunneling traffic over an 161 area lacking network deployment, the former allows the extension of 162 the applicability of information-centric networking to novel 163 scenarios such as affordable pervasive data access, low cost 164 extension of access networks, edge computing, and vehicular networks: 166 Affordable pervasive data access: This scenario encompasses the 167 implementation of NDN in personal mobile nodes (e.g. smartphones) 168 allowing users to share data and messaging services by exploiting 169 existing intermittent wireless connections (e.g. Wi-Fi, Wi-Fi 170 direct) in environment without/or limited Internet access. 172 Low cost extension of access networks: This scenario refers to the 173 usage of wireless nodes (mobile or fix) to extend the reach of an NDN 174 networks while reducing CAPEX costs. 176 Edge/Fog computing: This scenario is related to the efforts being 177 done to bring cloud computing closer to the end-users. This scenario 178 encompasses a large set of heterogeneous (wireless and sometimes 179 autonomous) decentralized nodes able of communicating, directly or 180 via an infrastructure, in order to perform storage and processing 181 tasks without the intervention of third parties. This scenario deals 182 with nodes that might not be continuously connected to a network, 183 such as laptops, smartphones, tablets and sensors, as well as nodes 184 that may be intermittently available due to scarce resources, such as 185 wireless access routers and even Mobile Edge Computing (MEC) servers. 187 V2X networks: This scenario deals with the intermittent connectivity 188 between vehicles as well as between vehicles and the infrastructure. 190 1.2. Assumptions and Requirements 192 DABBER relies on the following assumptions: 194 o Mobile nodes are able of exploiting wireless connectivity. 196 o Mobile nodes can be a source and destination of data, being able of 197 operating as a router: there is not a clear distinction, in terms of 198 routing process, between sources, destinations, and routers. 200 o Mobile nodes may decide to be the custodians of data transmissions 201 based on a set of criteria such as local available resources. 203 o In DTNs it is not possible to know the complete network topology. 205 o In DTNs it is not efficient to flood the network, as shown by all 206 prior solutions based on controlled packet replication forwarding 207 ([RFC6693][Dlife][Scorp][Dlife-draft]) instead of broadcast as used 208 in Epidemic routing. 210 o Selecting the best set of neighbors to replicate packets to, may 211 not be efficient if based only on connectivity based information 212 (e.g. inter-contact times, contact duration). 214 In terms of requirements: 216 o Routing informaiton must be exchanged based on Interest / Data 217 messages. 219 o Routing information should be used to distribute only name prefix 220 reachability, since building a network topology based on adjacency 221 information is not feasible in an opportunistic network. 223 o Routing information must be distributed to multiple next-hops based 224 on local information that encodes data reachability. 226 o A synchronization mechanism my be used to exchange routing 227 information among neighbor node. 229 o Forwarding of Interest packets must take into account the 230 information stored in the Forwarding Information Base (FIB). 232 o Interest packets must carry information about the data consumer ID. 234 o Interest packets should carry information about custodians IDs. 236 o Forwarding of Interest must take into account the information 237 stored in the Forwarding Information Base (FIB). 239 o Forwarding of Data packets must take into account the information 240 stored in the Pending Information Table (PIT). 242 o The PIT must store information about the data consumer ID. 244 o The PIT may store information about custodians IDs. 246 o Data sources must set the validity of name prefixes - validity v - 247 as an integer that represents the expiration date of the data. 249 1.3. Conventions 251 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 252 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 253 document are to be interpreted as described in RFC 2119. In this 254 document, these words will appear with that interpretation only when 255 in ALL CAPS. Lower case uses of these words are not to be 256 interpreted as carrying significance described in RFC 2119. 258 2. DABBER Architecture 260 This section presents an overview of the DABBER protocol 261 architecture. DABBER relies on the same message formats, message 262 exchange process, and same data structures made available by CCN/NDN: 263 Routing Information Base (RIB); Forwarding Information Base (FIB); 264 Pending Intent Table (PIT), while adding new elements such as two new 265 faces (OPPFace and DTNFace), a contextual manager, and distinct 266 forwarding strategies for Interests and Data packets. On contrary to 267 what happens in CCN/NDN, in DTN Data packets may not be able to 268 follow the same path followed by Interest packets. 270 TBD 272 Figure 1: DABBER Architecture. 274 2.1. Routing and Forwarding 276 DABBER aims to assist in better defining opportunities for the 277 transmission of Interest and Data packets in a store-carry-and- 278 forward manner, based on a combination of proactive and reactive 279 approaches. DABBER defines a proactive routing approach based on the 280 dissemination of name-prefix information, which are use to identifie 281 suitable next hops to reach a certain data object. This location can 282 be the source of data or any other custodian. The proactive routing 283 scheme aims to reduce the time needed to reach the requested data 284 object. Without a mechanism able of disseminating routing 285 information, devices would need to use try and error approach based 286 on a broadcast forwarding strategy. Besides the extra delay in 287 finding the requested data, such strategy will increase the amount of 288 used networked resources. As shown in figure 2, the proposed 289 proactive approach is able of populating the FIB with a list of next 290 hops towards each name prefix. This is done based on the information 291 collected from neighbor nodes and stored in the RIB. 293 Node A Node B 294 +----------+ +------------+ 295 N - |1 2| - N----- |1 2| 296 | | | | 297 |3 4| - N |3 4| 298 +----------+ | +------------+ 299 | Node C 300 | +------------+ 301 ------ |1 2| 302 | | 303 |3 4| 304 +------------+ 306 RIB FIB 307 +----------------------------+ +-----------------------+ 308 |Prefix Name | Face | Cost | | Prefix Name | Faces | 309 +----------------------------+ +-----------------------+ 310 | N | 2 | 3 | | N | 2,1,4 | 311 | N | 4 | 10 | | | | 312 | N | 1 | 5 | +---------------------- + 313 +----------------------------+ 315 PIT 316 +--------------------------------------------+ 317 | Interest | Face | Requester | Custodians | 318 +--------------------------------------------+ 319 | N | 1 | DID1 | DID2;DID3 | 320 | | 3 | DID4 | | 321 +--------------------------------------------+ 323 Figure 2: RIB, FIB and PIT on node A. 325 The FIB illustrated in Figure 2 is used by a forwarding strategy 326 (c.f. section 4.1) used to transmit Interest packets in the direction 327 of one of more copies of the requested data. This strategy is 328 perfectly aligned with the current CCN/NDN architecture. However the 329 same does not happen with the forwarding of Data packets. On CCN/NDN 330 Data packets are transmited in the Faces listed in the PIT for the 331 name carried in the Data packet. Although this breadcumb approach 332 works on a stable/fixed network, the same does not happen in a DTN, 333 since faces from which Interest packets were received may be down. 334 In this case DABBER forwards Data packets toward the DID of the data 335 requester (mandatory), or to any identified custodian (Optional). 336 This is done by using new forwarding strategy for Data packets based 337 on the encounters probability and contextual awareness, as described 338 in section 4.2. 340 The inclusion of a forwarding strategy for Data packets is already a 341 difference from the CCN/NDN architecture. To implement such 342 forwarding strategy some changes need to be included to handle 343 Interest packets (c.f. section 4.1) and to the PIT structure, namely: 345 o The Interest packet includes the DID of the requester device, as 346 well as of any visited custodian device. For this the 347 ApplicationParameter optional field can be used. 349 o The in-record of the PIT entry related to the Interest needs to 350 hold the following fields: DID of resquester; list of DID of 351 custodians, as illustrated in Figure 2. 353 Given the multi-path nature of DABBER, the incoming Face might appear 354 among the potential next-hops for a given name prefix. For this 355 reason, DABBER applies the Incoming Face Exclusion principle 356 [Loop-free] in order to prevent forwarding packets back though the 357 Face them came from, thus removing two-hop loops. 359 Furthermore, in order to detect longer forwarding loops (more than 360 two hops), DABBER relies on the nonce-based detection scheme 361 available in CCN/NDN in order to drop a looping packet as soon as it 362 is received the second time. 364 In addition, DABBER considers a loop removal mechanism, which takes 365 care of disabling the Face responsible for the looping once it is 366 detected. 368 2.2. Contextual Awareness 370 DABBER defines routing and forwarding strategies that take into 371 consideration, at a network level, the context of wireless nodes, and 372 not just the history of contacts among wireless nodes. Contextual 373 information is obtained in a self-learning approach, by software- 374 based agents running in each networked device, and not based on 375 network wide orchestration. Contextual agents are in charge of 376 computing node and link related costs concerning availability and 377 centrality metrics. Contextual agents interact with DABBER via a 378 well-defined interface: the contextual self-learning process is not 379 an integrating part of the DABBER routing framework. 381 The contextual agent (named Contextual Manager [UmobileD45]) 382 installed in each device can therefore be seen as an end-user 383 background service that seamlessly captures wireless data to 384 characterize the affinity network (roaming patterns and peers' 385 context over time and space) and the usage habits and data interests 386 (internal node information) of a node. Data is captured directly via 387 the regular MAC Layer (e.g., Wi-Fi, Bluetooth, LTE) as well as via 388 native applications for which the user configures interests or other 389 type of personal preferences. For instance, an application can 390 request a one-time configuration of categories of data interests 391 (e.g., music, food). 393 Based on the defined interface, DABBER is able of querying the local 394 Contextual Manager about the characteristics of neighbor nodes, based 395 on three types of information: i) Node availability (metric A); ii) 396 Node centrality (metric C); iii) Node similarity (metric S): 398 o Node Availability (A) gives an estimate of the node availability 399 based on the usage of internal resources over time and space, such as 400 the time spent per application category (e.g. per day), as well as 401 the usage of physical resources (battery status; CPU status, etc). 403 o Node Centrality (C) provides awareness about the node's affinity 404 network neighborhood context. This means that a list is kepted with 405 the following information about each neigbour: neighbour's node 406 degree; Frequency of contacts between the neighbor and other nodes; 407 Duration of each contact between the neighbor and other nodes; 408 Importance of encountered nodes. 410 o Node similarity (S) provides awareness about a node's similarity 411 towards neighbor nodes. This means that a list is kepted with the 412 following information about each neigbour: Packet Error Rate of the 413 wireless link towards the neighbor; Frequency of contacts with 414 neighbor; Duration of each contact with neighbour. 416 The Contextual Manager keeps values for the mentioned metrics for 417 different periods of time. Encountered nodes can be of different 418 types, such as other mobile devices or wireless access points for 419 instance. 421 2.3. Device Identifiers 423 With DABBER, networked devices (producers, consumers, routers) are 424 identified by variable-length identifiers, such as End-points 425 Identifiers in DTN and hierarchical names in CCN/NDN. Using an DID, 426 a node is able to determine the source of a Interest packet as well 427 as a potential set of custodians that may help the data transmission 428 process. Each device is required to have at least one DID that 429 uniquely identifies it. 431 Device ID are expressed syntactically as a Uniform Resource 432 Identifier (URI) [RFC3986]. The URI syntax has been designed as a 433 way to express names or addresses for a wide range of purposes, and 434 is therefore has been used to construct names for DTN endpoints, as 435 well as hierarchical names in CCN/NDN. In URI terminology, each URI 436 begins with a scheme name. The scheme name is an element of the set 437 of globally-managed scheme names maintained by IANA. Lexically 438 following the scheme name in a URI is a series of characters 439 constrained by the syntax defined by the scheme. This portion of the 440 URI is called the scheme-specific part, and can be quite general. 442 Being based on UIRs, device IDs may be kept quite flexible. They 443 might, for example, be constructed based on DNS names, or might look 444 like expressions of interest or intentional names. For instance DIDs 445 may be set up to reflect the network operator to which the mobile 446 node belongs to and to the home site, in case the mobile operator has 447 more than one operational site. In this case, when a mobile node is 448 used outside its home network and some of its requests reach an 449 access point of a visited mobile network, the latter may recognize 450 may be able of checking if there is a roaming agreement between the 451 home network and one of the networks of the visited operator. If so 452 the request may be routed towards an international transit network. 454 Based on an URI scheme that may reflect a network operator, the 455 information included in the DID may be used to select next hops 456 belonging to the same operator network, or nodes that have the same 457 home network. It is assumed that a DTN is build based on wireless 458 direct connectivity between nodes that may belong to different 459 operators, but that may have roaming patterns that allows them to 460 have frequent wireless contacts. 462 2.4. Faces 464 DABBER leverages the concept of Faces in CCN/NDN to adapt its 465 operation to the intermittent property of wireless connections. This 466 is done by the implementation of two new type of faces, called 467 Opportunistic Face (OPPFace) and Delay Tolerant Networking Face 468 (DTNFace). Besides these two communication interfaces, DABBER keeps 469 a face to the Contextual Manager (CMFace). 471 2.4.1. OPPFace 473 An OPPFace is based on a system of packet queues to hide intermittent 474 connectivity: instead of dispatching packets from the FIB, the 475 OPPFace is able of delaying packet transmission until the wireless 476 face is actually connected. OPPFaces are kept in the Face Table of 477 the forwarder and their state reflects the wireless connectivity 478 status: they can be in an Up or Down state, depending upon the 479 wireless reachability towards neighbor nodes. Based on this 480 information, the OPPFace decides whether to simply queue packets 481 (when OPPFace is down) or flush the queue (when OPPFace is up). 482 Since packet queuing is concealed inside OPPFaces, existing 483 forwarding strategy do not need to be changed. 485 OPPFaces can be implemented by using any direct wireless 486 communication mode. The current specification of DABBER considers 487 Wi-Fi (Infrastructured, Ad-Hoc, and Direct mode). 489 The current version of the NDN port to opportunitic networks based on 490 Android (NDN-OPP) makes usage of group communications provided by Wi- 491 Fi Direct [NDN-OPP][NDN-opportunisticnets] (NDN-OPP GitHub code [1]). 492 In this case there is a one-to-one correspondence between an OPPFace 493 and a neighbor node (for each node detected in a Wi-Fi Direct Group, 494 a new instance of an OPPFace is created). In this peer-to-peer 495 scenario, OPPFaces can be used in two transmission modes: connection- 496 oriented, in which packets are sent to a neighbor node via a reliable 497 TCP connection over the group owner; connection-less, in which 498 packets are sent directly to a neighbor node during the Wi-Fi direct 499 service discovery phase. In the latter case data transmission is 500 limited to the size of the TXT record (900 bytes for Android 5.1 and 501 above). This type of communication is used to exchange small packets 502 that require fast transmission (e.g. emergency apps, Chronosync 503 status messages). The connection-less solution allows peers to 504 exchange a short number of bytes without the establishment of a TCP 505 socket. 507 In the peer-to-peer scenario of Wi-Fi direct, DABBER operates as 508 follows: routing information is shared among all members of a Wi-Fi 509 direct group, while Interest Packets are forwarded to specific 510 neighbors. With Dabber it is the carrier of an Interest packet that 511 decides which of the neighbors will get a copy of the Interest 512 packet. Hence, with the current implementation of NDN-OPP, DABBER 513 places a copy of the Interest packet in the OPPFaces of selected 514 neighbors. In what concerns the dissemination of routing 515 information, it is ensured by: i) node mobility, meaning that nodes 516 carry such information between Wi-Fi direct groups; ii) information 517 is passed between neighbor groups via nodes that belong to more than 518 one group. 520 Based on the reception of notifications of Wi-Fi Direct regarding 521 changes in the peers detected in the neighborhood, DABBER is able of 522 updating its internal peer list (Neighbor Table as illustredted in 523 Figure 5). If it is not currently connected to a Wi-Fi Direct Group, 524 it performs a selection heuristic to determine which node to connect 525 to. The motivation behind this selection process is to attempt to 526 minimize the number of Wi-Fi Direct Groups in a certain area given 527 that nodes can only transmit packets within the Group they are 528 currently connected to. 530 By defining OPPFaces implemented based on a broadcast link layer such 531 as ad-hoc Wi-Fi, DABBER will need to create only one OPPFace in each 532 networked device. Such OPPFace would be used to exchange packets 533 with any neighbor node, making use of the overhearing property of the 534 wireless medium. Since with DABBER, it is the carrier that decides 535 which of the neighbors are entitle to get a certain Interest packet, 536 DABBER would need to encode in the Interest packet information about 537 the ID of the neighbors that should process the overheard Interest 538 packet. 540 2.4.2. DTNFace 542 By defining a DTNFace implemented based on the bundle layer [RFC5050] 543 DABBER will make use of the end-to-end protocol, block formats, and 544 abstract service description for the exchange of messages (bundles) 545 described in the DTN architecture. A DTNFace provides a robust 546 communications platform for the transmission of Data packets towards 547 the consumer node, making usage of any available custodian nodes. 549 The bundle protocol [RFC5050] introduces the concept of a "bundle 550 agent" that manages the interface between applications and the 551 "convergence layers" that provide the transport of bundles between 552 nodes during communication opportunities. DABBER defines a DTNFace 553 that extends the bundle agent aiming to control the actions of the 554 bundle agent during communication opportunities. 556 The new DTNFace aims to control the reception and delivery of 557 bundles, which are placed in a queue during the forwarding of Data 558 packets. The DTNFace allows the routing process to be aware of the 559 bundles placed at the node, and allows it to inform the bundle agent 560 about the bundles to be sent to a neighbor node. Therefore, the 561 bundle agent implemented in the DTNFace needs to provide the 562 following interface/functionality to the forwarding process: 564 Get Bundle List: Returns a list of the stored bundles and their 565 attributes to the routing agent. 567 Send Bundle: Notifies the bundle agent to send a specified bundle. 569 Drop Bundle Advice: Advises the bundle agent that a specified bundle 570 may be dropped by the bundle agent if appropriate. 572 Acked Bundle Notification: Bundle agent informs routing agent whether 573 a bundle has been delivered to its final destination and time of 574 delivery. 576 2.4.3. CMFace 578 TBD 580 3. Routing of Name Prefixes 582 Being developed to operate in DTNs, DABBER does not rely on the 583 dissemination of Adjacency Link State Advertisements (LSAs) that 584 reflect the status of the links towards neighbor nodes; DABBER only 585 requires the dissemination of Prefix LSAs, and does not require the 586 computation of shortest paths. DABBER replaces the path cost used by 587 protocols used for fixed networks with a data reachability cost 588 reducing the impact that topological changes would have on the 589 stability of routing information. 591 The computation of data reachability costs towards different data 592 sources, based on the local dissemination of name prefixes, aims to 593 avoid flooding the wireless network with Interest packets that would 594 otherwise be broadcast to all potential data sources. 596 3.1. LSA Dissemination 598 DABBER makes use of Interest/Data packets to have neighbour devices 599 exchanging Prefix LSAs. This means that while IP-based routing 600 protocols push updates to other routers, DABBER devices pull updates. 601 DABBER can use any underlay communication channels (e.g., TCP/UDP 602 tunnels, Link layer TXT records) to exchange LSA information. 604 By using Interest/Data packets, DABBER benefits from CCN/NDN built-in 605 data authenticity to exchange routing information: since a routing 606 update is carried in an Data packet and every Data packet carries a 607 signature, a DABBER device can verify the signature of each LSA to 608 ensure that it was generated by the claimed origin node and was not 609 tampered during dissemination. 611 DABBER advertises Prefix LSAs every time a new name prefix is added 612 or deleted to the LSA Data Base (LSDB). Name prefixes are advertised 613 with a cost metric related to the validity of the associated data, as 614 shown in Figure 3. Each LSA used by DABBER has the name 615 /DABBER/LSA/Prefix/. The is described by a 616 scheme based on URIs (c.f. section 2.1); It can be for instance 617 ////. The field is increased 618 by 1 whenever a device creates a new version of the LSA. 620 Prefix LSA 621 +-----------------------------------------------------------------+ 622 | LSA | Number of |Prefix 1|Cost| ... |Prefix N|Cost| Signature | 623 | Name | Prefixes | | | | | | | 624 +-----------------------------------------------------------------+ 626 Figure 3: Prefix LSA format. 628 DABBER disseminates LSAs via a data synchronization mechanism (e.g. 629 ChronoSync [ChronoSync], PartialSync [PartialSync]) of the local 630 LSDB. This peer synchronization approach is receiver-driven, meaning 631 that a device requests LSAs only when it has CPU cycles. Thus it is 632 less likely a device will be overwhelmed by a flurry of updates. In 633 order to reduce the amount of transfered data, DABBER removes 634 obsolete LSAs from the LSDB by periodically refreshing each of its 635 own LSAs by generating a newer version. Every LSA has a lifetime 636 associated with it and will be removed from the LSDB when the 637 lifetime expires. 639 DABBER performs the dissemination of LSAs based on a process able of 640 synchronizing the content of LSDBs. In this sense, all LSAs are kept 641 in the LSDB as a name set, and DABBER uses a hash of the LSA name set 642 as a compact expression of the set. Neighbor nodes use the hashes of 643 their LSA name sets to detect inconsistencies in their sets. For 644 this reason, neighbor nodes exchange hashes of the LSDB as soon as 645 OPPFaces are UP. 647 Current version of DABBER makes use of ChronoSync as synchronization 648 mechanism. Chronosync allows DABBER to define a collection of named 649 data in a local repo as a slice. LSA information is synchronized 650 among neighbor nodes, since Chronosync keeps the repo slice 651 containing the LSA information in sync with identically defined 652 slices in neighboring repositories. If a new LSA name is detected in 653 a repo, ChronoSync notifies DABBER to retrieve the corresponding LSA 654 in order to update the local LSDB. DABBER can also request new LSAs 655 from Chronosync when resources (e.g. CPU cycles) are available. 657 Figure 4 shows how an LSA is disseminated between two neighbor nodes 658 A and B, when the OPPFace is UP. To synchronize the slice 659 representing the LSDB information in the repo, ChronoSync, on each 660 node, periodically sends Sync Interests with the hash of its LSA name 661 set / slice (step 1). When Node A has a new Prefix LSA in its LSDB, 662 DABBER writes it in the Chronosync slice (step 2). At this moment, 663 the hash value of the LSA slide of node A becomes different from that 664 of node B. As a consequence, the Chronosync in node A replies to the 665 Sync Interest of node B with a Sync Reply with the new hash value of 666 its local LSA slice (step 3). The Chronosync in node B identifies 667 the LSA that needs to be synchronized and notifies DABBER about the 668 missing LSA, and updates its LSA name set (step 4). Since DABBER on 669 node B has been notified of the missing LSA, DABBER sends an LSA 670 Interest message to retrieve the missing LSA (step 5). DABBER on 671 node A sends the missing data in a LSA Data message (step 6). When 672 DABBER on node B receives the LSA data, it inserts the LSA into its 673 LSDB. Chronosync on nodes A and B compute a new hash for updated the 674 set and send a new Sync Interest with the new hash (step 7). 676 Node A Node B 677 +----------------------------+ +----------------------------+ 678 | +-------------+ | |+-------------+ | 679 | DABBER | Chronosync | | || Chronosync | DABBER | 680 | +-------------+ | |+-------------+ | 681 +----------------------------+ +----------------------------+ 682 | | Sync Interest (1) | | 683 | |------------------->| | 684 | |<-------------------| | 685 | New LSA (2)| | | 686 |----------> | | | 687 | | Sync Reply (3) | | 688 | |------------------->| | 689 | | | Notify (4) | 690 | | |------------->| 691 | | LSA Interest (5) | | 692 |<-----------|--------------------|--------------| 693 | | LSA Data (6) | | 694 |------------|--------------------|------------->| 695 | | | | 696 | | Sync Interest (7) | | 697 | |------------------->| | 698 | |<-------------------| | 700 Figure 4: LSA exchange process. 702 When more than one LSA needs to be synchronized, the issued LSA 703 Interest packet will contain information about as many LSAs as 704 allowed by the Link maximum transmission unit. In the same sense one 705 LSA Data packet may include also be used to transport information 706 about more than one LSA. 708 3.2. Multiple path Computation 710 By exchanging LSAs each devices becomes aware of potential next-hops 711 via which a name prefix N can be reached with a certain cost k. This 712 cost k represents the probability of reaching a data object 713 identified by N via a Face F, and is related to the time validity of 714 the name prefix (v). The rationale for this approach is that the 715 selection of faces that have a lower cost k (higher validity v) will 716 improve data reachability. The validity of a name prefix is set by 717 the data source as an integer that represents the expiration date of 718 the data. 720 Since different devices can announce the same name prefix, a certain 721 name prefix may be associated with different values of k (as v shall 722 differ) over different faces, depending upon the nodes announcing 723 such name prefix: this lead to the identification of multiple next 724 hops, each one with a different cost. 726 The computation of multiple next hops is performed every time DABBER 727 has a new Name Prefix LSA (or a new version of an existing Name 728 Prefix LSA) in its LSDB. The sequence of operations, as described in 729 the following sub-sections are: 731 1) Computes a new value for the validity of a new Name Prefix in the 732 LSDB; 734 2) Updates DABBER internal routing table; 736 3) Updates the LSDB with the data reachability information (validity) 737 of the current node towards the new Name Prefix; 739 4) Updates the RIB on NDF based on the DABBER internal routing table, 740 following a Downwards Path Criterion (FIB is updated by NFD based on 741 the RIB content). 743 Periodically DABBER updates the validity values of all Name Prefixes 744 in its internal routing table, performing the consequent updates of 745 the local LSDB and RIB, and needed. 747 3.2.1. Name Prefix Cost Computation 749 When DABBER is notified that a new Prefix LSA was registered in the 750 LSDB or an existing Prefix LSA has a new version, it computes a new 751 cost for each name prefix in such Prefix LSA. The cost of a name 752 prefix is given by its validity. 754 DABBER starts by computing a new validity v for a prefix N depending 755 upon the validity announced by the neighbor, and the relevancy of the 756 "relation" between the two neighbor nodes (e.g., node A and node B). 757 The cost of the Name Prefix, passed to NFD, will then be computed as 758 an inversely proportional value to its validity. 760 The relevancy of the "relation" between two neighbor nodes can be, 761 e.g., a measure of similarity [UmobileD45], where similarity is seen 762 as a link measure, i.e., it provides a correlation cost between a 763 node and its neighbors. Or such relation can be weighted based on 764 metrics derived from average contact duration thus allowing a node to 765 adjust the Name Prefix validity based on the probability of meeting 766 the respective neighbor again. The "relation" between two neighbor 767 nodes is computed based on the three metrics (A, C, and S) provided 768 by the local contextual manager, plus a metric computed by DABBER 769 itself: the time reachability. 771 The variable considered by DABBER for the computation of the 772 validity/cost of a Name prefix passed by a neighbor Na are: 774 o Validity (V) - Represents the expiration date of the data 775 associated with the Name Prefix. Currently it is the UNIX Timestamp 776 (10 digit integer). 778 o Similarity metric (S) towards the neighbor Na, as passed by the 779 contextual manager (S >= 0), aiming to select neighbors with whom the 780 current node has a good communication link. 782 o Availability metric (A) towards the neighbor Na, as passed by the 783 contextual manager ( 0 < A < 1), aiming to select neighbors able to 784 process Interest packets with high probability. 786 o Centrality metric (C) towards the neighbor Na, as passed by the 787 contextual manager ( C >= 0), aiming to select neighbors with high 788 probability of successfully forwarding Interest packets. 790 o Time reachability (T) which corresponds to the RTT between sending 791 an Interest packet towards the source of such Name Prefix and 792 receiving a data packet. (0 < T < 1). Currently the value of T is 793 computed as (current time when data packet of received - time when 794 Interest packet was sent) / Validity of Name Prefix. Time 795 reachability allows DABBER to select next hops that lead to closer 796 sources. 798 Neighbor table 799 +------------------------------------------------------+ 800 | Face | Status | Metric C | Metric A | Metric S | 801 +------------------------------------------------------+ 802 | 1 | UP | 6 | 0.3 | 12 | 803 | 2 | DOWN | 4 | 0.8 | 8 | 804 | 3 | UP | 1 | 0.8 | 9 | 805 +------------------------------------------------------+ 807 Figure 5: Neighbor table. 809 The values C, A and S provided by the contextual manager are stored 810 in a Neighbor Table (c.f. Figure 5) indexed by the number of faces. 811 The higher the values of C, A and S, the most preferential a neighbor 812 is. 814 T is measured by observing the flow of Interest and Data packets. 815 Thus, the lowest the T, the most preferential a Face is. Although 816 different nodes may have a different implementation of a face ranking 817 logic, the relevancy of T in comparison to C and A should be higher, 818 since T reflects the measured delay to reach a data source, while C 819 and A are indicators of the neighbors potential as relays. 821 Based on the above mentioned metrics the Validity of a new Name 822 Prefix (V) is updated based on two operations: 824 o V' = f (V, S') = trunc (V * S'), where: 826 S' = (S - Smin) / (Smax - Smin); Smin = 0 and Smax = max (Smax, C) 828 o V'' = f (V', C', A, T) = 0.3* trunc (V' * (C'+A)) + 0.7 * trunc (V' 829 * T), where: 831 C' = (C - Cmin) / (Cmax - Cmin); Where Cmin = 0 and Cmax = max (Cmax, 832 C) 834 3.2.2. Update of DABBER internal routing table and LSDB 836 After the computation of the cost of the Name Prefix taking into 837 account the relation of the current node with the neighbor announcing 838 it, DABBER updates its internal routing table and its LSDB. The 839 information on the routing table will be used to updated the RIB of 840 the local NFD and the information of the LSDB will be announced to 841 all neighbors by Chronosync. 843 To update the Internal routing table, DABBER adds an entry (Na, V'') 844 for the Name Prefix received from Na, where V'' is the computed cost 845 of the name prefix (c.f. section 3.2.1). The routing table is then 846 ordered by name prefix in decreased order of validity. 848 Since the current node will also disseminate the received Name 849 Prefix, DABBER updates the cost of the Name Prefix in the LSA stored 850 in its local LSDB in order to consider the computed value V''. For 851 this, DABBER can use two methods: 853 o Maximal method: Cost of Name Prefix = max (V'', current cost on 854 LSA). 856 o Average method: Cost of Name Prefix = max (average (cost of Name 857 Prefix entries on local routing table), current cost on LSA). 859 3.2.3. Update of RIB on NFD 861 After computing the new value of the cost of a name prefix (c.f. 862 section 3.2.2), DABBER updates the RIB entry of that name prefix with 863 the face over which the Name Prefix LSA was received and the new 864 computed cost. The cost (k) of the Name Prefix to be stored in the 865 RIB is computed based on its validity V'' as k = trunc (100/V''). 867 DABBER updates the RIB on NFD with the cost k based on three possible 868 logics: 870 o Increase diversity - The new Face is included in the RIB entry, if 871 the computed cost k helps to increase diversity of the name prefix. 872 For instance the new cost k is higher than the average costs already 873 stored for that name prefix, affected by a configured diversity 874 constant. This is, this logic include all neighbors with cost = 875 trunc (100/V''), such that 1/V'' - Avr (Costs in RIB for N) > X 876 (predefined value). 878 o Downward Path Criterion - It is a non-equal cost multi-path logic 879 that is guaranteed to be loop-free. Based on the Downward Path 880 Criterion, the X faces (the maximum number X of desirable faces can 881 be defined by configuration) to be considered for a name prefix 882 include the one with the lowest cost k plus X-1 faces that have a 883 cost k lower than the cost that the current node has itself to the 884 name prefix. This is, this logic includes X neighbors with cost = 885 trunc(100/V''), such that cost is the lowest value of 1/V'' or cost < 886 1/ V. 888 o Downward Path Criterion extension - Also considers any face over 889 which the name prefix can be reached with a cost k equal to the cost 890 that the current node has itself to the name prefix. To avoid packet 891 from looping back, there is the need to add a tiebreaker, which 892 assures that traffic only crosses one direction of equal-cost links. 893 This is, this logic includes X neighbors with cost = trunc (100/V''), 894 such that cost is the lowest value of 1/V'' or cost <=1/ V. 896 3.3. Routing Operation Example 898 In order to illustrate the proactive routing method defined by 899 DABBER, let's consider Figure 4, where nodes A, B, and C reside in an 900 ICDTN running DABBER, while nodes E and F are wireless edge routers 901 running another ICN routing protocol; G is a wireless node running 902 DABBER. 904 +--------------------+ 905 | +---+ | 906 | | B | . | 907 | +---+ .2+---+ | +---+ +---+ +---+ 908 |+---+ | C |3 ... | E |....| F |....| G | 909 || A |.......1+---+ | +---+ +---+ +---+ 910 |+---+ | 911 +--------------------+ 913 Figure 6: End-to-end operational example. 915 In our example, Node A starts producing some content derived, for 916 instance, from the use of an application (such as a data sharing 917 application). The produced content is stored in its local Content 918 Store with the name /NDN/video/Lisbon/nighview.mpg. Node B stores in 919 its Content Store a data object with name /NDN/video/Lisbon/ 920 river.mpg, which node B received from a neighbor (meaning that B have 921 already synchronize its LSDB with such a neighbor). 923 Due to the update of the Content Store, the name prefix /NDN/video/ 924 Lisbon/ is stored in the LSDB of node A and B with a validity of 925 864000 and 518400 in the case of node A and B respectively. In the 926 case of node A, the cost k of the name prefix equals the validity v 927 of the data object, e.g., v=864000 seconds (10 days) stipulated by 928 the application. In the case of node B the validity is the result of 929 the computation process described in section 3.2.1. 931 From a routing perspective, storing a name prefix in the local LSDB 932 allows the node to share the respective Prefix LSA on all its Faces, 933 excepting on the Face over which the LSA was previously received. 934 This LSA exchange is done when the OPPFaces are up. This means that 935 Node C, which got a new Prefix LSA from nodes A and B, will: 937 o Update its LSDB with the Prefix LSAs received from node A and node 938 B. 940 o Update its internal routing table with two new entries for the name 941 prefix /NDN/video/Lisbon/, associated with the face towards A (face1) 942 and with the face towards B (face2), after computing the values of V' 943 and V'' for the received validity values: 945 o The validity of the name prefix is updated based on the metric 946 configured for node C: average inter-contact time. 948 o Let's assume that A and C encounter each other frequently, while B 949 and C do not meet frequently. This means that the two entries on the 950 routing table of node C for prefix /NDN/video/Lisbon/ will have a 951 validity/cost for A higher than the one for B. 953 o Update its LSDB with the validity of the current node towards the 954 Name Prefix following the maximal or average methods. 956 o Update the RIB with one new entry for the name prefix /NDN/video/ 957 Lisbon/ with two faces (face 1 and face 2) with a cost inversely 958 proportional to the validity of the Name Prefix. 960 When node C gets in the range of router E (wireless edge router) it 961 will exchange disseminate routing information, based on some 962 interoperability issues need to be considered, as described in 963 section 4. 965 4. Forwarding of Interest Packets 967 In order to support the new forward strategy for Data packets, 968 devices need to collect information about the DID of the requester 969 (mandatory) and of any potential custodian (optional). Therefore, 970 when an Interest packet is received, the following operations need to 971 be performed: 973 o The DIDs found in the ApplicationParameter field of the Interest 974 packet are placed in the PIT entry corresponding to the Face over 975 which the Interest packet was received. 977 o Before forwarding the Interest packet, DABBER will include the DID 978 of the current device if this is a custodian. In this version the 979 role of custodian is pre-configured. This may be revised to include 980 other logics, that may consider the capabilities of the device (e.g. 981 available storage; available energy). 983 Interest packets are forwarded based on the information that is 984 stored in the FIB, which is updated by the NFD based on information 985 stored on the RIB. Independently of the used forwarding strategy, it 986 has to respect the ranking of faces done by DABBER on the RIB. For 987 instance an unicast forwarding strategy will use the most important 988 face (lower cost), while a multicast forwarding strategy will use all 989 the faces indicated for the name prefix. 991 After selecting the best set of faces, a copy of the Interest packet 992 is sent to the OPPFaces of the selected faces. The state of an 993 OPPFace reflects the fact that the corresponding neighbor device is 994 currently reachable or not. Based on this information, the OPPFace 995 decides whether to simply queue the packet or attempt a transmission 996 over the associated Opportunistic Channel. 998 Based on the feedback provided by the wireless channel (e.g. Wi-Fi 999 direct confirmation), the OPPFace can decide to remove the packet 1000 from the queue once it has been passed on to its intended peer. In 1001 case the packet was not passed to the intended peers, a new attend to 1002 forward the packet will be done as soon as the OPPFace is activated: 1003 the OPPFace integrates a mechanism to automatically flush the queue 1004 whenever the face is brought up upon detection of the corresponding 1005 peer being available. 1007 5. Forwarding of Data Packets 1009 By following the operation of CCN/NDN, Data packets are forwarded 1010 based in the information holded in the PIT: the ID of the Faces over 1011 which a copa of the Data packet must be transmitted. In a DTN 1012 network, this setup faces two problems: i) the Face(s) stored in the 1013 PIT may not be active since neighbour devices are not in range; ii) 1014 the breadcumb path may not be available, since in a dynamic network 1015 some of the devices visited by the Interest packet may not be 1016 reachable. 1018 To solve these two problems, DABBER makes usage of a new forwarding 1019 strategy for Data packets by making usage of information stored in 1020 the PIT (which is different from the standard information used by 1021 CCN/NDN) and by making usage of an opportunistic forwarding scheme 1022 aiming to bring the Data packet closer to the requester or to any 1023 available custodian. 1025 The new forwarding strategy works as follows: 1027 o First check if the Face(s) present in the PIT related to that 1028 Interest are active. The Data packet is sent to the OPPFace of each 1029 active Face. This is a procedure similar to the one used by CCN/NDN. 1031 o For all Faces that are not active (OPPFace is down), DABBER uses an 1032 algorithm similar to dlife [Dlife][Dlife-draft] to forward the Data 1033 packet closer to the requester or any custodian. 1035 For all OPPFaces that are not active, DABBER starts by collecting the 1036 DID of the requester of Data, as well as the DID from potential 1037 Custodian from the in-record PIT entry related to that Interest. 1038 Based on that information DABBER will forward the Data packet to any 1039 active neighbour that has high probability to meet any of these DIDs. 1040 This forwarding is done through a DTNFace, which will create a bundle 1041 based on the Data packet to be sent. 1043 To forward Data packets, DABBER applies a social opportunistic 1044 contact paradigm to decide whether bundle replication is feasible. 1045 Its decision is based on social weight (w_(x,y)) towards the bundle's 1046 destination or on the importance (I(x)) of the encountered node 1047 (i.e., potential next forwarder) in the system. 1049 If the encountered node has better relationship with the bundle's 1050 destination than the carrier in a given daily sample, it receives a 1051 bundle copy, since there is a much greater chance for the encountered 1052 node to meet the destination in the future. If relationship to the 1053 bundle's destination is unknown, replication happens only if the 1054 encountered node has higher importance than the bundle's current 1055 carrier. 1057 In order to compute the social weight between nodes and their 1058 importance, DABBER uses parameters that are determined as nodes 1059 interact in the system. A brief explanation of these parameters is 1060 given below: 1062 o CD_(x,y): Refers to the contact duration between nodes, i.e., time 1063 nodes spent in the communication range of one another, which would 1064 allow them to exchange information. Within a given daily sample, 1065 different contacts can happen with varied lengths. 1067 o TCT_(x,y): Refers to the total contact time between nodes within a 1068 given daily sample. It is given by the sum of all CD_(x,y) in that 1069 specific daily sample. 1071 o AD_(x,y): Refers to the average duration of contacts for the same 1072 daily sample over different days. It is a Cumulative Moving Average 1073 (CMA) of the average duration, considering the TCT_(x,y) of the 1074 current daily sample and average duration in the same daily sample of 1075 the previous day, AD_(x,y)_old. 1077 o w_(x,y): Refers to the social weight between nodes at a given daily 1078 sample. It reflects the level of social interaction among such nodes 1079 throughout their daily routines. 1081 o I_(x): Refers to the importance of a node in the system. The 1082 importance is influenced by how well a node is socially related to 1083 other important nodes. 1085 o N_(x): Refers to the neighbor set of a node x, which it encountered 1086 in the current daily sample. 1088 o dumping factor (d): Refers the level of randomness considered by 1089 the forwarding algorithm. 1091 o daily sample (Ti): Refers to the time period in which the contact 1092 duration will be measured to determine social weight and node 1093 importance. 1095 As nodes interact, their CD_(x,y) is collected and used to determine 1096 TCT_(x,y), AD_(x,y), w_(x,y), and I_(x) at the end of every daily 1097 sample. If DABBER is configured with a high number of daily samples, 1098 the social weight and node importance will be more refined. Thus, it 1099 is recommended the usage of twenty-four (24) daily samples 1100 representing each hour of the day: the first daily sample refers 1101 always to the zero hour of the day when the node is started. 1103 Being able to identify the current daily sample allows a proper 1104 computation of social weights and importance. Hence, in the case of 1105 node failure (e.g., node crash) or node shutdown (e.g., lack of 1106 battery), nodes need to know exactly in which daily sample they 1107 stopped interaction, and more importantly how many daily samples have 1108 elapsed since then (elapsed_ds). To guarantee that, the equation 1109 below is used: 1111 elapsed_ds = cnds * (ed - 1) + (cds - 1) + (cnds - lds) (1) 1113 where: 1115 "cnds" is the configured number of daily samples. 1117 "ed"refers to the number of elapsed days. 1119 "cds" refers to the current daily sample (the one in which the node 1120 came back on). 1122 "lds" refers to last daily sample (in which the node failed or shut 1123 down). 1125 With this, the node knows how many daily samples have elapsed and can 1126 proceed with the update of social weights and importance to reflect 1127 the lack of interaction that happen in reality. 1129 5.1. Time-Evolving Contact Duration 1131 The TECD utility function considers the duration of contacts 1132 (representing the intensity of social ties among users) and time- 1133 evolving interactions (reflecting users' habits over different daily 1134 samples). 1136 Regarding the notations used in the equations presented in this sub- 1137 section: sumk(...) denotes summation for k from 1 to n; sumj(...) 1138 denotes summation for j from i to i+t-1; sumy denotes summation from 1139 all y belonging to N(x). 1141 Two nodes may have a social weight, w_(x,y), that depends on the 1142 average total contact duration they have had in that same period of 1143 time over different days. Within a specific daily sample Ti, node x 1144 has n contacts with node y, having each contact k a certain contact 1145 duration, CD_(x,y). At the end of each daily sample, the total 1146 contact time, TCT_(x,y), between nodes x and y is given by the 1147 equation below where n is the total number of contacts between the 1148 two nodes. 1150 TCT_(x,y) = sumk(CD_(x,y)) (2) 1152 The Total Contact Time between users in the same daily sample over 1153 consecutive days can be used to estimate the average duration of 1154 their contacts for that specific daily sample: the average duration 1155 of contacts between users x and y during a daily sample Ti in a day 1156 j, denoted by AD_(x,y) is given by a cumulative moving average of 1157 their TCT in that same daily sample, TCT_(x,y), and the average 1158 duration of their contacts during the same daily sample Ti on the 1159 previous day, denoted by AD_(x,y)_old, as shown in the equation 1160 below. 1162 AD_(x,y) = (TCT_(x,y)+(j-1)*AD(x,y)_old)/j (3) 1164 The social strength between users in a specific daily sample Ti may 1165 also provide some insight about their social strength in consecutive 1166 k samples in the same day, i+k. This is what we call Time Transitive 1167 Property. This property increases the probability of nodes being 1168 capable of transmitting large data chunks, since transmission can be 1169 resumed in the next daily sample with high probability. 1171 TECD is able to capture the social strength w_(x,y) between any pair 1172 of users x and y in a daily sample Ti based on the average duration 1173 AD_(x,y) of contacts between them in such daily sample and in 1174 consecutive t-1 samples, where t represents the total number of daily 1175 samples. When k>t, the corresponding AD_(x,y) value refers to the 1176 daily sample k-t. In the equation below the time transitive property 1177 is given by the weight t/(t+k-i), where the highest weight is 1178 associated to the average contact duration in the current daily 1179 sample, being it reduced in consecutive samples. 1181 TECD = w_(x,y) = sumj(t/(t+k-i)*AD_(x,y)) (4) 1183 5.2. TECD Importance 1185 As social interaction may also be modeled to consider the node 1186 importance, TECDi computes the importance, I_(x), of a node x (cf. 1187 equation below), considering the weights of the edges between x and 1188 all the nodes y in its neighbor set, N_(x), at a specific daily 1189 sample Ti along with their importance. 1191 TECDi = I_(x) = (1-d)+d*sumy(w_(x,y)*I_(y)/N_(x)) (5) 1192 TECDi is based on the PeopleRank function. However, TECDi considers 1193 not only node importance, but also the strength of social ties 1194 between bundle's current carrier and potential next hops. Another 1195 difference is that, with TECDi, the neighbor set of a node x only 1196 includes the nodes which have been in contact with node x within a 1197 specific daily sample Ti, whereas in PeopleRank the neighbor set of a 1198 node includes all the nodes that ever had a link to node x. Note 1199 that the level of randomness may vary with the application scenario. 1200 Unless previously experimented, it is suggested that dumping factor 1201 be set to 0.8. 1203 5.3. Forwarding strategy 1205 Independently of the application scenario, each node MUST employ a 1206 forwarding strategy. The first rule is that if the encountered node 1207 is the final destination of a bundle, the carrier SHOULD prioritize 1208 such bundles by employing the prioritized forwarding strategy, 1209 described below. 1211 We use the following notation for the description provided in this 1212 section. Nodes A and B are the nodes that encounter each other, and 1213 the strategies are described as they would be applied by node A. 1215 5.3.1. Basic Strategy 1217 Forward the bundle only if w_(B,D) > w_(A,D) or I_(B) > I_(A) 1219 When two nodes A and B meet in any daily sample Ti, node A gets from 1220 node B: a) the updated list of all neighbors of B, including the 1221 social weights that B has towards each of its neighbors, as well as 1222 the importance of B; b) the list of the bundles that B is carrying 1223 (bundle identifier, plus Endpoint Identifier (EID) of the 1224 destination); c) the list of the latest set of bundles acknowledged 1225 to B (the size of the list of acknowledged bundles returned by B 1226 depends on the local cache size and policy). The information about 1227 the social weight, importance, bundle list, and acknowledged bundles 1228 received from node B are referenced in node A as w_(B,x)_recv, 1229 I_(B)_recv, bundleList(IDn, destinationEIDx)_recv, and 1230 ackedBundleList(IDn, destinationEIDx)_recv, respectively. 1232 For every bundle that A carries in its buffer, and i) is not carried 1233 by B, ii) has not been previously acknowledged to B, and iii) B has 1234 enough buffer space to store it, node A sends a copy to B if B has 1235 already encountered the bundle's destination D and its weight in 1236 w_(B,D)_recv is greater than A's weight towards this same destination 1237 D. Otherwise, bundles are replicated if I_(B)_recv is greater than 1238 A's importance in the current daily sample Ti. 1240 Finally, node A will update its own ackedBundleList and discard 1241 bundles that have already been acknowledged to node B. 1243 5.3.2. Prioritized Strategy 1245 Similar to the basic forwarding strategy, being the only difference 1246 the fact that prior to sending bundles, node A will first send those 1247 bundles that have node B as destination. 1249 6. Protocol Addictional Functionality 1251 6.1. Adjustment to data source mobility 1253 As NDN uses a publish/subscribe communication model, where request 1254 resolution and data transfer are decoupled, it is especially relevant 1255 to solve the problem of data source mobility. Supporting data source 1256 mobility requires, first of all, finding the new location of the 1257 source each time data sources move, and, second, updating the name 1258 resolution system according to the new location, in order to maintain 1259 the consistency of NDN forwarding. 1261 This sub-section described a new feature of DABBER which follows a 1262 new reactive approach to face the challenges of the data source 1263 mobility and consistent forwarding in Mobile ICNs. To this end, 1264 DABBER is using the efficient dissemination method for Opportunistic 1265 Networks [Optimal-stopping] to efficiently discover data sources by 1266 replicating Interest messages in an efficient way that avoids network 1267 flooding. 1269 With this new feature the prospective forwarders for a given Interest 1270 message (which are denoted as discoverers) are limited in number and 1271 carefully selected in terms of three criteria: 1273 o Centrality: how well connected a node is in the network. The more 1274 central a node is, the bigger the chances are to find a data source. 1276 o Reliability: the likeliness a node does not drop messages. The 1277 more reliable a node is, the least probable is that the Interest 1278 message will be discarded. 1280 o Similarity: how alike the contacted candidate node is in terms of 1281 shared acquaintances. The less similar, the more likely is that it 1282 will find different nodes in the future. 1284 A combination of these three criteria defines a reward function 1285 (discoverer suitability) of an Optimal Stopping (OS) problem. If a 1286 node finds a new node with a certain value for the discoverer 1287 suitability it is difficult to know whether this value is a good one 1288 when compared with what a node could find in future contacts. This 1289 decision is not trivial: if a node chooses early-contacted discoverer 1290 candidates, good results are not guaranteed because selected 1291 discoverers could have a low discoverer suitability metric. On the 1292 other end of the spectrum, selecting late-contacted discoverer 1293 candidates does not guarantee either good discoverer nodes since it 1294 is likely that good candidates with high discovery suitability values 1295 would be skipped. 1297 DABBER is so extended with the ability to perform an OS-based 1298 strategy that allows nodes to select the most suitable node among all 1299 of the contacted ones to forward the Interest message. This strategy 1300 relies on the existence of an optimal set of stopping values such 1301 that the nth discoverer node for a certain Interest message is the 1302 first contacted node which is the best of all the previously explored 1303 nodes, if the node has contacted the first stopping value. If this 1304 node is not found, then it will be the first node which is the second 1305 best of all the previous nodes, if the node has contacted the second 1306 stopping value, and so on. Otherwise, if these nodes are not found, 1307 then, the nth discoverer node will be the last nth node before 1308 reaching the last contacted node. This makes the dissemination of 1309 the Interest messages in Mobile NDNs efficient, even, and pervasive 1310 all over the network, increasing the delivery ratio while decreasing 1311 the network overhead. 1313 7. Interoperability 1315 In this section we analyze the interoperability of DABBER with 1316 routing and forwarding mechanisms used in wired ICN networks, aiming 1317 to study how DABBER can help in ther interconnection of ICDTNs with 1318 wired ICN networks. We analyze the interoperability of DABBER with 1319 two potential configurations of an ICN access network based on: a 1320 routing protocol able of disseminating name prefix information; a 1321 broadcast based forwarding approach. 1323 7.1. Interoperability with ICN routing 1325 DABBER LSA dissemination mechanism provides a good interoperability 1326 with ICN routing protocols based on link state, which normally 1327 exchange information about adjacency and name prefixes. In this 1328 scenario the specification used by DABBER ensures a good level of 1329 interoperability, since DABBER follows the same message structure and 1330 sequence used by such protocols, such as the Named Data Link State 1331 Routing Protocol (NLSR). 1333 However, when DABBER is executing the LSA dissemination procedure 1334 over a Wi-Fi face, towards an edge router it will ignore all 1335 notifications that Chronosync will send related to Adjacency LSAs. 1337 7.2. Interoperability with broadcast based forwarding 1339 Broadcast-based forwarding is a common mechanism in the design of 1340 some networks, such as switched Ethernet and mobile ad-hoc networks. 1341 In CCN/NDN networks this means that NFD broadcasts Interest packets 1342 that do not match an entry in the FIB, inserting then into the FIB 1343 the forwarding path learned through observation of Data return paths. 1344 The main challenge in broadcast based forwarding schemes is the 1345 prefix granularity problem: determine the name prefix of an inserted 1346 FIB entry from the Data name. Several solutions exist 1347 [Self-learning], including the announcements of name prefixes, as 1348 done by DABBER. 1350 In any case DABBER interoperability with such CCN/NDN networks relies 1351 on the following considerations: 1353 o When in contact with a wireless edge router, DABBER always forward 1354 Interest packet towards the Wi-Fi Face, even when the Interest packet 1355 does not match an entry in the FIB. 1357 o Interest packets received from a wireless edge router will not be 1358 broadcast. Interest packets will be forwarded if they match an entry 1359 in the FIB, or dropped otherwise. 1361 8. Security Considerations 1363 DABBER follows the CCN/NDN security framework built on public-key 1364 cryptography, allows it to secure the exchange of routing messages, 1365 by being able of verifying the authenticity of routing messages, and 1366 ensuring the needed levels of confidentiality. Moreover, DABBER 1367 ensures the right level of privacy of the involved entities, who 1368 provide local information to support routing decisions. 1370 Routing security can be achieved not only by signing routing 1371 messages, but also by allowing the usage of multiple paths, as done 1372 by DABBER: when an anomaly is detected routers can retrieve the data 1373 through alternative paths. 1375 Besides the presented security and privacy considerations, the issue 1376 of Denial of Service (DoS) needs to be properly addressed. An 1377 example is when a malicious user sends a high rate of broadcast 1378 messages aiming to exhaust available forwarding resources. 1380 The remaining of this section provides initial insights about the 1381 methods used by DABBER to ensure the authenticity, confidentiality of 1382 the routing message exchange as well as the privacy of the involved 1383 entities. 1385 8.1. Authenticity 1387 DABBER routing messages are carried in Data packets containing a 1388 signature. Hence, a DABBER device can verify the signature of each 1389 routing message to ensure that it was generated by the claimed origin 1390 node and was not tampered with during dissemination. For this 1391 propose, DABBER makes use of a hierarchical trust model for routing 1392 to verify the keys used to sign the routing messages. 1394 Following the name structure described in section 2.3, DABBER can 1395 model a trust management as a five-level hierarch, although 1396 reflecting a different administrative structure: represents 1397 the authority responsible by the international transit network 1398 allowing roaming services; represents the operator 1399 providing the mobile service; represents the network site of 1400 the mobile operator where the node is registered; represents 1401 the mobile equipment. Each node can create a DABBER process that 1402 produces LSAs. 1404 With this hierarchical trust model, one can establish a chain of keys 1405 to authenticate LSAs. Specifically, a LSA must be signed by a valid 1406 DABBER process, which runs on the same node where the LSA was 1407 originated. To become a valid DABBER process, the process key must 1408 be signed by the corresponding node key, which in turn should be 1409 signed by the registered home network of the network operator. Each 1410 home network key must be signed by the operator key, which must be 1411 certified by the network authority using the network key. 1413 Since keys must be retrieved in order to verify routing updates, 1414 DABBER allows each node to retrieve keys from its neighbors. This 1415 means that a DABBER node will use the Interest/Data exchange process 1416 to gathers keys from all its direct neighbors. Upon the reception of 1417 an Interest of the type //broadcast/KEYS each neighbor looks 1418 up the requested keys in their local key storage and return the key 1419 if it is found. In case a neighbor does not have the requested key, 1420 the neighbor can further query its neighbors for such key. The used 1421 key retrieval process makes use of a broadcast forwarding strategy, 1422 stopping at nodes who either own or cache the requested keys. 1424 8.2. Confidentiality 1426 Although being deployed under the control of an operator, DABBER 1427 allows its network to be extended beyond the reach of its 1428 infrastructure network, into scenarios where wireless communications 1429 between involved DABBER devices/router may be spoofed. Hence, DABBER 1430 requires routing data confidentiality to ensure the setup of a secure 1431 communication topology. 1433 DABBER basic approach relies on the usage of encryption to protect 1434 the confidentiality of routing messages. By taking advantage of the 1435 semantically meaningful names DABBER relies on approaches such as 1436 Named-based Access Control (NAC) [NAC]. NAC provides content 1437 confidentiality and access control based on a combination of 1438 symmetric and asymmetric cryptography algorithms, while using NDN's 1439 data-centric security and naming convention to automate data access 1440 control. 1442 Being implemented in wireless devices that may energy constraint, it 1443 will be important to verify the efficiency of the cryptographic 1444 solution, namely since the generation of asymmetric key pairs as well 1445 as the symmetric and asymmetric encryption/decryption operations may 1446 be expensive in terms of the usage of resources. devices. 1448 8.3. Privacy 1450 In DABBER, forwarding decisions are taken into account using 1451 different metrics such as centrality and similarity. While these 1452 metrics may be efficient in terms of node selection, they can breach 1453 privacy of network users carrying networked devices by inferring 1454 social related information such as position inside groups, as well as 1455 information about the devices themselves. 1457 If exchanged as clear text, the information carried in routing 1458 metrics may potentially compromising the privacy of users. A way of 1459 preserving the privacy of the users in DABBER is to use NDN-P2F 1460 [Privacy], a privacy-preserving forwarding scheme that uses 1461 homomorphic encryption for information-centric wireless Ad Hoc 1462 Networks. 1464 In, NDN-P2F, forwarding decisions are made by performing calculations 1465 on encrypted forwarding metric values without decrypting them first, 1466 while maintaining low overhead and delays. As a result, forwarding 1467 decisions can be taken preserving the user's privacy. For these 1468 purposes, homomorphic encryption is extremely useful. This 1469 cryptographic scheme allows computations on ciphertexts and generates 1470 encrypted results that, when decrypted, match the results of the 1471 operations as if they had been performed on plaintexts. 1473 There are many homomorphic cryptosystems. A good choice for DABBER 1474 can be the Paillier cryptosystem because it is lightweight and, among 1475 its properties, it includes the homomorphic addition and 1476 multiplication of plaintexts and the homomorphic multiplication by a 1477 scalar. The Paillier cryptosystem, however, does not provide a way 1478 of calculating the encrypted subtraction, which is needed for metric 1479 comparisons. For these purposes, the mapping scheme proposed in 1480 [PrivHab] can be used to be able to operate with negative numbers. 1482 9. IANA Considerations 1484 This document has no actions for IANA. 1486 10. Acknowledgments 1488 The research leading to these results received funding from the 1489 European Union (EU) Horizon 2020 research and innovation programmer 1490 under grant agreement No 645124(Action full title: Universal, mobile- 1491 centric and opportunistic communications architecture, Action 1492 Acronym: UMOBILE)[Umobile]. 1494 We thank all contributors, as well as the valuable comments offered 1495 by Lixia Zhang (UCLA) and Lan Wang (University of Memphis) to improve 1496 this draft. 1498 11. References 1500 11.1. Normative References 1502 [NDN-OPP] Tavares, M. and P. Mendes, "NDN-Opp: Named-Data Networking 1503 in Opportunistic Networks", Technical Report COPE-SITI-TR- 1504 18-01 , January 2018. 1506 [NFD] A. Afanasyev, et al, "NFD Developer's Guide", NDN 1507 Technical Report NDN-001 , October 2010. 1509 11.2. Informative References 1511 [ChronoSync] 1512 Zhu, Z. and A. Afanasyev, "Lets ChronoSync:Decentralized 1513 Dataset State Synchronization in Named Data Networking", 1514 in Proc. IEEE ICNP , October 2013. 1516 [Dlife] Moreira, W., Mendes, P., and S. Sargento, "Opportunistic 1517 Routing based on daily routines", in Proc. of IEEE WoWMoM 1518 workshop on autonomic and opportunistic communications, 1519 San Francisco, USA , June 2012. 1521 [Dlife-draft] 1522 Moreira, W., Mendes, P., and E. Cerqueira, "Opportunistic 1523 Routing based on Users Daily Life Routine", IETF Internet 1524 Draft (draft-moreira-dlife-04) , May 2014. 1526 [ICN-routing-opp] 1527 P. Mendes, et al, "Information-centric Routing for 1528 Opportunistic Wireless Networks", n ACM ICN, Boston, USA , 1529 September 2018. 1531 [Loop-free] 1532 Schneider, K. and B. Zhang, "How to Establish Loop-Free 1533 Multipath Routes in Named Data Networking", NDN Technical 1534 Report NDN-0044 , April 2017. 1536 [NAC] Z. Zhang, et al, "NAC: Automating Access Control via Named 1537 Data", in IEEE MILCOM , October 2018. 1539 [NDN-emergency] 1540 Tavares, M., Aponte, O., and P. Mendes, "Named-data 1541 Emergency Network Services", in ACM MOBISYS, Munich, 1542 Germany , June 2018. 1544 [NDN-opportunisticnets] 1545 Dynerowicz, S. and P. Mendes, "Named-Data Networking in 1546 Opportunistic Networks", ACM ICN, Berlin, Germany , 1547 September 2017. 1549 [Optimal-stopping] 1550 Borrego, C., Borrell, J., and S. Robles, "Efficient 1551 broadcast in opportunistic networks using optimal stopping 1552 theory", Ad Hoc Networks , May 2019. 1554 [PartialSync] 1555 Zhang, M., Lehman, V., and L. Wang, "PartialSync:Efficient 1556 Synchronization of a Partial Namespace in NDN", NDN 1557 Technical Report NDN-0039 , June 2016. 1559 [Privacy] C. Borrego, et al, "Privacy-Preserving Forwarding using 1560 Homomorphic Encryption for Information-Centric Wireless Ad 1561 Hoc Networks", IEEE Communications Letters , July 2019. 1563 [PrivHab] S.Carmona, et al, "PrivHab+: A secure geographic routing 1564 protocol for DTN", Elsevier Computer Communications , May 1565 2016. 1567 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1568 Resource Identifier (URI): Generic Syntax", STD 66, 1569 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1570 . 1572 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 1573 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 1574 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 1575 April 2007, . 1577 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 1578 Specification", RFC 5050, DOI 10.17487/RFC5050, November 1579 2007, . 1581 [RFC6693] Lindgren, A., Doria, A., Davies, E., and S. Grasic, 1582 "Probabilistic Routing Protocol for Intermittently 1583 Connected Networks", RFC 6693, DOI 10.17487/RFC6693, 1584 August 2012, . 1586 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 1587 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 1588 "Information-Centric Networking: Baseline Scenarios", 1589 RFC 7476, DOI 10.17487/RFC7476, March 2015, 1590 . 1592 [Scorp] Moreira, W., Mendes, P., and S. Sargento, "Social-aware 1593 Opportunistic Routing Protocol based on User's 1594 Interactions and Interests", in Proc. of AdhocNets, 1595 Barcelona, Spain , October 2013. 1597 [Self-learning] 1598 Shi, J., Newberry, E., and B. Zhang, "On Broadcast-based 1599 Self-Learning in Named Data Networking", in Proc. Of IFIP 1600 Networking, Stockholm , June 2017. 1602 [Umobile] C. Sarros, et al, "Connecting the Edges: A Universal, 1603 Mobile centric and Opportunistic Communications 1604 Architecture", IEEE Communication Magazine , February 1605 2018. 1607 [UmobileD45] 1608 R. Sofia, et al, "UMOBILE D45 - Report on Data Collection 1609 and Inference Models", Umobile Technical Report , 1610 September 2018. 1612 11.3. URIs 1614 [1] https://github.com/COPELABS-SITI/ndn-opp 1616 Authors' Addresses 1617 Paulo Mendes (editor) 1618 Airbus 1619 Willy-Messerschmitt Strasse 1 1620 Munich 81663 1621 Germany 1623 Email: paulo.mendes@airbus.com 1624 URI: http://www.paulomilheiromendes.com 1626 Rute C. Sofia 1627 fortiss GmbH 1628 Guerickestrasse 25 1629 Munich 80805 1630 Germany 1632 Email: sofia@fortiss.org 1633 URI: http://www.rutesofia.com 1635 Vassilis Tsaoussidis 1636 Democritus University of Thrace 1637 University Campus 1638 Komotini 69100 1639 Greece 1641 Email: vtsaousi@ee.duth.gr 1643 Carlos Borrego 1644 Autonomous University of Barcelona 1645 Department of Information and Communications Engineering 1646 Bellaterra 08193 1647 Spain 1649 Email: carlos.borrego@uab.cat