[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

Network Working Group                                     P. Mendes, Ed.
Internet-Draft                                                    Airbus
Intended status: Experimental                                   R. Sofia
Expires: March 19, 2021                                     fortiss GmbH
                                                          V. Tsaoussidis
                                         Democritus University of Thrace
                                                              C. Borrego
                                      Autonomous University of Barcelona
                                                      September 15, 2020


    Information-centric Routing for Opportunistic Wireless Networks
                      draft-mendes-icnrg-dabber-05

Abstract

   This draft describes the Data reAchaBility BasEd Routing (DABBER)
   protocol.  DABBER aims to provide a name-based routing solution to
   support the operation of Information-centric Networking frameworks in
   opportunistic wireless networks.  By "opportunistic wireless
   networks" it is meant multi-hop wireless networks where finding an
   end-to-end path between any pair of nodes at any moment in time may
   be a challenge.  The goal is to assist in better defining
   opportunities for the transmission of Interest packets in a store-
   carry-and-forward manner, based on a proactive approach.  The
   document describes how to integrate DABBER in a networking node that
   implements some ICN approach, such as Named-Data Networking (NDN) or
   Content Centric Networking (CCN), along with the specification of the
   proactive approach based on the dissemination of name-prefix
   information.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 19, 2021.




Mendes, et al.           Expires March 19, 2021                 [Page 1]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Assumptions and Design Choices  . . . . . . . . . . . . .   4
     1.2.  Conventions . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Applicability Examples  . . . . . . . . . . . . . . . . . . .   4
   3.  DABBER Architecture . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Extensions to NFD . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Routing Engine  . . . . . . . . . . . . . . . . . . . . .   7
   4.  DABBER Protocol Design  . . . . . . . . . . . . . . . . . . .   8
     4.1.  Name Prefix Dissemination . . . . . . . . . . . . . . . .  10
     4.2.  Name Prefix Cost Computation  . . . . . . . . . . . . . .  13
     4.3.  Update of Internal Structures . . . . . . . . . . . . . .  15
     4.4.  Update of NFD Structures  . . . . . . . . . . . . . . . .  15
     4.5.  Packet Format . . . . . . . . . . . . . . . . . . . . . .  16
   5.  DABBER Operational Example  . . . . . . . . . . . . . . . . .  16
   6.  DABBER Operational Considerations . . . . . . . . . . . . . .  17
     6.1.  Context Awareness . . . . . . . . . . . . . . . . . . . .  18
     6.2.  Integration with Wi-Fi Direct . . . . . . . . . . . . . .  19
     6.3.  Integration with DTN  . . . . . . . . . . . . . . . . . .  20
     6.4.  Producer Mobility . . . . . . . . . . . . . . . . . . . .  20
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
     7.1.  Authenticity  . . . . . . . . . . . . . . . . . . . . . .  22
     7.2.  Confidentiality . . . . . . . . . . . . . . . . . . . . .  22
     7.3.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .  23
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  24
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  24
     10.2.  Informative References . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26





Mendes, et al.           Expires March 19, 2021                 [Page 2]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


1.  Introduction

   This document provides a specification for DABBER, an opportunistic
   wireless routing protocol that provides a name-based routing solution
   for the operation of Information-Centric Networking (ICN) [RFC7476]
   in wireless networks, including opportunistic wireless environments.
   The term opportunistic wireless networks primarily refers to multi-
   hop wireless networks, where finding an end-to-end path between any
   pair of nodes at any moment in time may be a challenge, given that
   networking nodes availability depends upon different mobility
   patterns and wireless links are intermittently available due to
   changes in the environment or changes in the position of the nodes
   terminating the link.  Examples of such wireless environments
   encompass mobile crowd sensing and Internet of Things, where things
   are mobile devices, or sensors, including those operating in
   terrestrial or non-terrestrial networks that integrate smart
   satellite constellations.

   The deployment of information centric wireless networks by applying
   NDN or CCN alone, inevitably leads to network flooding, due to the
   lack of knowledge about the best set of paths to reach data holders.
   As a basic NDN/CCN approach the first set of Interest packets are
   broadcasted in order to identify the interfaces that lead to a data
   holder.  DABBER aims to prevent such flooding by allowing data
   holders to announce the name prefix of the data sets they hold.  This
   allows networking nodes to know which are the appropriate interfaces
   to reach a certain data set prior to the arrival of the corresponding
   Interest packets.  The expected result is the reduction of both
   network overhead and latency of Interest packets.

   It is our understanding that routing in such wireless environments
   needs to be done based on strategies that take into consideration, at
   a network level, the context of wireless nodes (e.g., availability,
   centrality), and not just the history of contacts among wireless
   nodes, as it is often the case in opportunistic routing [Dlife]
   [Dlife-draft] [Scorp].  The goal is to better determine windows of
   opportunity to transmit Interest and Data packets, while opportunity
   reflects both time and space.

   DABBER is devised to be easily integrated with the data plane of CCN/
   NDN [NFD], since these are well established distributed ICN
   frameworks.

   A DABBER [DABBER18] proof-of concept implementation is available via
   GitHub [DABBER18-1] and via Google Play [DABBER18-2].  DABBER has
   been tested in emergency scenarios with intermittent connectivity
   based on a novel NDN instant messenger, the Oi!  Application for
   Android [OI].



Mendes, et al.           Expires March 19, 2021                 [Page 3]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


1.1.  Assumptions and Design Choices

   DABBER relies on the following assumptions with regard to
   opportunistic wireless environments:

   o Nodes are mobile.

   o Nodes overhear each other.

   o Nodes can be data sources, data destinations, or forwarders.

   o Nodes may decide to be the custodians of data transmissions based
   on a set of criteria, such as local available resources.

   o Nodes do not have a complete topology view.

   DABBER relies on the following major design choices to develop a
   name-based routing protocol for opportunistic wireless network:

   o DABBER must avoid the network being flooded by Interest packets.

   o DABBER is based on the distribution of name prefix (data
   reachability) only, since adjacency information may present high
   variability.

   o DABBER is based on local information about the context of a node,
   in order to support the selection of the most suitable neighbours to
   forward Interest packets.

   o DABBER avoids the definition of new messages by making usage of
   synchronization mechanisms already developed for NDN, such as
   ChronoSync [ChronoSync][PartialSync].

1.2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

2.  Applicability Examples

   Mobile Crowd Sensing: This scenario encompasses the implementation of
   NDN/CCN in personal mobile nodes (e.g., smartphones) allowing users
   to share data and messaging services by exploiting existing
   intermittent wireless connections (e.g., Wi-Fi, Wi-Fi Direct) in an
   environment without/or limited Internet access.  These scenarios are
   also relevant in dense and remote areas.




Mendes, et al.           Expires March 19, 2021                 [Page 4]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


   Smart Satellite Constellation Communication: Delay Tolerant
   Networking (DTN) [RFC4838] is acknowledged as a relevant technology
   also for future smart satellite constellations.  ICN adds in the
   support for intermittent connectivity, and relevant properties to
   support mobility and integrated security.

   People-to-people Communication in Emergency Scenarios: A routing
   solution such as DABBER assists in supporting local data exchange
   across entities in a way that is agnostic to devices capabilities and
   identity [Umobile].

   Internet of Things: The Pub/Sub receiver-driven nature of ICN brings
   in recognizable advantages to the Internet of Things, in particular
   involving mobile nodes, such as fleets of AGVs, UAVs.

3.  DABBER Architecture

   R relies on the same data structures made available by the Named Data
   Networking Forwarding Daemon [NFD], namely the Routing Information
   Base (RIB), the Forwarding Information Base (FIB), and the Pending
   Intent Table (PIT), as illustrated in figure 1.

   DABBER brings no changes to the operation of NFD.  However,
   augmenting NFD with a routing engine for wireless networks requires
   the inclusion of three new components to NFD.  This extended NFD is
   called NDN-OPP (NDN for Opportunistic networks) [NDN-OPP], as shown
   in figure 1.

   This section provides a description of the extensions included in NFD
   as well as the new components of the DABBER routing engine.





















Mendes, et al.           Expires March 19, 2021                 [Page 5]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


    +--------------+     +--------------------------- + +----------+
    |NDN-OPP       |     | DABBER                     | |Contextual|
    |  +---------+ |     |  +---------------+   |-------| Manager  |
    |  |Add_Route|<--| |--->|Neighbor Mng    |<-|     | +----------+
    |  +---------+ | | | |  +---------------+         |
    |  | +------+  | | | |     |           |          |
    |  | |NFD   |  | | | |     |           |          |
    |  | | +---+|  | | | |     v           v          |
    |  |-->|RIB||  | | | |  +----------+  +--------+  |
    |    | +---+|  | |------|RIB-Update|<-|CompCost|<||
    |    | +---+|  |   | |  +----------+  +--------+ ||
    |    | |FIB||  |   | |     |                     ||
    |    | +---+|  |   | |     v        +--------+   ||
    |    | +---+|  |   | | +------+     |Name_Mng|---||
    |    | |PIT||  |   | | | LSDB |<--->+--------+    |
    |    | +---+|<||   | | +------+<------|           |
    |    +------+ ||   | |                v           |
    |   +-------+-||   | |             +-------+      |
    |   |Pkt_Mng|<-----| |             | PSync |      |
    | |>+-------+  |     |             +-------+      |
    | |            |     +----------------------------+
    |+--------+    |
    ||OppFace |    |
    +--------------+


   Figure 1: DABBER Architecture.

3.1.  Extensions to NFD

   In order to augment NFD with a routing engine to allow for the
   deployment of NDN/CNN in wireless networks three new elements were
   included in NFD: a method to add routes to the RIB (Add_route in
   figure 1); a method to gather information (carried names) and status
   (time of reception) of Interest and Data messages (Pkt_Mng in figure
   1); a new face able to handle the intermittent nature of wireless
   links, called Opportunistic Face (OPPFace) (c.f figure 1).

   An OPPFace is a virtual face based on a system of packet queues to
   hide intermittent connectivity.  An OPPFace is created for each
   neighbor node, where a neighbor node is any node that the current
   node has ever contacted to directly (i.e. over one radio hop).
   OPPFaces are kept in the Face Table and their state reflects the
   wireless connectivity status towards the respective neighbor: they
   can be in an Up or Down state, depending upon the wireless
   reachability the corresponding neighbor node.





Mendes, et al.           Expires March 19, 2021                 [Page 6]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


   When packets are dispatched based on the information stored in the
   FIB, an OPPFace is able to delay packet transmission until there is
   wireless connectivity to the correspondent neighbor: the OPPFace
   simply queue packets, when OPPFace is Down, or flush the queue, when
   OPPFace is Up.  Since packet queuing is concealed inside OPPFaces,
   existing forwarding strategies do not need to be changed.

   OPPFaces can be implemented by using any direct wireless
   communication mode (Infrastructured, Ad-Hoc, and Direct mode).  The
   current implementation of NDN-OPP for Android devices
   [NDN-OPP-Android] makes usage of group communications provided by Wi-
   Fi Direct [NDN-emergency][NDN-opportunisticnets].  More information
   about the integration of NDN-OPP with Wi-Fi Direct is provided in
   section 6.2.

3.2.  Routing Engine

   DABBER is a name-based routing protocol that allows nodes to exchange
   information about name reachability in order to select the most
   suitable neighbours to forward Interest messages.

   The operation of the DABBER routing engine is performed based on the
   following components, illustrated in figure 1:

   o Neighbor_Management: Keep updated information about neighbours in a
   Neighbor Table.  A neighbor entry in that table has information about
   the neighbor availability, centrality and similarity, as well as
   about the delay that Interest packets suffer when forwarded via a
   certain neighbour.  The information about neighbours is used to
   compute the cost of each name prefix announced by them, while the
   information about the delay of Interest packets is used to update the
   weights of the neighbors entries in the RIB.  The delay of Interest
   packets is a measure of the time difference between sending an
   Interest packet and receiving the corresponding Data packet, based on
   information collected from the Pkt_Mng module of NDN-OPP.  The
   information about neighbor availability, centrality and similarity is
   collected by an external entity, as described in section 6.1.

   o Compute_Name_Cost: This module computes the cost associated with
   each name prefix as a function of the node similarity of the neighbor
   announcing the name prefix, and the cost received in the
   announcement.  That cost is used to update the entry of that name
   prefix / Neighbor in the DABBER internal Routing Table.

   o Name_Prefix_Management: This module is responsible to remove and
   add Link State Announcement (LSA) into the Link State DataBase (LSDB)
   used by PSync.  New LSAs present in the LSDB (announced by a
   neighbor) are removed in order to pass the following tuples to the



Mendes, et al.           Expires March 19, 2021                 [Page 7]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


   module responsible to compute the costs of name prefixes: Name
   prefix; Cost; Neighbor.

   o RIB_Update: This module keeps updated information about the cost of
   the name prefixes that will be used to populate the NFD RIB.  The
   information about each name prefix is kept in a local Routing
   Table based on the tuple: Name prefix; Cost; Neighbor.  The cost
   variable is a function of the cost provided by the Compute_Name_Cost
   module, plus the information about the availability and centrality of
   the neighbor, provided by the Neighbor_Management module.  In defined
   periods of time the RIB_Update modules will use the content of the
   local Routing Table to populate the NFD RIB as well as to insert new
   LSA into the LSDB.

   o LSDB: The Link State DataBase is the structure used by the PSync to
   keep all the information to be synchronized among neighbor nodes.  By
   placing LSAs into the LSDB, DABBER ensures that such information is
   passed to all neighbours without the need to define a new set of
   messages for the exchange of routing information.

   Between PSync and ChronoSync, DABBER makes use of the former since it
   is designed to support partial dataset synchronization.  This means
   that PSync allows a node to subscribe to a subset of data streams,
   where a data stream is a sequence of data items under a common name
   prefix.  Hence, by avoiding full sync operations of a LSDB in which
   only a few entries may be new, PSync helps to improve DABBER
   performance over networks in which wireless links are intermittently
   available.

4.  DABBER Protocol Design

   Being developed for wireless networks, DABBER does not rely on the
   dissemination of Adjacency Link State Advertisements that reflect the
   status of the links towards neighbor nodes; DABBER only requires the
   dissemination of Prefix LSAs.  DABBER does not require the
   computation of shortest paths taking into account adjacency
   information.  Instead DABBER replaces the path cost (sum of the
   weights of all the involved links) used in fixed networks with the
   computation of data reachability cost based on local available
   information, reducing the impact that topological changes would have
   on the stability of routing information.  The assumption behind this
   rational is that the position and validity of the data announced by a
   data holder changes less than the conditions in all the links making
   all potential paths.

   By exchanging Prefix LSAs each device becomes aware of potential
   next-hops via which a name prefix N can be reached with a certain
   cost k.  This cost k represents the probability of reaching a data



Mendes, et al.           Expires March 19, 2021                 [Page 8]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


   object identified by N via a Face F, and is related to the time
   validity of the name prefix (v).  The rationale for this approach is
   that the selection of faces that have a lower cost k (higher validity
   v) will improve data reachability.  The validity of a name prefix is
   set by the data source as an integer that represents the expiration
   date of the data.

   Since different devices can announce the same name prefix, a certain
   name prefix may be associated with different values of k (as v shall
   differ) over different faces, depending upon the nodes announcing
   such name prefix: this lead to the identification of multiple next
   hops, each one with a different cost.

   The computation of multiple next hops is performed every time DABBER
   has a new Name Prefix LSA (or a new version of an existing Name
   Prefix LSA) in its LSDB.

   The computation of multiple next hops is performed every time DABBER
   has a new Name Prefix LSA (or a new version of an existing Name
   Prefix LSA) in its LSDB.

   With this in mind, DABBER was designed with the following sequence of
   operations, as described in the following subsections:

   1.  Name prefix dissemination.

   2.  Name prefix cost computation.

   3.  Update of internal structures (DABBER routing table and LSDB)
   with the data reachability information of the current node towards
   the new Name Prefix.

   4.  Update of NFD structure (RIB) based on the DABBER internal
   routing table.

   Periodically DABBER updates the validity values of all Name Prefixes
   in its internal routing table, performing the consequent updates of
   the local LSDB and RIB, and needed.

   The updated RIB information is used by NFD to update its FIB, which
   is used to forward Interest packets, based on the normal operation of
   NFD.  However, independently of the used forwarding strategy, the
   ranking of faces done by DABBER on the RIB should be respected.  For
   instance an unicast forwarding strategy should use the most important
   face (lower cost), while a multicast forwarding strategy will use all
   the faces indicated for the name prefix.  After selecting the best
   set of faces, a copy of the Interest packet is sent to the OPPFaces
   of the selected faces.  The state of an OPPFace reflects the fact



Mendes, et al.           Expires March 19, 2021                 [Page 9]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


   that the corresponding neighbor device is currently reachable or not.
   Based on this information, the OPPFace decides whether to simply
   queue the packet or attempt a transmission over the associated
   Opportunistic Channel.

   In what concerns Data packets, they are forwarded following the
   normal operation of NFD, that is, following the information stored in
   the PIT.

4.1.  Name Prefix Dissemination

   DABBER was designed to exploit the synchronization mechanisms made
   available by NDN, such as PSync to control the dissemination of name
   prefixes without the need to define neither new messages nor new
   message passing mechanisms.

   This means that while IP-based routing protocols push updates to
   other routers, DABBER devices pull updates.  DABBER can use any
   underlay communication channels (e.g., TCP/UDP tunnels, Link layer
   TXT records) to exchange LSA information via an existing mechanism,
   such as PSync.

   By using Interest/Data packets (exchanged by PSync), DABBER benefits
   from CCN/NDN built-in data authenticity to exchange routing
   information: since a routing update is carried in an Data packet and
   every Data packet carries a signature, a DABBER device can verify the
   signature of each LSA to ensure that it was generated by the claimed
   origin node and was not tampered during dissemination.

         Prefix LSA
   +----------------------------------------------------+
   |LSA |Number of|Prefix 1|Cost|...|Prefix N|Cost|Sign.|
   |Name|Prefixes |        |    |   |        |    |     |
   +----------------------------------------------------+

   Figure 2: Prefix LSA format.

   DABBER advertises Prefix LSAs every time a new name prefix is added
   or deleted to the LSA DataBase (LSDB).  Name prefixes are advertised
   with a cost metric related to the validity of the associated data, as
   shown in Figure 2.  Each LSA used by DABBER has the name
   DID/DABBER/LSA/Prefix/version.  The DID is described by a scheme
   based on URIs.  It can be for instance network/operator/home/node/.
   The version field is increased by 1 whenever a device creates a new
   version of the LSA.

   DABBER disseminates LSAs via a data synchronization mechanism (e.g.
   PSync) of the local LSDB.  This peer synchronization approach is



Mendes, et al.           Expires March 19, 2021                [Page 10]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


   receiver-driven, meaning that a device requests LSAs only when it has
   CPU cycles.  Thus it is less likely a device will be overwhelmed by a
   flurry of updates.  In order to reduce the amount of transferred
   data, DABBER removes obsolete LSAs from the LSDB by periodically
   refreshing each of its own LSAs by generating a newer version.  Every
   LSA has a lifetime associated with it and will be removed from the
   LSDB when the lifetime expires.

   DABBER performs the dissemination of LSAs based on a process able to
   synchronize the content of LSDBs.  In this sense, all LSAs are kept
   in the LSDB as a name set, and DABBER uses a hash of the LSA name set
   as a compact expression of the set.  Neighbor nodes use the hashes of
   their LSA name sets to detect inconsistencies in their sets.  For
   this reason, neighbor nodes exchange hashes of the LSDB as soon as
   OPPFaces are up.

   Current version of DABBER makes use of PSync as a synchronization
   mechanism.  PSync allows DABBER to define a collection of named data
   in a local repo as a slice.  LSA information is synchronized among
   neighbor nodes, since PSync keeps the repo slice containing the LSA
   information in sync with identically defined slices in neighboring
   repositories.

   If a new LSA name is detected in a repo, PSync notifies DABBER to
   retrieve the corresponding LSA in order to update the local LSDB.
   DABBER can also request new LSAs from PSync when resources (e.g.  CPU
   cycles) are available.
























Mendes, et al.           Expires March 19, 2021                [Page 11]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


          Node A                            Node B
     +------------------------+     +---------------------------+
     |        +-------------+ |     |+-------------+            |
     | DABBER |    Psync    | |     ||    Psync    |   DABBER   |
     |        +-------------+ |     |+-------------+            |
     +------------------------+     +---------------------------+
          |            |  Sync Interest (1) |            |
          |            |------------------->|            |
          |            |<-------------------|            |
          | New LSA (2)|                    |            |
          |----------->|                    |            |
          |            |   Sync Reply (3)   |            |
          |            |------------------->|            |
          |            |                    | Notify (4) |
          |            |                    |----------->|
          |            |   LSA Interest (5) |            |
          |<-----------|--------------------|------------|
          |            |   LSA Data (6)     |            |
          |------------|--------------------|----------->|
          |            |                    |            |
          |            |  Sync Interest (7) |            |
          |            |------------------->|            |
          |            |<-------------------|            |


   Figure 3: LSA exchange process.

   Figure 3 shows how an LSA is disseminated between two neighbor nodes
   A and B, when the OPPFace is up.  To synchronize the slice
   representing the LSDB information in the repo, PSync, on each node,
   periodically sends Sync Interests with the hash of its LSA name set /
   slice (step 1).  When Node A has a new Prefix LSA in its LSDB, DABBER
   writes it in the Chronosync slice (step 2).  At this moment, the hash
   value of the LSA slide of node A becomes different from that of node
   B.  As a consequence, the PSync in node A replies to the Sync
   Interest of node B with a Sync Reply with the new hash value of its
   local LSA slice (step 3).  The PSync in node B identifies the LSA
   that needs to be synchronized and notifies DABBER about the missing
   LSA, and updates its LSA name set (step 4).  Since DABBER on node B
   has been notified of the missing LSA, DABBER sends an LSA Interest
   message to retrieve the missing LSA (step 5).  DABBER on node A sends
   the missing data in a LSA Data message (step 6).  When DABBER on node
   B receives the LSA data, it inserts the LSA into its LSDB.  PSync on
   nodes A and B compute a new hash for updating the set and send a new
   Sync Interest with the new hash (step 7).

   When more than one LSA needs to be synchronized, the issued LSA
   Interest packet will contain information about as many LSAs as



Mendes, et al.           Expires March 19, 2021                [Page 12]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


   allowed by the Link maximum transmission unit.  In the same sense one
   LSA Data packet may also be used to transport information about more
   than one LSA.

4.2.  Name Prefix Cost Computation

   When DABBER is notified that a new Prefix LSA was registered in the
   LSDB or an existing Prefix LSA has a new version, it computes a new
   cost for each name prefix in such Prefix LSA.  The cost of a name
   prefix is given by its validity.

   DABBER starts by computing a new validity v for a prefix N depending
   upon the validity announced by the neighbor, and the relevancy of the
   association between the two neighbor nodes (e.g., node A and node B).
   The cost of the Name Prefix, passed to NFD, will then be computed as
   an inversely proportional value to its validity.

   The relevance of the association between two neighbor nodes can be,
   e.g., a measure of similarity, where similarity is seen as a link
   measure, i.e., it provides a correlation cost between a node and its
   neighbors.  Or such relation can be weighted based on metrics derived
   from average contact duration thus allowing a node to adjust the Name
   Prefix validity based on the probability of meeting the respective
   neighbor again.  The "relation" between two neighbor nodes is
   computed based on the three metrics (A, C, and S) provided by the
   local contextual manager, plus a metric computed by DABBER itself:
   the time reachability.

   The variable considered by DABBER for the computation of the
   validity/cost of a Name prefix passed by a neighbor Na are:

   o Validity (V) - Represents the expiration date of the data
   associated with the Name Prefix.  Currently it is the UNIX Timestamp
   (10 digit integer).

   o Similarity metric (S) towards the neighbor Na, as passed by the
   contextual manager (S >= 0), aiming to select neighbors with whom the
   current node has a good communication link.

   o Availability metric (A) towards the neighbor Na, as passed by the
   contextual manager ( 0 < A < 1), aiming to select neighbors able to
   process Interest packets with high probability.

   o Centrality metric (C) towards the neighbor Na, as passed by an
   external context-aware agent (rf. to section 6.1, C >= 0), aiming to
   select neighbors with high probability of successfully forwarding
   Interest packets.




Mendes, et al.           Expires March 19, 2021                [Page 13]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


   o Time reachability (T) which corresponds to the RTT between sending
   an Interest packet towards the source of such Name Prefix and
   receiving a data packet. (0 < T < 1).  Currently the value of T is
   computed as (current time when data packet is received - time when
   Interest packet was sent) / Validity of Name Prefix.  Time
   reachability allows DABBER to select next hops that lead to closer
   sources.

           Neighbor table
     +------------------------------------------------------+
     |   Face     | Status | Metric C | Metric A | Metric S |
     +------------------------------------------------------+
     |     1      |    UP  |    6     |   0.3    |    12    |
     |     2      |  DOWN  |    4     |   0.8    |    8     |
     |     3      |    UP  |    1     |   0.8    |    9     |
     +------------------------------------------------------+

   Figure 4: Neighbor table.

   The values C, A and S provided by the contextual manager are stored
   in a Neighbor Table (c.f.  Figure 4) indexed by the number of faces.
   The higher the values of C, A and S, the most preferential a neighbor
   is.

   T is measured by observing the flow of Interest and Data packets.
   Thus, the lowest the T, the most preferential a Face is.  Although
   different nodes may have a different implementation of a face ranking
   logic, the relevancy of T in comparison to C and A should be higher,
   since T reflects the measured delay to reach a data source, while C
   and A are indicators of the neighbors potential as relays.

   Based on the above mentioned metrics the Validity of a new Name
   Prefix (V) is updated based on two operations:

   o V' = f (V, S') = trunc (V * S'), where:

   S' = (S - Smin) / (Smax - Smin); Smin = 0 and Smax = max (Smax, C)

   o V'' = f (V', C', A, T) = 0.3* trunc (V' * (C'+A)) + 0.7 * trunc (V'
   * T), where:

   C' = (C - Cmin) / (Cmax - Cmin); Where Cmin = 0 and Cmax = max (Cmax,
   C)

   The computation of V' is done by the Compute_Name_Cost module, while
   the execution of V'' is done by the RIB_Update module (c.f. figure
   1).  The value of V'' may be updated more often than V', since it is
   assumed that the properties of the neighbours (C,A) as well as the



