ICN Research Group P.Mendes
Internet-Draft COPELABS/University Lusofona
Intended Status: Experimental Rute Sofia
Expires: August 27, 2018 Senception/COPELABS/University Lusofona
Vassilis Tsaoussidis
Sotiris Diamantopoulos
Christos-Alexandros Sarros
Democritus University of Thrace
February 23, 2018
Information-centric Routing for Opportunistic Wireless Networks
draft-mendes-icnrg-dabber-00
Abstract
This draft describes the Data reAchaBility BasEd Routing (DABBER)
protocol, which has been developed to extend the reached of Named
Data Networking based routing approaches to 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 towards the most suitable data source, based on
metrics that provide information about: i) the availability of
different data sources; ii) the availability and centrality of
neighbor nodes; iii) the time lapse between forwarding Interest
packets and receiving the corresponding data packets. The document
presents an architectural overview of DABBER followed by
specification options related to the dissemination of name-prefix
information to support the computation of next hops, and the ranking
of forwarding options based on the best set of neighbors to ensure a
short time-to-completion.
Status of this Memo
This Internet-Draft is submitted to IETF 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 http://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
Mendes, et al. Expires August 27, 2018 [Page 1]
Internet-Draft dabber February 23, 2018
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 27, 2018.
Copyright and License Notice
Copyright (c) 2018 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
(http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Contextual Aspects . . . . . . . . . . . . . . . . . . . . 5
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. NFD Adjustment to Opportunistic Networks . . . . . . . . . 7
1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 8
2. DABBER Architecture . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Assumptions and Requirements . . . . . . . . . . . . . . . 10
2.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. LSA Dissemination . . . . . . . . . . . . . . . . . . . . . 12
2.4. Multiple path Computation . . . . . . . . . . . . . . . . . 13
2.4.1. Cost Computation . . . . . . . . . . . . . . . . . . . 14
2.4.2. RIB Update with Face Selection . . . . . . . . . . . . 14
2.4.3. FIB Update with Face Ranking . . . . . . . . . . . . . 15
2.4.4. LSDB Updates . . . . . . . . . . . . . . . . . . . . . 16
2.5. Loop Prevention . . . . . . . . . . . . . . . . . . . . . . 17
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 17
3.1. Overall Operation Example . . . . . . . . . . . . . . . . . 17
3.2. Peer Discovery and Face Setup . . . . . . . . . . . . . . . 19
3.3. LSA Exchange . . . . . . . . . . . . . . . . . . . . . . . 20
3.4. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . 21
3.5. Failure and Recovery . . . . . . . . . . . . . . . . . . . 21
3.6. Interface towards a Contextual Agent . . . . . . . . . . . 22
4. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 22
4.1. Interoperability with NDN operation over DTNs . . . . . . . 22
4.2. Interoperability with NDN operation in wired networks . . . 23
4.2.1. Interoperability with NLSR . . . . . . . . . . . . . . 23
4.2.2. Interoperability with broadcast based forwarding . . . 24
Mendes, et al. Expires August 27, 2018 [Page 2]
Internet-Draft dabber February 23, 2018
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 24
6. Implementation and Deployment Experience . . . . . . . . . . . 25
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1 Normative References . . . . . . . . . . . . . . . . . . . 25
8.2 Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Mendes, et al. Expires August 27, 2018 [Page 3]
Internet-Draft dabber February 23, 2018
1. Introduction
In a networking scenario where an increasing number of wireless
systems, such as end-user nodes and mobile edge nodes, are being
deployed, there are two networking paradigms that are highly
correlated to the efficiency of pervasive data sharing: Information-
Centric Networking (ICN), and opportunistic wireless networking. The
latter concerns the capability of exploiting any potential wireless
communication opportunity to exchange data in a multi-hop wireless
networks, where it is difficult to find an end-to-end path between
any pair of nodes at any moment in time.
Combining opportunistic networking with ICN principles is relevant to
efficiently extend the applicability of information-centric
networking to novel scenarios, such as affordable pervasive access;
low cost extension of access networks; edge computing; vehicular
networks.
This document describes the Data reAchaBility BasEd Routing (DABBER)
routing protocol for information-centric wireless opportunistic
networks. These networking architectures are operationally located on
the Internet fringes (Customer Premises). In such areas, networking
experiences intermittent connectivity and variable availability of
nodes due to their movement and/or due to other constrains, e.g.,
limited battery, storage, and processing.
DABBER has been therefore designed to be compatible with the routing
deployed within ICN access networks. Its main purpose is to assist in
extending the reach of multi-hop transmission to opportunistic
environments, in a seamless and fully interoperable way.
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, and not just the
history of contacts among wireless nodes. The goal is to assist in
better defining opportunities for the transmission of Interest
packets over time and space. Such opportunities can be better
addressed if routing metrics take into consideration, as common in
opportunistic environments, measures of centrality, as well as
measures of node and data availability.
Being NDN[1][2] a well established ICN framework, the first step
proposed by this draft is to extend the current de facto NDN routing,
Named-data Link State Routing protocol (NLSR)[19][20], in a way that
allows the benefits of link-state approaches, while delimiting its
downsize in the context of the wireless medium.
DABBER is intended as complementing existing forwarding protocols for
Mendes, et al. Expires August 27, 2018 [Page 4]
Internet-Draft dabber February 23, 2018
opportunistic networks (e.g., Prophet [12], Scorp [13], dLife
[14][18], BubbleRap [15]).
1.1. Contextual Aspects
Prior art in forwarding solutions for opportunistic networks showed
that data transmission in such wireless environments needs to be done
based on strategies that take into consideration, at a network level,
the context of wireless nodes, and not just the history of contacts
among wireless nodes.
This section provides an example on how to obtain contextual
information that defines the availability and centrality of a
wireless node, based on a specific operational example that is being
developed in the context of the H2020 UMOBILE project [17].
Contextual information is obtained in a self-learning approach, by
software-based agents running in wireless nodes, and not based on
network wide orchestration. Contextual agents are in charge of
computing node and link related costs concerning availability and
centrality metrics. Contextual agents interact with DABBER via well-
defined interfaces. This to say that the contextual self-learning
process is not an integrating part of the routing plane, as it would
add additional complexity to the simplified routing plane of NDN.
The contextual agent (named Contextual Manager, CM [7]) installed in
each wireless node 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 (cf. section 3.6), DABBER is able of
querying the local Contextual Manager about the characteristics of
neighbor nodes, based on two types of information: Node availability
(metric A); ii) Node centrality (metric C).
Node Availability (A) gives an estimate of the node availability
based on the usage of internal and external resources over time and
space. In what concerns external resources, one SHOULD consider, for
instance, indicators such as the preferred visited network and/or
location of the node; in what concerns internal resources, one SHOULD
consider the time spent per application category (e.g. per day), as
Mendes, et al. Expires August 27, 2018 [Page 5]
Internet-Draft dabber February 23, 2018
well as the usage of physical resources (battery status; CPU status,
etc).
Node centrality (C) provides awareness about a node's affinity
network neighborhood context. For instance, aspects such as the
traditional contact duration between neighboring nodes and add
information derived from network mining such as cluster distance, and
network diameter MAY be the basis for the computation of centrality.
The detailed specification of the contextual manager is out of scope
of this document. Nevertheless, code for such an agent is being
provided openly in the context of the H2020 UMOBILE project [7]. What
is relevant to have in mind, from a routing perspective, is that this
contextual plane provides weights (A and C) to assist the routing
protocol in ranking next hops, which is an aspect highly relevant in
the context of multiple path routing. We believe that contextual
awareness can assist NDN routing schemes in better dealing with
topological variability, by anticipating changes derived from prior
learning.
1.2. Applicability
DABBER is being developed to allow the deployment of wireless NDN
networks where nodes and links can be intermittently available. From
an end-to-end perspective we can consider two scenarios: the NDN
wireless network is at the fringes of the NDN core; the NDN wireless
network can interconnect different NDN fixed networks.
While the latter may support applicability scenarios typical of
Delay-Tolerant Networks (DTN)[21][22]for instance tunneling traffic
over an area lacking network deployment, the former allows the
extension of the applicability of information-centric networking to
novel scenarios such as affordable pervasive data access, low cost
extension of access networks, edge computing, and vehicular networks:
Affordable pervasive data access:
This scenario encompasses the implementation of NDN 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 environment without/or
limited Internet access.
Low cost extension of access networks:
This scenario refers to the usage of wireless nodes (mobile or
fix) to extend the reach of an NDN networks while reducing CAPEX
costs.
Edge/Fog computing:
Mendes, et al. Expires August 27, 2018 [Page 6]
Internet-Draft dabber February 23, 2018
This scenario is related to the efforts being done to bring cloud
computing closer to the end-users. This scenario encompasses a
large set of heterogeneous (wireless and sometimes autonomous)
decentralized nodes able of communicating, directly or via an
infrastructure, in order to perform storage and processing tasks
without the intervention of third parties. This scenario deals
with nodes that might not be continuously connected to a network,
such as laptops, smartphones, tablets and sensors, as well as
nodes that may be intermittently available due to scarce
resources, such as wireless access routers and even Mobile Edge
Computing (MEC) servers.
V2X networks:
This scenario deals with the intermittent connectivity between
vehicles as well as between vehicles and the infrastructure.
1.3. NFD Adjustment to Opportunistic Networks
The main functionality of the Named-Data Networking Forwarding Daemon
(NFD) [7] is to forward Interest and Data packets. This section
provides a set of design considerations that need to be considered to
allow the operation of NFD in opportunistic wireless networks. Such
considerations have been implemented in a new branch of NDN, called
NDN-OPP [3], which code of available on GitHub
(https://github.com/COPELABS-SITI/ndn-opp).
NDN-OPP introduces a few modifications in the way NFD performs its
forwarding, by leveraging the concept of Faces in order to adapt the
operation of the NFD to the intermittent property of wireless
connections. This is done by the implementation of a new type of
face, called Opportunistic Face - OPPFace.
Each OPPFace is based on a system of packet queues to hide
intermittent connectivity from NFD: instead of dispatching packets
from the FIB, the OPPFace is able of delaying packet transmission
until the wireless face is actually connected. OPPFaces are kept in
the Face Table of the forwarder and their state reflects the wireless
connectivity status: they can be in an Up or Down state, depending
upon the wireless reachability towards neighbor nodes. Since packet
queuing is concealed inside OPPFaces, no other part of the NFD or any
existing forwarding strategy needs to be changed.
OPPFaces can be implemented by using any direct wireless/cellular
communication mode (e.g., Ad-Hoc Wi-Fi, Wi-Fi Direct, D2D LTE, DTN).
The current operational version of NDN-OPP (V1.0) makes usage of
group communications provided by Wi-Fi Direct. In this case there is
a one-to-one correspondence between an OPPFace and a neighbor node.
Mendes, et al. Expires August 27, 2018 [Page 7]
Internet-Draft dabber February 23, 2018
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).
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.
In a scenario where NDN-OPP would have OPPFaces implemented based on
a broadcast link layer, such as ad-hoc Wi-Fi, only one OPPFace would
be created in each node. 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 entitle 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.
This means that the operation of DABBER is the same independently of
the nature of the link layer protocol, the only different being the
number of transmissions that needs to be done at the link layer to
forward Interest packets and to disseminate routing information.
Besides the OPPFaces towards neighbor wireless nodes, NDN-OPP makes
use of the Wi-Fi Face, already defined in NFD, and will integrate the
DTN Face developed in the UMOBILE project[23]. This means that DABBER
is able of exploiting any available wireless Face (OPPFace, Wi-Fi
Face, DTN Face). Future versions of NDN-OPP will allow DAGGER to
exploit interfaces to other wireless access networks, such as LTE.
A detailed specification of NDN-OPP and OPPFaces can be found in [3].
In the remainder document we will refer to OPPFaces, Wi-Fi Faces and
DTN Faces simply as Faces.
1.4. Conventions
Mendes, et al. Expires August 27, 2018 [Page 8]
Internet-Draft dabber February 23, 2018
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. In this
document, these words will appear with that interpretation only
when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying significance described in RFC 2119.
2. DABBER Architecture
This section presents an overview of the overall DABBER protocol
architecture. The three major considerations to architect DABBER are:
i) In opportunistic networks it is not possible to know the
complete network topology. Hence, there is no need to disseminate
Adjacency information.
ii) In opportunistic networks it is not efficient to flood the
network, as shown by all prior solutions based on controlled
packet replication forwarding ([12][13][14][18][15]) instead of
broadcast as used in Epidemic routing.
iii) Selecting the best set of neighbors to replicate packets to,
may not be efficient if based only on connectivity based
information (e.g. inter-contact times, contact duration).
Node A Node B
+----------+ +------------+
N - |1 2| - N----- |1 2|
| | | |
|3 4| - N |3 4|
+----------+ | +------------+
| Node C
| +------------+
------ |1 2|
| |
|3 4|
+------------+
RIB FIB
+----------------------------+ +---------------------+
|Prefix Name | Face | Cost | | Prefix Name | Faces |
+----------------------------+ +---------------------+
| N | 2 | 3 | | N | 1,2 |
| N | 4 | 10 | | | |
| N | 1 | 5 | +-------------------- +
+----------------------------+
Mendes, et al. Expires August 27, 2018 [Page 9]
Internet-Draft dabber February 23, 2018
Figure 1: RIB and FIB Management, node A.
DABBER relies on the same message formats, message exchange process,
and same data structures (RIB and FIB), made available by NDN, and
used by NLSR. As shown in figure 1, both protocols are able of
populating the FIB with a list of next hops towards each name prefix.
This is done based on the information collected from neighbor nodes
and stored in the RIB.
However, NLSR needs to build a full network topology, based on
Adjacency Link State Advertisements (LSA), to compute shortest paths
towards each node in the network (based on a simple extension of the
Dijkstra's algorithm). After this, NLSR computes shortest paths
towards each data source by associating each router with name
prefixes, based on the information exchanged via Prefix LSAs. Such
name prefixes are ordered in the FIB based on the distance of the
path towards the data source (shortest first).
While NLSR relies on the dissemination of Adjacency and Prefixes
LSAs, DABBER only requires the dissemination of Prefix LSAs and does
not require the computation of shortest paths: DABBER replaces the
path cost used by NSLR with a data reachability cost, as described in
section 2.4, reducing the impact that topological changes would have
on the stability of routing information.
The computation of data reachability costs towards different data
sources, based on the local dissemination of name prefixes, aims to
avoid flooding the wireless network with Interest packets that would
otherwise be broadcast to all potential data sources.
Another difference towards NLSR is the face ranking in the FIB. While
NLSR ranks faces based only of the path distance towards the data
source, DABBER considers a set of local variables that characterize
the neighbors, and the time lapse between forwarding an Interest
packets and receiving the corresponding data packet, as described in
section 2.2.4.
2.1. Assumptions and Requirements
DABBER relies on the following assumptions:
o Mobile nodes are able of exploiting wireless connectivity. For
instance having NDN-OPP installed.
o Mobile nodes can be a source and destination of data, being able
of operating as a router: there is not a clear distinction, in
terms of routing process, between sources, destinations, and
Mendes, et al. Expires August 27, 2018 [Page 10]
Internet-Draft dabber February 23, 2018
routers.
In terms of requirements:
o LSAs must be exchanged based on Interest / Data messages, as in
NSLR.
o A synchronization mechanism should be used to exchange LSAs
among neighbor node, as in NSLR.
o LSAs should be used to distribute only name prefix reachability,
since building a network topology based on adjacency information
is not feasible in an opportunistic network.
o Multiple next-hops for each name prefix must be computed based
on local information that encodes data reachability.
o Link failure recovery must be local and hence, the recovery
process should be based on the operation of OPPFaces (UP/Down link
management).
o IP addresses or any other form of addressing a node in the
network must not be considered, as in NLSR.
o Selective information diffusion must be considered, in order to
avoid network flooding.
o Data sources must set the validity of name prefixes - validity v
- as an integer that represents the expiration date of the data.
2.2. Naming
DABBER makes use of NDN hierarchical naming scheme to identify each
wireless node. This strategy is similar to the one used by NLSR. The
difference is in the name semantics: being a routing protocol for
wired networks, NLSR uses names that reflect network structures and
operational practices, making it easy to identify routers belonging
to the same network, and operator realms. In NLSR each router is
named according to the network it resides in, the specific site it
belongs to, as well as an assigned router name, i.e.,
/<network>/<site>/<router>. For example, /ATT/AtlantaPoP1/router3.
This semantics provide additional topological information to the
routing process.
In a wireless networking environment, a hierarchical naming scheme
still makes sense to identify to which network operator does the
mobile node belongs to and to the home site, in case the mobile
Mendes, et al. Expires August 27, 2018 [Page 11]
Internet-Draft dabber February 23, 2018
operator has more than one operational site. Since DABBER is used to
exchange data directly between mobile nodes in an opportunistic
networking scenario, it makes use of a hierarchical naming scheme
that reflects the way mobile roaming works: When a mobile node is
used outside its home, it attempts to communicate with a visited
mobile network. The visited network recognizes that the node does not
belong to any of its networks, and checks if there is a roaming
agreement between the home network and one of the networks of the
visited operator. If so the call is routed towards an international
transit network.
Based on the operation of a mobile network, the following semantics
is used to name DABBER nodes:/<network>/<operator>/<home>/<node>,
where <network> represents the international transit network allowing
roaming services for the mobile operator; <operator> refers to the
operator providing the mobile service; <home> is the network site of
the mobile operator where the node is registered; <node> is the
mobile equipment.
The hierarchical name is used to implement a trust model to allow
nodes to verify the signature of routing messages, as described in
section 5.
The information included in the hierarchical name may be used to
select next hops belonging to the same operator network, or nodes
that have the same home network. It is assumed that an opportunistic
wireless network is build based on wireless direct connectivity
between nodes that may belong to different operators and home
networks, but that may have roaming patterns that allows them to have
frequent wireless contacts.
2.3. LSA Dissemination
As happens with NLSR, DABBER runs on top of NDN, making use of
Interest/Data packets to exchange LSAs. This means that while IP-
based routing protocols push updates to other routers, DABBER nodes
need to pull the updates.
As happens with NLSR, DABBER can use any underlay communication
channels (e.g., TCP/UDP tunnels, Link layer TXT records) to exchange
LSA information.
Moreover, DABBER benefits from NDN built-in data authenticity: since
a routing update is carried in an NDN data packet and every NDN data
packet carries a signature, a DABBER node can verify the signature of
each LSA message to ensure that it was generated by the claimed
origin node and was not tampered during dissemination.
Mendes, et al. Expires August 27, 2018 [Page 12]
Internet-Draft dabber February 23, 2018
Similarly to what happens with NLSR, DABBER disseminates LSAs via a
data synchronization mechanism (e.g. ChronoSync [9], PartialSync
[10]) of the local LSDB.
The main differences towards NLSR are:
o Contrary to NLSR, DABBER does not disseminate Adjacency LSAs to
reflect the status of the links towards neighbor nodes.
o As NSLR, DABBER advertises Prefix LSAs every time a new name
prefix is added or deleted to the LSDB. However in the case of
DABBER, name prefixes are advertised with a cost/metric related to
the validity of the associated data.
This peer synchronization approach is receiver-driven, meaning that a
node will request LSAs only when it has CPU cycles. Thus it is less
likely a node will be overwhelmed by a flurry of updates. In order to
remove obsolete LSAs, every node periodically refreshes 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. The LSA format is shown in Figure 2.
Prefix LSA
+-----------------------------------------------------------------+
| LSA | Number of |Prefix 1|Cost| ... |Prefix N|Cost| Signature |
| Name | Prefixes | | | | | | |
+-----------------------------------------------------------------+
Figure 2: Prefix LSA format.
Each LSA used by DABBER has the name
<network>/<operator>/<home>/<node>/DABBER/LSA/Prefix/<version>. The
LSA <version> is increased by 1 whenever a node creates a new version
of the LSA.
A detailed description of the LSA exchange process is provided in
section 3.3.
2.4. Multiple path Computation
As mentioned, DABBER considers that there is a set 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 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 higher k 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.
Mendes, et al. Expires August 27, 2018 [Page 13]
Internet-Draft dabber February 23, 2018
Since different nodes 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 Prefix LSA (or a new version of an existing Prefix LSA) in
its LSDB (c.f. section 2.3). The sequence of operations, as described
in the following sub-sections are: Update of the RIB based on a face
selection criteria; Update of the FIB based on a face ranking
strategy; Update of the LSDB with the updated cost of the local
Prefix LSA.
2.4.1. Cost Computation
When DABBER is notified that a new Prefix LSA was entered 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.
DABBER computes a new cost k for a prefix N depending upon the cost
announced by the neighbor (e.g., 3 in the case of N announced by node
B in figure 1), and the relevancy of the "relation" between the two
neighbor nodes (e.g., node A and node B).
The relevancy of the "relation" between two neighbor nodes can be,
e.g., a measure of similarity [7], 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, as is common in
opportunistic environments, on metrics derived from average contact
duration thus allowing a node to adjust the Name Prefix cost k based
on the probability of meeting the respective neighbor again.
2.4.2. RIB Update with Face Selection
After computing the new value of the cost k of a name prefix, as
described in section 2.4.1, DABBER updates the RIB entry of that name
prefix with the face over which the Prefix LSA was received based on
the logic assigned to that name prefix.
DABBER assigns selection logics to name prefix, such as NDN assigns
forwarding strategies to name prefixes.
There may be different available logics to choose from:
o Increase diversity - The new Face is included in the RIB entry,
if the computed cost k helps to increase diversity of the name
Mendes, et al. Expires August 27, 2018 [Page 14]
Internet-Draft dabber February 23, 2018
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.
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.
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
packet from looping back, there is the need to add a tiebreaker,
which assures that traffic only crosses one direction of equal-
cost links.
2.4.3. FIB Update with Face Ranking
FIB updates are performed by selecting a certain number RIB entries
with a lower cost k, aiming to allow the forwarding strategy to use a
maximum number of next hops per name prefix. This maximum number of
FIB entries (F) is defined by configuration in order to control the
size of the FIB table in an environment where each node may have a
large set of neighbors, as is the case of an opportunistic network.
In order to increase the performance of any NDN forwarding strategy,
DABBER ranks the faces installed in the FIB, based on the
contextualization variables described in section 1.1, and a measure
of the distance towards the data source:
o Node centrality C, aiming to select neighbors with high
probability of successfully forwarding Interest packets;
o Node availability A, aiming to select neighbors able to process
Interest packets with high probability;
o Time-to-completion T, i.e., time lapse between forwarding an
Interest packets and receiving the corresponding data packet,
aiming to select neighbors closer to a data source.
The CM provides the values of C and A for each face, periodically or
on demand, every time the FIB is updated. The values provided by the
CM are stored in a FACE Table as shown in figure 3. The higher the
values of C and A the most preferential a face is.
Mendes, et al. Expires August 27, 2018 [Page 15]
Internet-Draft dabber February 23, 2018
Face table
+--------------------------------------------+
| Face | Status | Metric C | Metric A |
+--------------------------------------------+
| 1 | UP | 6 | 3 |
| 2 | DOWN | 4 | 12 |
| 3 | UP | 1 | 8 |
+--------------------------------------------+
Figure 3: Face table.
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.
2.4.4. LSDB Updates
The LSBD of a node starts by being updated every time a new Prefix
LSA is received from a neighbor node, as a consequence of the LSA
dissemination process described in section 2.3.
The reception of new Prefix LSA, or of new versions of existing
prefix LSA leads to the computation of a cost k to each name prefix
carried in the LSA, and the inclusion of such value in the RIB entry
corresponding to the respective name prefix as described in this
section.
After updating the RIB, and while populating the FIB, DABBER needs to
update in the LSDB its own Prefix LSA with the updated information
about the revised name prefix. The cost of the announced name prefix
is the lowest from all the RIB entries related to such name prefix.
Giving as example node A in Figure 1, it will include the following
Prefix LSA in its LSDB after the LSA dissemination with nodes B and
C:
o <network>/<operator>/<home>/Node B/DABBER/LSA/Prefix/d1
including a cost of 3 for name prefix N
o <network>/<operator>/<home>/Node C/DABBER/LSA/Prefix/d1
including a cost of 10 for name prefix N
After updating its RIB, node A will include the following Prefix LSA
in its LSDB:
o <network>/<operator>/<home>/Node A/DABBER/LSA/Prefix/d1
Mendes, et al. Expires August 27, 2018 [Page 16]
Internet-Draft dabber February 23, 2018
including a cost of 3 for name prefix N
2.5. Loop Prevention
Given the multi-path nature of DABBER, the incoming Face might appear
among the potential next-hops for a given name prefix. For this
reason, DABBER applies the Incoming Face Exclusion principle [11] in
order to prevent forwarding Interest packets back though the Face
them came from, thus removing two-hop loops.
Furthermore, in order to detect longer forwarding loops (more than
two hops), DABBER relies on the nonce-based detection scheme
available in NDN in order to drop a looping packet as soon as it is
received the second time.
In addition, DABBER considers a loop removal mechanism, which takes
care of disabling the Face responsible for the looping once it is
detected, as described in section 3.4.
3. Protocol Overview
3.1. Overall Operation Example
We consider the scenario in Figure 4 to assist in the protocol
operation overview: namely to understand to role of DABBER to allow
extension of NDN operation towards wireless dynamic networks. In
Figure 4, nodes A, B, and C reside in an opportunistic network and
run DABBER, while nodes E and F are wireless edge routers running
another NDN routing/forwarding protocol, such as NLSR. G is a
wireless node running DABBER.
+--------------------+
| +---+ |
| | B | . |
| +---+ .2+---+ | +---+ +---+ +---+
|+---+ | C |3 ... | E |....| F |....| G |
|| A |.......1+---+ | +---+ +---+ +---+
|+---+ |
+--------------------+
Figure 4: 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
Store with the name /NDN/video/Lisbon/nighview.mpg. Node B stored in
its Content Store a data object with name
/NDN/video/Lisbon/river.mpg, which node B received from a neighbor
Mendes, et al. Expires August 27, 2018 [Page 17]
Internet-Draft dabber February 23, 2018
(meaning that B have already synchronize 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 cost
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 cost k is the result of
the cost computation process (cf. section 2.4).
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, as
explained in section 3.3. This LSA exchange is done when the OPPFaces
are up, as described in section 3.2. Node C, which got a new Prefix
LSA from nodes A and B, will:
o Updates its LSDB with the Prefix LSAs received from node A and
node B.
o Updates its RIBs 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):
o The cost 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,
and therefore the link cost is 0.8, while B and C do not meet
frequently and the link cost is 0.1. This means that node C
stores 2 new entries for prefix /NDN/video/Lisbon/ in its RIB
related to face2 with a cost of 51840 and related to face1 with
a cost of 691200.
o Update their FIBs with one new entry for the name prefix
/NDN/video/Lisbon/ with two faces: face 1 and face 2, since F
equals 4.
o Ranks the faces in the FIB entry as <face2,face1> since the
information stored in the Face Table shows that node B is more
available that node A and has higher centrality. At the moment
there is no information about the time-to-completion.
o Updates its LSDB with a local Prefix LSA (as described in
section 2.4.4) including the name prefix /NDN/video/Lisbon/ and
the lowest cost that such prefix has on its RIB.
Mendes, et al. Expires August 27, 2018 [Page 18]
Internet-Draft dabber February 23, 2018
Based on this status of the FIB all interest packets that node C gets
for the name prefix /NDN/video/Lisbon/ will be forwards to the number
of faces associated to the used forwarded strategy, but respecting
the ranking of faces done by DABBER.
When node C gets in the range of router E (wireless edge router) it
will exchange disseminate routing information, based on some
interoperability issues need to be considered, as described in
section 4.
3.2. Peer Discovery and Face Setup
In an opportunistic network DABBER needs to manage the dynamic
connectivity among neighbor nodes. For this proposes the DABBER
protocol relies on a background process, the Connectivity Manager.
The current version of DABBER comes with a Connectivity Manager for
Wi-Fi Direct. However, such connectivity manager can be easily
extended to integrate other type of wireless or cellular support. The
description here provided is adjusted to the case of Wi-Fi Direct.
When booted, the Connectivity Manager starts reacting to changes in
the peers available within scanning range of the current node. It
oversees managing the connection to a Wi-Fi Direct Group and
automatically joins a Group if it is not part of one.
Upon the reception of notifications regarding changes in the peers
detected in the neighborhood, the Connectivity Manager updates its
internal peer list. 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.
The heuristic simply favors whichever Group Owner is already detected
among the available peers. In the case there is exactly one Group
Owner, the current node attempts to join its Group. If more than one
or no Group Owners are available, the heuristic selects the non-
client node with the highest UUID. If the selected node is not the
current node, a connection is attempted. This heuristic guarantees
that the current node will never attempt to connect to a Client, thus
breaking an existing Group. Also, all nodes located in an area and
have the same view of available peers will all select the same node
as the Group Owner to which connection should be attempted.
For each node detected in a Wi-Fi Direct Group, a new instance of an
OPPFace is created. The status of an OPPFace tells us if the
Mendes, et al. Expires August 27, 2018 [Page 19]
Internet-Draft dabber February 23, 2018
connectivity link towards a specific node is up or down. Based on
this information, the OPPFace decides whether to simply queue a
packet (when OPPFace is down) or flush the queue (when OPPFace is
up).
In order to achieve this, whenever the node joins a Wi-Fi Direct
Group, it gets registered in the Group so that other nodes can send
packets to it. After this setup, all service changes detected within
the Group (connectivity up or down) are reflected into the Face Table
(cf. Figure 2). Upon disconnection from the Group, the node is
unregistered and the node returns to a state of waiting for a Group
to be joined.
3.3. LSA Exchange
DABBER performs the dissemination of LSAs based on a process able of
synchronizing 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 ChronoSync as synchronization
mechanism. Chronosync allows DABBER to define a collection of named
data in a local repo as a slice. LSA information are synchronized
among neighbor nodes, since Chronosync 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, ChronoSync notifies DABBER
to retrieve the corresponding LSA in order to update the local LSDB.
DABBER can also request new LSAs from Chronosync when resources (e.g.
CPU cycles) are available.
Figure 5 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, ChronoSync, 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 Chronosync 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 Chronosync 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
Mendes, et al. Expires August 27, 2018 [Page 20]
Internet-Draft dabber February 23, 2018
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.
Chronosync on nodes A and B compute a new hash for updated the set
and send a new Sync Interest with the new hash (step 7).
Node A Node B
+----------------------------+ +----------------------------+
| +-------------+ | |+-------------+ |
| DABBER | Chronosync | | || Chronosync | DABBER |
| +-------------+ | |+-------------+ |
+----------------------------+ +----------------------------+
| | Sync Interest (1) | |
| |------------------->| |
| |<-------------------| |
| New LSA (2)| | |
|----------> | | |
| | Sync Reply (3) | |
| |------------------->| |
| | | Notify (4) |
| | |------------->|
| | LSA Interest (5) | |
|<-----------|--------------------|--------------|
| | LSA Data (6) | |
|------------|--------------------|------------->|
| | | |
| | Sync Interest (7) | |
| |------------------->| |
| |<-------------------| |
Figure 5: LSA exchange process.
When more than one LSA needs to be synchronized, the issued LSA
Interest packet will contain information about as many LSAs as
allowed by the Link maximum transmission unit. In the same sense one
LSA Data packet may include also be used to transport information
about more than one LSA.
3.4. Loop Avoidance
In addition to the loop avoidance mechanism of NDN, DABBER considers
a loop removal mechanism, which takes care of disabling the Face
responsible for the looping once it is detected.
3.5. Failure and Recovery
As described in section 3.2, DABBER relies on a connectivity manager
that is able to react to changes in the peers available within the
Mendes, et al. Expires August 27, 2018 [Page 21]
Internet-Draft dabber February 23, 2018
wireless scanning range of the current node.
Upon detection of a Wi-Fi Direct Group, the connectivity manager
automatically joins that Group, if it is not part of one.
Upon the reception of notifications regarding changes in the peers
detected in the neighborhood, the Connectivity Manager updates its
internal peer list.
3.6. Interface towards a Contextual Agent
The interface between DABBER and CM provides the former with periodic
information concerning a node's centrality (C) and a node's
availability (A), as well as with a similarity weight (I) between
peers (link relevancy).
This interface integrates premises to perform specific requests to
get the computed values C, U for a list of peers provided by DABBER.
The peers are identified by hashed MACs.
The interface integrates also a premise to provide a similarity
weight (I) between two peers passed by DABBER to the CM. For
instance, if DABBER requests similarity between node A (sender) and
node B (potential successor), then the CM computes similarity for
both nodes based on a specific period of time. Such analysis can
assist in a better selection of peers for data transmission, for
instance.
4. Interoperability
As mentioned in section 1.2 DABBER is being developed to allow the
deployment of wireless NDN networks where nodes and links can be
intermittently available. In this section we analyze the
interoperability of DABBER in two scenarios: the NDN wireless network
is at the fringes of a wired NDN core; the NDN wireless network can
interconnect topologically separated NDN networks or hosts, via a
DTN.
4.1. Interoperability with NDN operation over DTNs
In this sub-section, we review the deployment of DABBER over existing
DTNs. We only consider deployment scenarios where NDN is deployed as
an overlay over a DTN. In this case, the existing DTN infrastructure
and implementation are leveraged to extend NDN operation in
challenged networks. We consider scenarios such as data mulling,
services to remote locations, and interconnecting different NDN hosts
(fixed or mobile)[23].
Mendes, et al. Expires August 27, 2018 [Page 22]
Internet-Draft dabber February 23, 2018
In such challenged network topologies, OPPFaces may not be able to
cope well with long delays or disruption due to frequent
disconnections and node mobility, severely hampering network
operations. A DTN face integrated into NDN-OPP provides the latter
with a robust communications platform supporting communications in
these conditions, by providing the option to propagate Interests to,
and return Data from, remote NDN hosts or networks. These are assumed
to typically reside in access points and wireless edge routers, or
mobile devices and have a corresponding DTN face implementation.
DABBER will employ the DTN face, either in a hop-by-hop or a multi-
hop fashion, when it senses, through the connectivity manager, that
the OPPFaces do not provide a high probability of successful data
delivery (e.g. Time-to-completion is too high). As DTN faces operate
as regular faces, cost computation and face ranking/selection is
performed using the procedure described in section 2.4.
4.2. Interoperability with NDN operation in wired networks
In this sub-section we analyze the interoperability of DABBER with
two potential configurations of an NDN access network based on: a
routing protocol able of disseminating name prefix information, such
as NLSR; a broadcast based forwarding approach.
4.2.1. Interoperability with NLSR
The LSA dissemination mechanism described in section 3.3 is used to
ensure interoperability with NLSR. Such mechanism ensures the
interoperability between a DABBER node and a NLSR edge router, since
the specification used by DABBER follows the same message structure
and sequence of the mechanism used by NLSR [19][20].
However, when DABBER is executing the LSA dissemination procedure
over a Wi-Fi face (towards a NLSR edge router), the following updates
to the procedure described in section 3.3 need to be done in order to
account for the changes between DABBER and NLSR as stated in section
2.3:
o When DABBER gets an Interest packet related to a Prefix LSA,
DABBER excludes the information about the cost of each name
prefix.
o When DABBER gets a Data packet related to a Prefix LSA, it had
to each name prefix a standard cost of 86400 (corresponding to a
validity of 1 day).
o DABBER will ignore all notifications that Chronosync will send
it related to Adjacency LSAs.
Mendes, et al. Expires August 27, 2018 [Page 23]
Internet-Draft dabber February 23, 2018
4.2.2. Interoperability with broadcast based forwarding
Broadcast-based forwarding is a common mechanism in the design of
some networks, such as switched Ethernet and mobile ad-hoc networks.
In NDN networks this means that NFD broadcasts Interest packets that
do not match an entry in the FIB, inserting then into the FIB the
forwarding path learned through observation of Data return paths. The
main challenge in broadcast based forwarding schemes is the prefix
granularity problem: determine the name prefix of an inserted FIB
entry from the Data name. Several solutions exist [16], including the
announcements of name prefixes, as done by DABBER.
In any case DABBER interoperability with such NDN networks relies on
the following considerations:
o When in contact with a wireless edge router, DABBER always
forward Interest packet towards the Wi-Fi Face, even when the
Interest packet does not match an entry in the FIB. o Interest
packets received from a wireless edge router will not be
broadcast. Interest packets will be forwarded if they match an
entry in the FIB, or dropped otherwise.
5. Security Considerations
As happens with NLSR, DABBER routing messages are carried in NDN data
packets containing a signature. Hence, a DABBER node 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 propose, DABBER makes use of a hierarchical
trust model for routing, as used by NLSR within a single domain, to
verify the keys used to sign the routing messages.
Following the name structure described in section 2.2, DABBER models
the trust management as a five-level hierarch, as in NLSR, although
reflecting a different administrative structure: <network> represents
the authority responsible by the international transit network
allowing roaming services; <operator> represents the operator
providing the mobile service; <home> represents the network site of
the mobile operator where the node is registered; <node> represents
the mobile equipment. Each node can create a DABBER process that
produces LSAs.
With this hierarchical trust model, one can establish a chain of keys
to authenticate LSAs. Specifically, a LSA must be signed by a valid
DABBER process, which runs on the same node where the LSA was
originated. To become a valid DABBER process, the process key must be
signed by the corresponding node key, which in turn should be signed
by the registered home network of the network operator. Each home
Mendes, et al. Expires August 27, 2018 [Page 24]
Internet-Draft dabber February 23, 2018
network key must be signed by the operator key, which must be
certified by the network authority using the network key, which is
called trust anchor in NDN.
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 NDN Interest/Data exchange
process to gathers keys from all its direct neighbors. Upon the
reception of an Interest of the type /<network>/broadcast/KEYS each
neighbor looks up the requested keys in their local key storage and
return 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.
6. Implementation and Deployment Experience
Currently DABBER is being implemented as the routing scheme for the
NDN framework for Opportunistic Networks (NDN-OPP) [3]. NDN-OPP is an
extension of the NDN Android implementation, aiming to support NDN
communication in wireless networks by exploiting direct communication
between wireless nodes, as well as intermittent Wi-Fi connectivity to
the Internet (NDN global test-bed).
NDN-OPP has been demonstrated in ACM ICN 2017 in Berlin [4], as well
as in the NDNComm in Memphis [5]. NDN-OPP code is available in
GitHub: https://github.com/COPELABS-SITI/ndn-opp
7. Acknowledgments
The research leading to these results has 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).
We thank all contributors, as well as the valuable comments offered
by Lixia Zhang (UCLA) and Lan Wang (University of Memphis) to improve
this draft.
8. References
8.1 Normative References
[1] Lixia Zhang, Deborah Estrin, Jeffrey Burke, Van Jacobson, James
D. Thornton, Diana K. Smetters, Beichuan Zhang, Gene Tsudik, KC
Claffy, Dmitri Krioukov, Dan Massey, Christos Papadopoulos,
Mendes, et al. Expires August 27, 2018 [Page 25]
Internet-Draft dabber February 23, 2018
Tarek Abdelzaher, Lan Wang, Patrick Crowley, Edmund Yeh "Named
Data Networking", NDN Technical Report NDN-001, October 2010.
[2] A. Afanasyev, J. Shi, B. Zhang, L. Zhang, I. Moiseenko, Y. Yu, W.
Shang, Y. Li, S. Mastorakis, Y. Huang, J. P. Abraham, E.
Newberry, S. DiBenedetto, C. Fan, C. Papadopoulos, D. Pesavento,
G. Grassi, G. Pau, H. Zhang, T. Song, H. Yuan, H. B. Abraham, P.
Crowley, S. O. Amin, V. Lehman, M. Chowdhury, and L. Wang, "NFD
Developer's Guide", NDN, Technical Report NDN-0021, February
2018.
[3] Miguel Tavares, Paulo Mendes, "NDN-Opp: Named-Data Networking in
Opportunistic Networks", Technical Report COPE-SITI-TR-18-01,
January 2018.
8.2 Informative References
[4] Seweryn Dynerowicz, Paulo Mendes, "Named-Data Networking in
Opportunistic Networks", in ACM ICN, Berlin, Germany, September
2017.
[5] Seweryn Dynerowicz, Omar Aponte, Paulo Mendes, "NDN Operation in
Opportunistic Wireless Networks", in NDNcomm, Memphis, USA,
March 2017
[6] Christos-Alexandros Sarros, Sotiris Diamantopoulos, Sergi Rene,
Ioannis Psaras, Adisorn Lertsinsrubtavee, Carlos Molina-Jimenez,
Paulo Mendes, Rute Sofia, Arjuna Sathiaseelan, George Pavlou,
Jon Crowcroft, Vassilis Tsaoussidis, "Connecting the Edges: A
Universal, Mobile centric and Opportunistic Communications
Architecture", IEEE Communication Magazine, February 2018
[7] Rute C. Sofia, Igor Santos, Jose Soares, Sotiris Diamantopoulos,
Christos-Alexandro Sarros, Dimitris Vardalis, Vassilis
Tsaoussidis, Angela; d'Angelo, "UMOBILE D4.5 - Report on Data
Collection and Inference Models" Technical Report, September
2018.
[8] NDN Project, "NFD Developer's Guide", Technical Report NDN-0021,
October 2016.
[9] Zhenkai Zhu and Alexander Afanasyev, "Let's ChronoSync:
Decentralized Dataset State Synchronization in Named Data
Networking", in Proc. IEEE ICNP, Goettingen, Germany, Oct 2013
[10] Minsheng Zhang, Vince Lehman, and Lan Wang, "PartialSync:
Efficient Synchronization of a Partial Namespace in NDN", NDN
Mendes, et al. Expires August 27, 2018 [Page 26]
Internet-Draft dabber February 23, 2018
Technical Report NDN-0039, June 2016.
[11] Klaus Schneider, Beichuan Zhang, "How to Establish Loop-Free
Multipath Routes in Named Data Networking", NDN Technical Report
NDN-0044, April 2017.
[12] A. Lindgren, A. Doria, E. Davies, S. Grasic, "Probabilistic
Routing Protocol for Intermittently Connected Networks, IETF RFC
6693, Aug 2012.
[13] Waldir Moreira, Paulo Mendes, Susana Sargento, "Social-aware
Opportunistic Routing Protocol based on User's Interactions and
Interests", in Proc. of AdhocNets, Barcelona, Spain, October
2013
[14] Waldir Moreira, Paulo Mendes, Susana Sargento, "Opportunistic
Routing based on daily routines", in Proc. of IEEE WoWMoM
workshop on autonomic and opportunistic communications, San
Francisco, USA, June, 2012
[15] P. Hui, J. Crowcroft, and E. Yoneki, "Bubble rap: social-based
forwarding in delay tolerant networks," Mobile Computing, IEEE
Transactions on, vol. 10, pp. 1576-1589, November, 2011.
[16] Junxiao Shi, Eric Newberry, Beichuan Zhang, "On Broadcast-based
Self-Learning in Named Data Networking", in Proc. Of IFIP
Networking, Stockholm, Sweden, June 2017
[17] The H2020 UMOBILE project. Grant number 645124, 2015-2018.
Available via http://www.umobile-project.eu/
[18] Waldir Moreira, Paulo Mendes and Eduardo Cerqueira,
"Opportunistic Routing based on Users Daily Life Routine", IETF
Internet Draft (draft-moreira-dlife-04), May 2014
[19] Vince Lehman, A K M Mahmudul Hoque, Yingdi Yu, Lan Wang,
Beichuan Zhang, Lixia Zhang "A Secure Link State Routing
Protocol for NDN", NDN Technical Report NDN-0037, January 2016.
[20] Vince Lehman, Muktadir Chowdhury, Nicholas Gordon, Ashlesh
Gawande, "NLSR Developer's Guide", November 2017.
[21] V. Cerf, S. Burleigh, A. Hooke, L. Torgerson, R. Durst, K.
Scott, K. Fall, H. Weiss, "Delay-Tolerant Networking
Architecture", IETF RFC 4838, April 2007
[22] K. Scott, S. Burleigh, "Bundle Protocol Specification", IETF RFC
5050, November 2007
Mendes, et al. Expires August 27, 2018 [Page 27]
Internet-Draft dabber February 23, 2018
[23] C.A. Sarros, A. Lertsinsrubtavee, C. Molina-Jimenez, K.
Prasopoulos, S. Diamantopoulos, D. Vardalis, A. Sathiaseelan,
"ICN-based Edge Service Deployment in Challenged Networks"
(demo), in Proceedings of the 4th ACM Conference on Information-
Centric Networking, Berlin, Germany, September 26-28, 2017
Authors' Addresses
Paulo Mendes
COPELABS, Universidade Lusofona
Campo Grande, 376
1749-024 Lisboa
Portugal
Email: paulo.mendes@ulusofona.pt
URI: http://www.paulomilheiromendes.com
Rute Sofia
Senception
Av. da Republica 6, 7 Esq
1050-191 Lisboa
Portugal
Email: rute.sofia@senception.com
URI: http://www.rutesofia.com
Vassilis Tsaoussidis
Democritus University of Thrace
University Campus
69100 Komotini
Greece
Email: vtsaousi@ee.duth.gr
Sotiris Diamantopoulos
Democritus University of Thrace
University Campus
69100 Komotini
Greece
Email: diamantopoulos.sotiris@gmail.com
Christos-Alexandros Sarros
Democritus University of Thrace
University Campus
69100 Komotini
Greece
csarros@ee.duth.gr
Mendes, et al. Expires August 27, 2018 [Page 28]