ICN Research Group Paulo Mendes Internet-Draft Airbus Intended Status: Experimental Rute Sofia Expires: September 1, 2019 COPELABS,University Lusofona Vassilis Tsaoussidis Sotiris Diamantopoulos Christos-Alexandros Sarros Democritus University of Thrace Carlos Borrego Joan Borrel Autonomous University of Barcelona February 28, 2019 Information-centric Routing for Opportunistic Wireless Networks draft-mendes-icnrg-dabber-02 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/. Mendes, et al. Expires September 1, 2019 [Page 1]
Internet-Draft dabber February 28, 2019 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 February 28, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . . . 9 2. DABBER Architecture . . . . . . . . . . . . . . . . . . . . . . 9 2.1. Assumptions and Requirements . . . . . . . . . . . . . . . 10 2.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3. LSA Dissemination . . . . . . . . . . . . . . . . . . . . . 12 2.4. Multiple path Computation . . . . . . . . . . . . . . . . . 14 2.4.1. Name Prefix Validity Computation . . . . . . . . . . . 14 2.4.2. Update of DABBER internal information . . . . . . . . . 16 2.4.2. Update of RIB of the local NFD . . . . . . . . . . . . 17 2.5. Packet Forwarding . . . . . . . . . . . . . . . . . . . . . 17 2.6. Loop Prevention . . . . . . . . . . . . . . . . . . . . . . 18 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 18 3.1. Overall Operation Example . . . . . . . . . . . . . . . . . 19 3.2. Peer Discovery and Face Setup . . . . . . . . . . . . . . . 20 3.3. Peer Communication Modes . . . . . . . . . . . . . . . . . 21 3.4. Multi-homing Wireless Communication . . . . . . . . . . . . 22 3.5. LSA Exchange . . . . . . . . . . . . . . . . . . . . . . . 23 3.6. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . 24 3.7. Failure and Recovery . . . . . . . . . . . . . . . . . . . 25 3.8. Interface towards a Contextual Agent . . . . . . . . . . . 25 Mendes, et al. Expires September 1, 2019 [Page 2]
Internet-Draft dabber February 28, 2019 3.9. Adjustment to data source mobility . . . . . . . . . . . . 25 4. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 27 4.1. Interoperability with NDN operation over DTNs . . . . . . . 27 4.2. Interoperability with NDN operation in wired networks . . . 27 4.2.1. Interoperability with NLSR . . . . . . . . . . . . . . 27 4.2.2. Interoperability with broadcast based forwarding . . . 28 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 28 6. Implementation and Deployment Experience . . . . . . . . . . . 29 6.1 Improvement of Network Service Discovery . . . . . . . . . 29 6.1.1. Peer Registration Service . . . . . . . . . . . . . . . 30 6.1.2. Peer Announcement Service . . . . . . . . . . . . . . . 30 6.1.3. Leader Service . . . . . . . . . . . . . . . . . . . . 31 6.1.4. Disconnect Detector Service . . . . . . . . . . . . . . 31 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 32 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 8.1 Normative References . . . . . . . . . . . . . . . . . . . 32 8.2 Informative References . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Mendes, et al. Expires September 1, 2019 [Page 3]
Internet-Draft dabber February 28, 2019 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 [24]. 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 consider 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. Although DABBER specification allows an easier integration with NDN Mendes, et al. Expires September 1, 2019 [Page 4]
Internet-Draft dabber February 28, 2019 access networks based on NSLR (e.g. the messaging systems based on the synchronization of LSA is the same), its operation is completely independent of NSLR. This means that DABBER can be used in any isolated wireless opportunistic network, or by any wireless node that frequently attaches to fix NDN networks (e.g. by using a Wi-Fi link), which do not have NLSR as their routing protocol. DABBER is intended as complementing existing forwarding protocols for 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 three types of information: i) Node Mendes, et al. Expires September 1, 2019 [Page 5]
Internet-Draft dabber February 28, 2019 availability (metric A); ii) Node centrality (metric C); iii) Node similarity (metric S). Node Availability (A) gives an estimate of the node availability based on the usage of internal resources over time and space, such as the time spent per application category (e.g. per day), as well as the usage of physical resources (battery status; CPU status, etc). Node Centrality (C) provides awareness about the node's affinity network neighborhood context. For instance, the more visited networks a node has over a period of time, the more central a node is (increases the possibility for data transmission); The higher the number of connections a node has over a period of time, the more central a node is; The higher the node degree of node over a period of time, the higher is its centrality; The lower the distances traversed by the node are, the higher is its centrality. Node similarity (S) provides awareness about a node's similarity towards neighbor nodes, based on the assumption that the more similar nodes are, the higher the probability of more robust data exchange between those nodes. This metric relies on a cosine similarity to provide a link cost between peer nodes. In the case of DABBER, similarity is computed based on the number of encounters between peer nodes and the average duration of such encounters. 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, C and S) 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, such as in the case of emergency situations [25]. 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 Mendes, et al. Expires September 1, 2019 [Page 6]
Internet-Draft dabber February 28, 2019 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: 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. Mendes, et al. Expires September 1, 2019 [Page 7]
Internet-Draft dabber February 28, 2019 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. 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 Mendes, et al. Expires September 1, 2019 [Page 8]
Internet-Draft dabber February 28, 2019 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 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). 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. Mendes, et al. Expires September 1, 2019 [Page 9]
Internet-Draft dabber February 28, 2019 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 | 2,1,4 | | N | 4 | 10 | | | | | N | 1 | 5 | +---------------------- + +----------------------------+ Figure 1: RIB and FIB Management, node A. 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. 2.1. Assumptions and Requirements Mendes, et al. Expires September 1, 2019 [Page 10]
Internet-Draft dabber February 28, 2019 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 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 Mendes, et al. Expires September 1, 2019 [Page 11]
Internet-Draft dabber February 28, 2019 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. With DABBER, we assume that DABBER is installed in mobile devices (e.g. smartphones), which have a contract with a mobile operator. In a 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 operator has more than one operational site. This naming scheme still makes sense even if DABBER is only used to exchange traffic over 802.11, wifi direct or 802.11 adhoc links, and never over a cellular interface. 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 DABBER runs on top of NDN, making use of Interest/Data packets to Mendes, et al. Expires September 1, 2019 [Page 12]
Internet-Draft dabber February 28, 2019 exchange LSAs. This means that while IP-based routing protocols push updates to other routers, DABBER nodes need to pull the updates. DABBER can use any underlay communication channels (e.g., TCP/UDP tunnels, Link layer TXT records) to exchange LSA information. 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. 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. Mendes, et al. Expires September 1, 2019 [Page 13]
Internet-Draft dabber February 28, 2019 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 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 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 Name Prefix LSA (or a new version of an existing Name Prefix LSA) in its LSDB (c.f. section 2.3). The sequence of operations, as described in the following sub-sections are: Computes a new value for the validity of a new Name Prefix in the LSDB; Updates DABBER internal routing table; Updates the LSDB with the data reachability information (validity) of the current node towards the new Name Prefix; Updates the RIB based on the DABBER internal routing table, following a Downwards Path Criterion (FIB is updated by NFD based on the RIB content). Periodically DABBER will update the validity values of all Name Prefixes in its internal routing table, performing the consequent updates of the local LSDB and RIB, and needed. 2.4.1. Name Prefix Validity 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 validity for each name prefix in such Prefix LSA. 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 "relation" 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 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 Mendes, et al. Expires September 1, 2019 [Page 14]
Internet-Draft dabber February 28, 2019 opportunistic environments, 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. In the current implementation of DABBER, 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 (and 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 the contextual manager ( C >= 0), aiming to select neighbors with high probability of successfully forwarding Interest packets. 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 of 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 3: Neighbor table. The values C, A and S provided by the contextual manager are stored Mendes, et al. Expires September 1, 2019 [Page 15]
Internet-Draft dabber February 28, 2019 in a Neighbor Table as shown in figure 3. Since an OPPFace is created by NDN-OPP (c.f. section 1.3), the table is 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) 2.4.2. Update of DABBER internal information After the computation of the validity of the Name Prefix taking into account the relation of the current node with the neighbor announcing it (c.f. section 2.4.1), DABBER updates its internal routing table and its LSDB. The information on the routing table will be used to updated the RIB of the local NFD and the information of the LSDB will be announced to all the neighbor by Chronosync. To update the Internal routing table, DABBER adds an entry Na for the Name Prefix with a validity V''. The routing table is then ordered by name prefix in decreased order of validity. To update its local LSDB updated with validity of current node towards the Name Prefix, DABBER can use two methods: o Maximal method: Name Prefix entry on current node LSA updated with max (V'', current value on LSA). o Average method: Name Prefix entry on current node LSA updated with max ( average (cost of Name Prefix entries on local routing Mendes, et al. Expires September 1, 2019 [Page 16]
Internet-Draft dabber February 28, 2019 table), current value on LSA). 2.4.2. Update of RIB of the local NFD After computing the new value of the validity V'' 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 Name Prefix LSA was received and the new cost of such Name prefix. The cost (k) of the Name Prefix is computed based on its validity as k = trunc (100/V''). 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 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 is include all neighbors with cost = trunc (100/V''), such that 1/V'' - Avr (Costs in RIB for N) > X (predefined value). 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 is include 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 packet from looping back, there is the need to add a tiebreaker, which assures that traffic only crosses one direction of equal- cost links. This is, include X neighbors with cost = trunc (100/V''), such that cost is the lowest value of 1/V'' or cost <=1/ V. 2.5. Packet Forwarding Packets are forwarded based on the information that is stored in the FIB, which is updated by the NFD when there is an update of the RIB (multicast forwarding strategy used). Mendes, et al. Expires September 1, 2019 [Page 17]
Internet-Draft dabber February 28, 2019 In order to support the operation of NDN in intermittently connected networks, a new type of Face was added to NFD, Opportunistic Faces (OPPFaces), which allows forwarded packets to be queued, being dispatched as soon as a wireless channel is established. The new concept of Opportunistic Faces aims to provide support for intermittent communications without requiring any other changes to NFD itself. This makes co-existence of the opportunistic networks side-by-side with traditional communication schemes possible. The implementation of the OPPFaces depends upon the specific link layer protocols based on two basic policies: In the presence of a peer-to-peer link layer protocol, such as Wi-Fi Direct or D2D LTE, one OPPFace should be created for each wireless neighbor; In the present of broadcast link layer protocols, such as Ad-Hoc Wi-Fi, a unique OPPFace should be created. The state of an Opportunistic Face reflects the fact that the corresponding neighbor device is currently reachable in the Wi-Fi Direct range. Based on this information, the Opportunistic Face decides whether to simply queue the packet or attempt a transmission over the associated Opportunistic Channel. Based on the feedback provided by the wireless channel, the Face can decide whether to remove the packet from the queue once it has been passed on to its intended peer. Furthermore, the Opportunistic Face integrates a mechanism to automatically flush the queue whenever the Face is brought up upon detection of the corresponding peer being available in the same Wi-Fi Direct Group. 2.6. 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 Mendes, et al. Expires September 1, 2019 [Page 18]
Internet-Draft dabber February 28, 2019 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 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 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 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 process described in 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 Update its LSDB with the Prefix LSAs received from node A and node B. Mendes, et al. Expires September 1, 2019 [Page 19]
Internet-Draft dabber February 28, 2019 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 node C stores 2 new entries for prefix /NDN/video/Lisbon/ in its internal routing table related to face2 with a validity 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 (c.f. section 2.4.2). 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. Based on the status of the FIB (updated based on the status of the RIB) 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 provided in this sub-section 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 Mendes, et al. Expires September 1, 2019 [Page 20]
Internet-Draft dabber February 28, 2019 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 that 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 connectivity link towards a specific node is up or down. Based on this information, the OPPFace decides whether to simply queue packets (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 Neighbor Table (c.f. Figure 3). 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. Peer Communication Modes This section describes the two communication methods implemented to allow for direct communication between wireless neighbors over Wi-Fi Direct: connection-oriented and connectionless. The connection-oriented solution allows peers to exchange packets by means of a reliable TCP connection established over the Wi-Fi direct group owner. This type of communication system is used mostly for large packets that may require reliable communication. The connection-oriented solution requires the formation of a Wi-Fi direct group by the connectivity manager. Once a device joins to the group, Mendes, et al. Expires September 1, 2019 [Page 21]
Internet-Draft dabber February 28, 2019 it will receive a list containing information related to each connected device. Since we are working with opportunistic networks, it is common that some devices could join or leave the group frequently. In order to deal with it, the group owner is also responsible to keep the list of connected devices updated. The connection-less communication method allows peers to exchange packets directly without the establishment of any Wi-Fi direct group, by exploiting the TXT records available during the Wi-Fi Direct service discovery phase. 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. To use this methodology, each device has to listen to all announced UUID related with it. Every time that a device needs to send a packet, it serializes the packet and starts announcing it, during the service discovery exchange, over TXT Record with the UUID of the destination. Android versions above 5.1 allow the transfer of up to 900 bytes. In order to implement a reliable connection-less solution, the Connectivity Manager maintains a TXT Record for each intended recipient of packets, which contains data packets and an acknowledgement list. Since the sequence and order in which devices probe and respond to one another is not controlled, a device might perform the acknowledgement of a given packet received from a remote peer, but might receive the packet again in the next TXT Record in the event the remote peer does not successfully probes the current device to get the pending acknowledgements. The decision of using a connection-oriented or connection-less communication is based on the following reasoning: o Hypothesis 1: Packets are exchanged between two wireless peers over a reliable TCP socket is such socket already exists; o Hypothesis 2: If a TCP connection does not exist, decision is take based on packet size. The connection-less mechanism is used for fast dispatching of small packets (limited to the size if the TXT record, which depends upon the Android version; Bigger packets will require the establishment of a reliable TCP connection over the Wi-Fi direct group owner. 3.4. Multi-homing Wireless Communication Although DABBER is being specified for the operation of NDN opportunistic wireless networks, wireless devices can exploit the present of Wi-Fi infrastructure connections made available by a nearby Wi-Fi Access Point. Mendes, et al. Expires September 1, 2019 [Page 22]
Internet-Draft dabber February 28, 2019 For this propose, beside using the new OPPFaces , DABBER also makes use of the Wi-Fi Face previously implemented in NFD. The Wi-Fi face may provide higher communication resilience and lower delays, as well as the possibility for wireless devices to exchange data with standard NDN devices deployed in a faraway location. Currently DABBER allows packets to be forwarded to a subset of available faces (OPPFaces, and Wi-Fi Faces). A more static alternative can be to avoid replicating Interest packets among wireless peers devices when a Wi-Fi network is available. It is expected that NDN-aware Access Points will be able to provide wireless devices with the IP address of the local NDN router within wireless beacons. In the current version this information is made available during the configuration phase. By default, the system is configured to connect to the NDN router deployed in COPELABS, but another NDN router may be selected. 3.5. 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 Mendes, et al. Expires September 1, 2019 [Page 23]
Internet-Draft dabber February 28, 2019 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 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.6. Loop Avoidance In addition to the loop avoidance mechanism of NDN, DABBER considers a loop removal mechanism, which takes care of disabling the Face Mendes, et al. Expires September 1, 2019 [Page 24]
Internet-Draft dabber February 28, 2019 responsible for the looping once it is detected. 3.7. 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 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.8. 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 (S) between peers (link relevancy). This interface integrates premises to perform specific requests to get the computed values C and A 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 (S) 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. 3.9. Adjustment to data source 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 source mobility. Supporting data source 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. This sub-section described a new feature of DABBER which follows a new reactive approach to face the challenges of the data source mobility and consistent forwarding in Mobile ICNs. To this end, DABBER is using the efficient dissemination method for Opportunistic Mendes, et al. Expires September 1, 2019 [Page 25]
Internet-Draft dabber February 28, 2019 Networks [26] to efficiently discover data sources by replicating Interest messages in an efficient way that avoids network flooding. With this new feature the prospective forwarders for a given Interest message (which are denoted as discoverers) 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 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. A combination of these three criteria defines a reward function (discoverer suitability) of an Optimal Stopping (OS) problem. If a node finds a new node with a certain value for the discoverer suitability it is difficult to know whether this value is a good one when compared with what a node could find in future contacts. This decision is not trivial: if a node chooses early-contacted discoverer candidates, good results are not guaranteed because selected discoverers could have a low discoverer suitability metric. On the other end of the spectrum, selecting late-contacted discoverer candidates does not guarantee either good discoverer nodes since it is likely that good candidates with high discovery suitability values would be skipped. DABBER is so extended with the ability to perform an OS-based strategy that allows nodes to select the most suitable node among all of the contacted ones to forward the Interest message. 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. Mendes, et al. Expires September 1, 2019 [Page 26]
Internet-Draft dabber February 28, 2019 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]. 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, multiple path computation 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 Mendes, et al. Expires September 1, 2019 [Page 27]
Internet-Draft dabber February 28, 2019 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 DABBER will ignore all notifications that Chronosync will send related to Adjacency LSAs. 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 Mendes, et al. Expires September 1, 2019 [Page 28]
Internet-Draft dabber February 28, 2019 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 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 DABBER is 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 6.1 Improvement of Network Service Discovery This section provides information about a set of improvements that were included in the operation of Wi-Fi Direct during the development of DABBER. Such improvements are related to the operation of the Network Service Discovery mechanism. Mendes, et al. Expires September 1, 2019 [Page 29]
Internet-Draft dabber February 28, 2019 NSD gives access to services that other devices provide on a local network. NSD implements the DNS-based Service Discovery (DNS-SD) mechanism, which allows services to be requested by specifying their type and the name of a device instance that provides the desired service. DNS-SD is supported both on Android and on other mobile platforms. NSD was also implemented on NDN-OPP, were it is responsible for detecting other devices that are using NDN-OPP via a Wi-Fi Direct network. After a set of tests, the DNS-SD library revealed some flaws: it was noticed that in some old versions of Android, sometimes devices could not get registered. This means that such devices could not be discovered. Moreover, registration and discovering processes revealed to be too slow. For that reason, NSD service should be running all the time, not only to detect new devices but also device disconnections. Once NDN-OPP deals with opportunistic communications, it should be capable of performing such processes quickly. Hence, in order to solve these issues, we developed a NSD similar implementation, based on the following guidelines: since a device joins a Wi-Fi Direct network, that device already knows the group owner's IP address. Then, we use this information to build a solution based on sockets, which has higher performance. Our solution implementation has four main components. All of them are explained in the next sub-sections. 6.1.1. Peer Registration Service The registration service allows devices in a Wi-Fi group to discover NDN-OPP peers by sharing information via the group owner. When a Wi- Fi Direct connection is performed successfully, the device that performed this connection only knows the group owner's IP address. In order to be discovered, this device must advertise that it already joined the network. In order to do that, the device should make its IP address and UUID available in the group. These data is encapsulated in an NsdInfo object that is serialized and then sent over a socket to the group owner: the register service remains sending this object in configured time intervals. If the Wi-Fi Direct connection goes down, the mechanism that sends these objects stops. Then, eventually the Disconnect Detector Service classifies this device as a disconnected device. 6.1.2. Peer Announcement Service Mendes, et al. Expires September 1, 2019 [Page 30]
Internet-Draft dabber February 28, 2019 This component is responsible to guarantee communications among all connected peers. In order to do that, the Discovery Service uses a socket system: when a device tries to register itself, it starts by sending, to the group owner, a NSD packet containing its personal information. The Announcement Service, which runs on the group owner, receives this packet through a socket and will notify all registered listeners. 6.1.3. Leader Service This service is instantiated only by the group owner. The group owner is responsible to keep the list of connected devices consistent and updated. In order to do that, when a device joins a network and registers itself, the group owner will be notified. The Leader Service will receive the UUID and IP address of the registered device and then, if that device is not already in the list, the Leader Service will add it, and also notify all connected devices in order to keep them updated. The periodical registration requests are sent by the Register Service in order to inform the Leader Service that this device is still alive. Also a copy of these requests is sent to Disconnect Detector Service that decides when a device is considered disconnected. When a device is considered disconnected, the Disconnect Detector Service notifies the Leader Service saying that this device is considered disconnected. At that moment, the Leader Service removes that device from the list of connected devices, and notifies all connected devices. 6.1.4. Disconnect Detector Service Since the group owner does not know when a device leaves the network, we developed an additional component to deal with it. The Disconnect Detector Service is responsible to define when a device is considered disconnected from the network. The Disconnect Detector Service runs periodically, incrementing a counter per each device. When this counter achieves a pre-configured number, that device is considered disconnected; The Disconnect Detector Service notifies the Leader Service that such device is disconnected. This notification is performed through onPeerLost method. The reset of this counter is performed every time the Leader Service receives a register request from that device. Mendes, et al. Expires September 1, 2019 [Page 31]
Internet-Draft dabber February 28, 2019 7. 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). 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, 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, Mendes, et al. Expires September 1, 2019 [Page 32]
Internet-Draft dabber February 28, 2019 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 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. Mendes, et al. Expires September 1, 2019 [Page 33]
Internet-Draft dabber February 28, 2019 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 [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 [24] Paulo Mendes, Rute Sofia, Vassilis Tsaoussidis, Sotiris Diamantopoulos, Christos-Alexandros Sarros, "Information-centric Routing for Opportunistic Wireless Networks", in ACM ICN, Boston, USA, September 2018. [25] Miguel Tavares, Omar Aponte, Paulo Mendes, "Named-data Emergency Network Services", in ACM MOBISYS, Munich, Germany, June 2018. [26] Borrego, Carlos, Joan Borrell, and Sergi Robles. "Efficient broadcast in opportunistic networks using optimal stopping theory." Ad Hoc Networks 88 (2019): 5-17 Authors' Addresses Paulo Mendes Airbus Defence and Space GmbH Willy-Messerschmitt Strasse 1 82024 Taufkirchen Germany Email: paulo.mendes@airbus.com Mendes, et al. Expires September 1, 2019 [Page 34]
Internet-Draft dabber February 28, 2019 URI: http://www.paulomilheiromendes.com Rute Sofia COPELABS, University Lusofona Campo grande 376 1749-024 Lisboa Portugal Email: rute.sofia@ulusofona.pt 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 Carlos Borrego Department of Information and Communications Engineering Autonomous University of Barcelona 08193 Bellaterra Spain carlos.borrego@uab.cat Joan Borrell Department of Information and Communications Engineering Autonomous University of Barcelona 08193 Bellaterra Spain joan.borrell@uab.cat Mendes, et al. Expires September 1, 2019 [Page 35]