Mendes, et al.           Expires March 19, 2021                [Page 14]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


   delay to a data holder (T) may vary more than the new announcement
   from neighbours with an updated value of V.

4.3.  Update of Internal Structures

   After the computation of the cost of the Name Prefix taking into
   account the relation of the current node with the neighbor announcing
   it, DABBER updates its internal routing table (operation done by the
   RIB_Update module) and its LSDB.  The information on the routing
   table will be used to update the RIB of the local NFD and the
   information of the LSDB will be announced to all neighbors by PSync.

   To update the Internal routing table, DABBER adds an entry (Na, V'')
   for the Name Prefix received from Na, where V'' is the computed cost
   of the name prefix.  The routing table is then ordered by name prefix
   in decreased order of validity.

   Since the current node will also disseminate the received Name
   Prefix, DABBER updates the cost of the Name Prefix in the LSA stored
   in its local LSDB in order to consider the computed value V''.  For
   this, DABBER can use two methods:

   o Maximal method: Cost of Name Prefix = max (V'', current cost on
   LSA).

   o Average method: Cost of Name Prefix = max (average (cost of Name
   Prefix entries on local routing table), current cost on LSA).

4.4.  Update of NFD Structures

   After computing the new value of the cost of a name prefix, DABBER
   updates the RIB entry of that name prefix with the face over which
   the Name Prefix LSA was received and the new computed cost.  The cost
   (k) of the Name Prefix to be stored in the RIB is computed based on
   its validity V'' as k = trunc (100/V'').

   DABBER updates the RIB on NFD with the cost k based on three possible
   logics:

   o Increase diversity - The new Face is included in the RIB entry, if
   the computed cost k helps to increase diversity of the name prefix.
   For instance the new cost k is higher than the average costs already
   stored for that name prefix, affected by a configured diversity
   constant.  This logic includes all neighbors with cost = trunc (100/
   V''), such that 1/V'' - Avr (Costs in RIB for N) > X (predefined
   value).





Mendes, et al.           Expires March 19, 2021                [Page 15]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


   o Downward Path Criterion - It is a non-equal cost multi-path logic
   that is guaranteed to be loop-free.  Based on the Downward Path
   Criterion, the X faces (the maximum number X of desirable faces can
   be defined by configuration) to be considered for a name prefix
   include the one with the lowest cost k plus X-1 faces that have a
   cost k lower than the cost that the current node has itself to the
   name prefix.  This logic includes X neighbors with cost = trunc(100/
   V''), such that cost is the lowest value of 1/V'' or cost < 1/ V.

   o Downward Path Criterion extension - Also considers any face over
   which the name prefix can be reached with a cost k equal to the cost
   that the current node has itself to the name prefix.  To avoid
   packets from looping back, there is the need to add a tiebreaker,
   which assures that traffic only crosses one direction of equal-cost
   links.  This logic includes X neighbors with cost = trunc (100/V''),
   such that cost is the lowest value of 1/V'' or cost <=1/ V.

   In any case the deployment of a DABBER network relies on having all
   nodes implemented with the same logic.

4.5.  Packet Format

   DABBER nodes exchange Prefix LSAs by means of a synchronization
   mechanism such as PSync, without the need to create new packets for
   the exchange of routing information.

5.  DABBER Operational Example

   In order to illustrate the proactive routing method defined by
   DABBER, let's consider Figure 5, where nodes A, B, and C reside in an
   wireless node running DABBER, while nodes E and F are wireless edge
   routers running another ICN routing protocol; G is a wireless node
   running DABBER.

        +--------------------+
        |    +---+           |
        |    | B | .         |
        |    +---+  .2+---+  |   +---+    +---+     +---+
        |+---+        | C |3 ... | E |....| F  |....| G |
        || A |.......1+---+  |   +---+    +---+     +---+
        |+---+               |
        +--------------------+

   Figure 5: End-to-end operational example.

   In our example, Node A starts producing some content derived, for
   instance, from the use of an application (such as a data sharing
   application).  The produced content is stored in its local Content



Mendes, et al.           Expires March 19, 2021                [Page 16]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


   Store with the name /NDN/video/Lisbon/nighview.mpg.  Node B stores in
   its Content Store a data object with name /NDN/video/Lisbon/
   river.mpg, which node B received from a neighbor (meaning that B has
   already synchronized its LSDB with such a neighbor).

   Due to the update of the Content Store, the name prefix /NDN/video/
   Lisbon/ is stored in the LSDB of node A and B with a validity of
   864000 and 518400 in the case of node A and B respectively.  In the
   case of node A, the cost k of the name prefix equals the validity v
   of the data object, e.g., v=864000 seconds (10 days) stipulated by
   the application.  In the case of node B the validity is the result of
   the computation of the cost of the name prefix.

   From a routing perspective, storing a name prefix in the local LSDB
   allows the node to share the respective Prefix LSA on all its Faces,
   excepting on the Face over which the LSA was previously received.
   This LSA exchange is done when the OPPFaces are up.  This means that
   Node C, which got a new Prefix LSA from nodes A and B, will:

   o Update its LSDB with the Prefix LSAs received from node A and node
   B.

   o Update its internal routing table with two new entries for the name
   prefix /NDN/video/Lisbon/, associated with the face towards A (face1)
   and with the face towards B (face2), after computing the values of V'
   and V'' for the received validity values:

   o The validity of the name prefix is updated based on the metric
   configured for node C: average inter-contact time.

   o Let's assume that A and C encounter each other frequently, while B
   and C do not meet frequently.  This means that the two entries on the
   routing table of node C for prefix /NDN/video/Lisbon/ will have a
   validity/cost for A higher than the one for B.

   o Update its LSDB with the validity of the current node towards the
   Name Prefix following the maximal or average methods.

   o Update the RIB with one new entry for the name prefix /NDN/video/
   Lisbon/ with two faces (face 1 and face 2) with a cost inversely
   proportional to the validity of the Name Prefix.

6.  DABBER Operational Considerations








Mendes, et al.           Expires March 19, 2021                [Page 17]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


6.1.  Context Awareness

   DABBER defines routing and forwarding strategies that take into
   consideration, at a network level, the context of wireless nodes, and
   not just the history of contacts among wireless nodes.  Contextual
   information is obtained in a self-learning approach, by software-
   based agents running in each networked device, and not based on
   network wide orchestration.  Contextual agents are in charge of
   computing nodes and link related costs concerning availability and
   centrality metrics.  Contextual agents interact with DABBER via a
   well-defined interface: the contextual self-learning process is not
   an integrating part of the DABBER routing framework.

   The contextual agent (named Contextual Manager [UmobileD45])
   installed in each device can therefore be seen as an end-user
   background service that seamlessly captures wireless data to
   characterize the affinity network (roaming patterns and peers'
   context over time and space) and the usage habits and data interests
   (internal node information) of a node.  Data is captured directly via
   the regular MAC Layer (e.g., Wi-Fi, Bluetooth, LTE) as well as via
   native applications for which the user configures interests or other
   type of personal preferences.  For instance, an application can
   request a one-time configuration of categories of data interests
   (e.g., music, food).

   Based on the defined interface, DABBER is able of querying the local
   Contextual Manager about the characteristics of neighbor nodes, based
   on three types of information: i) Node availability (metric A); ii)
   Node centrality (metric C); iii) Node similarity (metric S):

   o Node Availability (A) gives an estimate of the node availability
   based on the usage of internal resources over time and space, as well
   as the usage of physical resources (battery status; CPU status,
   etc.).

   o Node Centrality (C) provides awareness about the node's affinity
   network neighborhood context.  This means that a list is kept with
   the following information about each neighbor: neighbour's node
   degree (number of nodes contacted in a predefined time window);
   Frequency of contacts between the neighbor and other nodes; Duration
   of each contact between the neighbor and other nodes; Importance of
   encountered nodes.

   The Contextual Manager keeps values for the mentioned metrics for
   different periods of time.  Encountered nodes can be of different
   types, such as other mobile devices or wireless access points, for
   instance.




Mendes, et al.           Expires March 19, 2021                [Page 18]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


6.2.  Integration with Wi-Fi Direct

   When Wi-Fi Direct is used on the MAC layer, there is a one-to-one
   correspondence between an OPPFace and a neighbor node (for each node
   detected in a Wi-Fi Direct Group, a new instance of an OPPFace is
   created).  In this peer-to-peer scenario, OPPFaces can be used in two
   transmission modes: connection-oriented, in which packets are sent to
   a neighbor node via a reliable TCP connection over the group owner;
   connection-less, in which packets are sent directly to a neighbor
   node during the Wi-Fi direct service discovery phase.  In the latter
   case data transmission is limited to the size of the TXT record (900
   bytes for Android 5.1 and above).  This type of communication is used
   to exchange small packets that require fast transmission (e.g.
   emergency apps, Chronosync status messages).  The connection-less
   solution allows peers to exchange a short number of bytes without the
   establishment of a TCP socket.

   In the peer-to-peer scenario of Wi-Fi direct, DABBER operates as
   follows: routing information is shared among all members of a Wi-Fi
   direct group, while Interest Packets are forwarded to specific
   neighbors.  With Dabber it is the carrier of an Interest packet that
   decides which of the neighbors will get a copy of the Interest
   packet.  Hence, with the current implementation of NDN-OPP, DABBER
   places a copy of the Interest packet in the OPPFaces of selected
   neighbors.  In what concerns the dissemination of routing
   information, it is ensured by: i) node mobility, meaning that nodes
   carry such information between Wi-Fi direct groups; ii) information
   is passed between neighbor groups via nodes that belong to more than
   one group.

   Based on the reception of notifications of Wi-Fi Direct regarding
   changes in the peers detected in the neighborhood, DABBER is able to
   update its internal peer list (Neighbor Table).  If it is not
   currently connected to a Wi-Fi Direct Group, it performs a selection
   heuristic to determine which node to connect to.  The motivation
   behind this selection process is to attempt to minimize the number of
   Wi-Fi Direct Groups in a certain area given that nodes can only
   transmit packets within the Group they are currently connected to.

   By defining OPPFaces implemented based on a broadcast link layer such
   as ad-hoc Wi-Fi, DABBER will need to create only one OPPFace in each
   networked device.  Such OPPFace would be used to exchange packets
   with any neighbor node, making use of the overhearing property of the
   wireless medium.  Since with DABBER, it is the carrier that decides
   which of the neighbors are entitled to get a certain Interest packet,
   DABBER would need to encode in the Interest packet information about
   the ID of the neighbors that should process the overheard Interest
   packet.



Mendes, et al.           Expires March 19, 2021                [Page 19]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


6.3.  Integration with DTN

   By defining a new DTNFace implemented based on the bundle layer,
   DABBER could make use of the end-to-end protocol, block formats, and
   abstract service description for the exchange of messages (bundles)
   described in the DTN architecture.  A DTNFace could provide a robust
   communications platform for the transmission of Data packets towards
   the consumer node, making usage of any available custodian nodes.

   The bundle protocol [RFC5050] introduces the concept of a "bundle
   agent" that manages the interface between applications and the
   "convergence layers" that provide the transport of bundles between
   nodes during communication opportunities.  A DTNFace would extends
   the bundle agent aiming to control the actions of the bundle agent
   during communication opportunities.

   A new DTNFace would aim to control the reception and delivery of
   bundles, which are placed in a queue during the forwarding of Data
   packets.  A DTNFace would allows the routing process to be aware of
   the bundles placed at the node, and allows it to inform the bundle
   agent about the bundles to be sent to a neighbor node.  Therefore,
   the bundle agent implemented in a DTNFace would need to provide the
   following interface/functionality to the forwarding process:

   o Get Bundle List: Returns a list of the stored bundles and their
   attributes to the routing agent.

   o Send Bundle: Notifies the bundle agent to send a specified bundle.

   o Drop Bundle Advice: Advises the bundle agent that a specified
   bundle may be dropped by the bundle agent if appropriate.

   o Acked Bundle Notification: Bundle agent informs routing agent
   whether a bundle has been delivered to its final destination and time
   of delivery.

6.4.  Producer Mobility

   As NDN uses a publish/subscribe communication model, where request
   resolution and data transfer are decoupled, it is especially relevant
   to solve the problem of data producer mobility.  Supporting producer
   mobility requires, first of all, finding the new location of the
   source each time data sources move, and, second, updating the name
   resolution system according to the new location, in order to maintain
   the consistency of NDN forwarding.






Mendes, et al.           Expires March 19, 2021                [Page 20]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


   This could be achieved by using a dissemination method to efficiently
   discover data sources by replicating Interest messages in an
   efficient way that avoids network flooding [Optimal-stopping].

   With this new feature the prospective forwarders for a given Interest
   message are limited in number and carefully selected in terms of
   three criteria:

   o Centrality: how well connected a node is in the network.  The more
   central a node is, the bigger the chances are to find a data source.

   o Reliability: the likeliness of a node does not drop messages.  The
   more reliable a node is, the least probable is that the Interest
   message will be discarded.

   o Similarity: how alike the contacted candidate node is in terms of
   shared acquaintances.  The less similar, the more likely is that it
   will find different nodes in the future.

   In the current version of DABBER, the degree of diffusion of Interest
   packets depends on the logic used to update the RIB on NFD (Increase
   diversity, Downward Path Criterion, Downward Path Criterion
   extension).  It may happen that the diffusion degree could still lead
   to some overhead.  In this case DABBER could be extended to allow
   nodes to select the most suitable node among all of the neighbors to
   forward the Interest message based on an optimal stopping approach.
   This strategy relies on the existence of an optimal set of stopping
   values such that the nth discoverer node for a certain Interest
   message is the first contacted node which is the best of all the
   previously explored nodes, if the node has contacted the first
   stopping value.  If this node is not found, then it will be the first
   node which is the second best of all the previous nodes, if the node
   has contacted the second stopping value, and so on.  Otherwise, if
   these nodes are not found, then, the nth discoverer node will be the
   last nth node before reaching the last contacted node.  This makes
   the dissemination of the Interest messages in Mobile NDNs efficient,
   even, and pervasive all over the network, increasing the delivery
   ratio while decreasing the network overhead.

7.  Security Considerations

   DABBER follows the CCN/NDN security framework built on public-key
   cryptography, allows it to secure the exchange of routing messages,
   by being able of verifying the authenticity of routing messages.
   Moreover, DABBER ensures the right level of privacy of the involved
   entities, who provide local information to support routing decisions.





Mendes, et al.           Expires March 19, 2021                [Page 21]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


   Routing security can be achieved not only by signing routing
   messages, but also by allowing the usage of multiple paths, as done
   by DABBER: when an anomaly is detected routers can retrieve the data
   through alternative paths.

   Besides the presented security and privacy considerations, the issue
   of Denial of Service (DoS) needs to be properly addressed.  An
   example is when a malicious user sends a high rate of broadcast
   messages aiming to exhaust available forwarding resources.

   The remainder of this section provides initial insights about the
   methods used by DABBER to ensure the authenticity, confidentiality of
   the routing message exchange as well as the privacy of the involved
   entities.

7.1.  Authenticity

   DABBER routing messages are carried in Data packets containing a
   signature.  Hence, a DABBER device can verify the signature of each
   routing message to ensure that it was generated by the claimed origin
   node and was not tampered with during dissemination.  For this
   purpose, DABBER makes use of a hierarchical trust model for routing
   to verify the keys used to sign the routing messages.

   DABBER can model a trust management as a five-level hierarchy,
   although reflecting a different administrative structure: represents
   the authority responsible by the international transit network
   allowing roaming services; represents the operator providing the
   mobile service; represents the network site of the mobile operator
   where the node is registered; represents the mobile equipment.  Each
   node can create a DABBER process that produces LSAs.

   Since keys must be retrieved in order to verify routing updates,
   DABBER allows each node to retrieve keys from its neighbors.  This
   means that a DABBER node will use the Interest/Data exchange process
   to gather keys from all its direct neighbors.  Upon the reception of
   an Interest of the type //broadcast/KEYS each neighbor looks up the
   requested keys in their local key storage and returns the key if it
   is found.  In case a neighbor does not have the requested key, the
   neighbor can further query its neighbors for such key.  The used key
   retrieval process makes use of a broadcast forwarding strategy,
   stopping at nodes who either own or cache the requested keys.

7.2.  Confidentiality

   Although being deployed under the control of an operator, DABBER
   allows its network to be extended beyond the reach of its
   infrastructure network, into scenarios where wireless communications



Mendes, et al.           Expires March 19, 2021                [Page 22]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


   between involved DABBER devices/router may be spoofed.  Hence, DABBER
   requires routing data confidentiality to ensure the setup of a secure
   communication topology.

   DABBER basic approach relies on the usage of encryption to protect
   the confidentiality of routing messages.  By taking advantage of the
   semantically meaningful names DABBER relies on approaches such as
   Named-based Access Control (NAC) [NAC].  NAC provides content
   confidentiality and access control based on a combination of
   symmetric and asymmetric cryptography algorithms, while using NDN's
   data-centric security and naming convention to automate data access
   control.

   Being implemented in wireless devices that may energy constraint, it
   will be important to verify the efficiency of the cryptographic
   solution, namely since the generation of asymmetric key pairs as well
   as the symmetric and asymmetric encryption/decryption operations may
   be expensive in terms of the usage of resources.

7.3.  Privacy

   In DABBER, forwarding decisions are taken into account using
   different metrics such as centrality and similarity.  While these
   metrics may be efficient in terms of node selection, they can breach
   privacy of network users carrying networked devices by inferring
   social related information such as position inside groups, as well as
   information about the devices themselves.

   If exchanged as clear text, the information carried in routing
   metrics may potentially compromise the privacy of users.  A way of
   preserving the privacy of the users in DABBER could pass by using
   homomorphic encryption for information-centric wireless Ad Hoc
   Networks.

   With homomorphic encryption forwarding decisions are made by
   performing calculations on encrypted forwarding metric values without
   decrypting them first, while maintaining low overhead and delays.  As
   a result, forwarding decisions can be taken preserving the user's
   privacy.  For these purposes, homomorphic encryption is extremely
   useful.  This cryptographic scheme allows computations on ciphertexts
   and generates encrypted results that, when decrypted, match the
   results of the operations as if they had been performed on
   plaintexts.








Mendes, et al.           Expires March 19, 2021                [Page 23]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


8.  IANA Considerations

   This document has no actions for IANA.

9.  Acknowledgments

   The research leading to these results received funding from the
   European Union (EU) Horizon 2020 research and innovation programmer
   under grant agreement No 645124(Action full title: Universal, mobile-
   centric and opportunistic communications architecture, Action
   Acronym: UMOBILE).

10.  References

10.1.  Normative References

   [DABBER18]
              Mendes, P., Sofia, R., Soares, J., Tsaoussidis, V., and S.
              Diamantopoulos, "Information-centric Routing for
              Opportunistic Wireless Networks", in Proc. of ACM
              Information Centric Networking , September 2018.

   [DABBER18-1]
              DABBER Development Team, "DABBER Source Code",
              https://github.com/COPELABS-SITI/ndn-opp/tree/dabber  ,
              September 2020.

   [DABBER18-2]
              DABBER Development Team, "DABBER Android",
              https://play.google.com/store/apps/
              details?id=pt.ulusofona.copelabs.ndn , September 2020.

   [NDN-OPP]  Tavares, M. and P. Mendes, "NDN-Opp: Named-Data Networking
              in Opportunistic Networks", Technical Report COPE-SITI-TR-
              18-01 , January 2018.

   [NFD]      A. Afanasyev, et al, "NFD Developer's Guide", NDN
              Technical Report NDN-001 , October 2010.

10.2.  Informative References

   [ChronoSync]
              Zhu, Z. and A. Afanasyev, "Lets ChronoSync:Decentralized
              Dataset State Synchronization in Named Data Networking",
              in Proc. IEEE ICNP , October 2013.






Mendes, et al.           Expires March 19, 2021                [Page 24]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


   [Dlife]    Moreira, W., Mendes, P., and S. Sargento, "Opportunistic
              Routing based on daily routines", in Proc. of IEEE WoWMoM
              workshop on autonomic and opportunistic communications,
              San Francisco, USA , June 2012.

   [Dlife-draft]
              Moreira, W., Mendes, P., and E. Cerqueira, "Opportunistic
              Routing based on Users Daily Life Routine", IETF Internet
              Draft (draft-moreira-dlife-04) , May 2014.

   [NAC]      Z. Zhang, et al, "NAC: Automating Access Control via Named
              Data", in IEEE MILCOM , October 2018.

   [NDN-emergency]
              Tavares, M., Aponte, O., and P. Mendes, "Named-data
              Emergency Network Services", in ACM MOBISYS, Munich,
              Germany , June 2018.

   [NDN-OPP-Android]
              NDN-OPP Development Team, "NDN-OPP Android",
              https://github.com/COPELABS-SITI/ndn-opp , September 2020.

   [NDN-opportunisticnets]
              Dynerowicz, S. and P. Mendes, "Named-Data Networking in
              Opportunistic Networks", ACM ICN, Berlin, Germany ,
              September 2017.

   [OI]       Lopes, L., C. Sofia, R., Mendes, P., and W. Moreira, "Oi!
              Opportunistic Data Transmission Based on Wi-Fi Direct", in
              Proc. of IEEE INFOCOM , April 2016.

   [Optimal-stopping]
              Borrego, C., Amado, M., Molinaro, A., Mendes, P., C.
              Sofia, R., Magaia, N., and J. Borrel, "Forwarding in
              Opportunistic Information-Centric Networks: An Optimal
              Stopping Approach", IEEE Communications Magazine, 58(5),
              56-61 , 2020.

   [PartialSync]
              Zhang, M., Lehman, V., and L. Wang, "PartialSync:Efficient
              Synchronization of a Partial Namespace in NDN", NDN
              Technical Report NDN-0039 , June 2016.

   [RFC4838]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
              R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
              Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
              April 2007, <https://www.rfc-editor.org/info/rfc4838>.




Mendes, et al.           Expires March 19, 2021                [Page 25]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


   [RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", RFC 5050, DOI 10.17487/RFC5050, November
              2007, <https://www.rfc-editor.org/info/rfc5050>.

   [RFC7476]  Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G.,
              Tyson, G., Davies, E., Molinaro, A., and S. Eum,
              "Information-Centric Networking: Baseline Scenarios",
              RFC 7476, DOI 10.17487/RFC7476, March 2015,
              <https://www.rfc-editor.org/info/rfc7476>.

   [Scorp]    Moreira, W., Mendes, P., and S. Sargento, "Social-aware
              Opportunistic Routing Protocol based on User's
              Interactions and Interests", in Proc. of AdhocNets,
              Barcelona, Spain , October 2013.

   [Umobile]  C. Sarros, et al, "Connecting the Edges: A Universal,
              Mobile centric and Opportunistic Communications
              Architecture", IEEE Communication Magazine , February
              2018.

   [UmobileD45]
              R. Sofia, et al, "UMOBILE D45 - Report on Data Collection
              and Inference Models", Umobile Technical Report ,
              September 2018.

Authors' Addresses

   Paulo Mendes (editor)
   Airbus
   Willy-Messerschmitt Strasse 1
   Munich  81663
   Germany

   Email: paulo.mendes@airbus.com
   URI:   http://www.paulomilheiromendes.com


   Rute C. Sofia
   fortiss GmbH
   Guerickestrasse 25
   Munich  80805
   Germany

   Email: sofia@fortiss.org
   URI:   http://www.rutesofia.com






Mendes, et al.           Expires March 19, 2021                [Page 26]


Internet-Draft        draft-mendes-icnrg-dabber-05        September 2020


   Vassilis Tsaoussidis
   Democritus University of Thrace
   University Campus
   Komotini  69100
   Greece

   Email: vtsaousi@ee.duth.gr


   Carlos Borrego
   Autonomous University of Barcelona
   Department of Information and Communications Engineering
   Bellaterra  08193
   Spain

   Email: carlos.borrego@uab.cat



































Mendes, et al.           Expires March 19, 2021                [Page 27]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/