idnits 2.17.1 draft-mendes-icnrg-dabber-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 375 has weird spacing: '...etation only...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 28, 2019) is 1878 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: '6' is defined on line 1494, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1507, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group Paulo Mendes 3 Internet-Draft Airbus 4 Intended Status: Experimental Rute Sofia 5 Expires: September 1, 2019 COPELABS,University Lusofona 6 Vassilis Tsaoussidis 7 Sotiris Diamantopoulos 8 Christos-Alexandros Sarros 9 Democritus University of Thrace 10 Carlos Borrego 11 Joan Borrel 12 Autonomous University of Barcelona 13 February 28, 2019 15 Information-centric Routing for Opportunistic Wireless Networks 16 draft-mendes-icnrg-dabber-02 18 Abstract 20 This draft describes the Data reAchaBility BasEd Routing (DABBER) 21 protocol, which has been developed to extend the reached of Named 22 Data Networking based routing approaches to opportunistic wireless 23 networks. By "opportunistic wireless networks" it is meant multi-hop 24 wireless networks where finding an end-to-end path between any pair 25 of nodes at any moment in time may be a challenge. The goal is to 26 assist in better defining opportunities for the transmission of 27 Interest packets towards the most suitable data source, based on 28 metrics that provide information about: i) the availability of 29 different data sources; ii) the availability and centrality of 30 neighbor nodes; iii) the time lapse between forwarding Interest 31 packets and receiving the corresponding data packets. The document 32 presents an architectural overview of DABBER followed by 33 specification options related to the dissemination of name-prefix 34 information to support the computation of next hops, and the ranking 35 of forwarding options based on the best set of neighbors to ensure a 36 short time-to-completion. 38 Status of this Memo 40 This Internet-Draft is submitted to IETF in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on February 28, 2019. 55 Copyright and License Notice 57 Copyright (c) 2018 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. Contextual Aspects . . . . . . . . . . . . . . . . . . . . 5 74 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . 6 75 1.3. NFD Adjustment to Opportunistic Networks . . . . . . . . . 7 76 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 9 77 2. DABBER Architecture . . . . . . . . . . . . . . . . . . . . . . 9 78 2.1. Assumptions and Requirements . . . . . . . . . . . . . . . 10 79 2.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 2.3. LSA Dissemination . . . . . . . . . . . . . . . . . . . . . 12 81 2.4. Multiple path Computation . . . . . . . . . . . . . . . . . 14 82 2.4.1. Name Prefix Validity Computation . . . . . . . . . . . 14 83 2.4.2. Update of DABBER internal information . . . . . . . . . 16 84 2.4.2. Update of RIB of the local NFD . . . . . . . . . . . . 17 85 2.5. Packet Forwarding . . . . . . . . . . . . . . . . . . . . . 17 86 2.6. Loop Prevention . . . . . . . . . . . . . . . . . . . . . . 18 87 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 18 88 3.1. Overall Operation Example . . . . . . . . . . . . . . . . . 19 89 3.2. Peer Discovery and Face Setup . . . . . . . . . . . . . . . 20 90 3.3. Peer Communication Modes . . . . . . . . . . . . . . . . . 21 91 3.4. Multi-homing Wireless Communication . . . . . . . . . . . . 22 92 3.5. LSA Exchange . . . . . . . . . . . . . . . . . . . . . . . 23 93 3.6. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . 24 94 3.7. Failure and Recovery . . . . . . . . . . . . . . . . . . . 25 95 3.8. Interface towards a Contextual Agent . . . . . . . . . . . 25 96 3.9. Adjustment to data source mobility . . . . . . . . . . . . 25 97 4. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 27 98 4.1. Interoperability with NDN operation over DTNs . . . . . . . 27 99 4.2. Interoperability with NDN operation in wired networks . . . 27 100 4.2.1. Interoperability with NLSR . . . . . . . . . . . . . . 27 101 4.2.2. Interoperability with broadcast based forwarding . . . 28 102 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 28 103 6. Implementation and Deployment Experience . . . . . . . . . . . 29 104 6.1 Improvement of Network Service Discovery . . . . . . . . . 29 105 6.1.1. Peer Registration Service . . . . . . . . . . . . . . . 30 106 6.1.2. Peer Announcement Service . . . . . . . . . . . . . . . 30 107 6.1.3. Leader Service . . . . . . . . . . . . . . . . . . . . 31 108 6.1.4. Disconnect Detector Service . . . . . . . . . . . . . . 31 109 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 32 110 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 111 8.1 Normative References . . . . . . . . . . . . . . . . . . . 32 112 8.2 Informative References . . . . . . . . . . . . . . . . . . 32 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 115 1. Introduction 117 In a networking scenario where an increasing number of wireless 118 systems, such as end-user nodes and mobile edge nodes, are being 119 deployed, there are two networking paradigms that are highly 120 correlated to the efficiency of pervasive data sharing: Information- 121 Centric Networking (ICN), and opportunistic wireless networking. The 122 latter concerns the capability of exploiting any potential wireless 123 communication opportunity to exchange data in a multi-hop wireless 124 networks, where it is difficult to find an end-to-end path between 125 any pair of nodes at any moment in time. 127 Combining opportunistic networking with ICN principles is relevant to 128 efficiently extend the applicability of information-centric 129 networking to novel scenarios, such as affordable pervasive access; 130 low cost extension of access networks; edge computing; vehicular 131 networks. 133 This document describes the Data reAchaBility BasEd Routing (DABBER) 134 routing protocol for information-centric wireless opportunistic 135 networks [24]. These networking architectures are operationally 136 located on the Internet fringes (Customer Premises). In such areas, 137 networking experiences intermittent connectivity and variable 138 availability of nodes due to their movement and/or due to other 139 constrains, e.g., limited battery, storage, and processing. 141 DABBER has been therefore designed to be compatible with the routing 142 deployed within ICN access networks. Its main purpose is to assist in 143 extending the reach of multi-hop transmission to opportunistic 144 environments, in a seamless and fully interoperable way. 146 It is our understanding that routing in such wireless environments 147 needs to be done based on strategies that take into consideration, at 148 a network level, the context of wireless nodes, and not just the 149 history of contacts among wireless nodes. The goal is to assist in 150 better defining opportunities for the transmission of Interest 151 packets over time and space. Such opportunities can be better 152 addressed if routing metrics take into consideration, as common in 153 opportunistic environments, measures of centrality, as well as 154 measures of node and data availability. 156 Being NDN[1][2] a well established ICN framework, the first step 157 proposed by this draft is to consider the current de facto NDN 158 routing, Named-data Link State Routing protocol (NLSR)[19][20], in a 159 way that allows the benefits of link-state approaches, while 160 delimiting its downsize in the context of the wireless medium. 162 Although DABBER specification allows an easier integration with NDN 163 access networks based on NSLR (e.g. the messaging systems based on 164 the synchronization of LSA is the same), its operation is completely 165 independent of NSLR. This means that DABBER can be used in any 166 isolated wireless opportunistic network, or by any wireless node that 167 frequently attaches to fix NDN networks (e.g. by using a Wi-Fi link), 168 which do not have NLSR as their routing protocol. 170 DABBER is intended as complementing existing forwarding protocols for 171 opportunistic networks (e.g., Prophet [12], Scorp [13], dLife 172 [14][18], BubbleRap [15]). 174 1.1. Contextual Aspects 176 Prior art in forwarding solutions for opportunistic networks showed 177 that data transmission in such wireless environments needs to be done 178 based on strategies that take into consideration, at a network level, 179 the context of wireless nodes, and not just the history of contacts 180 among wireless nodes. 182 This section provides an example on how to obtain contextual 183 information that defines the availability and centrality of a 184 wireless node, based on a specific operational example that is being 185 developed in the context of the H2020 UMOBILE project [17]. 187 Contextual information is obtained in a self-learning approach, by 188 software-based agents running in wireless nodes, and not based on 189 network wide orchestration. Contextual agents are in charge of 190 computing node and link related costs concerning availability and 191 centrality metrics. Contextual agents interact with DABBER via well- 192 defined interfaces. This to say that the contextual self-learning 193 process is not an integrating part of the routing plane, as it would 194 add additional complexity to the simplified routing plane of NDN. 196 The contextual agent (named Contextual Manager, CM [7]) installed in 197 each wireless node can therefore be seen as an end-user background 198 service that seamlessly captures wireless data to characterize the 199 affinity network (roaming patterns and peers' context over time and 200 space) and the usage habits and data interests (internal node 201 information) of a node. Data is captured directly via the regular MAC 202 Layer (e.g., Wi-Fi, Bluetooth, LTE) as well as via native 203 applications for which the user configures interests or other type of 204 personal preferences. For instance, an application can request a one- 205 time configuration of categories of data interests (e.g., music, 206 food). 208 Based on the defined interface (cf. section 3.6), DABBER is able of 209 querying the local Contextual Manager about the characteristics of 210 neighbor nodes, based on three types of information: i) Node 211 availability (metric A); ii) Node centrality (metric C); iii) Node 212 similarity (metric S). 214 Node Availability (A) gives an estimate of the node availability 215 based on the usage of internal resources over time and space, such as 216 the time spent per application category (e.g. per day), as well as 217 the usage of physical resources (battery status; CPU status, etc). 219 Node Centrality (C) provides awareness about the node's affinity 220 network neighborhood context. For instance, the more visited networks 221 a node has over a period of time, the more central a node is 222 (increases the possibility for data transmission); The higher the 223 number of connections a node has over a period of time, the more 224 central a node is; The higher the node degree of node over a period 225 of time, the higher is its centrality; The lower the distances 226 traversed by the node are, the higher is its centrality. 228 Node similarity (S) provides awareness about a node's similarity 229 towards neighbor nodes, based on the assumption that the more similar 230 nodes are, the higher the probability of more robust data exchange 231 between those nodes. This metric relies on a cosine similarity to 232 provide a link cost between peer nodes. In the case of DABBER, 233 similarity is computed based on the number of encounters between peer 234 nodes and the average duration of such encounters. 236 The detailed specification of the contextual manager is out of scope 237 of this document. Nevertheless, code for such an agent is being 238 provided openly in the context of the H2020 UMOBILE project [7]. What 239 is relevant to have in mind, from a routing perspective, is that this 240 contextual plane provides weights (A, C and S) to assist the routing 241 protocol in ranking next hops, which is an aspect highly relevant in 242 the context of multiple path routing. We believe that contextual 243 awareness can assist NDN routing schemes in better dealing with 244 topological variability, by anticipating changes derived from prior 245 learning. 247 1.2. Applicability 249 DABBER is being developed to allow the deployment of wireless NDN 250 networks where nodes and links can be intermittently available, such 251 as in the case of emergency situations [25]. From an end-to-end 252 perspective we can consider two scenarios: the NDN wireless network 253 is at the fringes of the NDN core; the NDN wireless network can 254 interconnect different NDN fixed networks. 256 While the latter may support applicability scenarios typical of 257 Delay-Tolerant Networks (DTN)[21][22] for instance tunneling traffic 258 over an area lacking network deployment, the former allows the 259 extension of the applicability of information-centric networking to 260 novel scenarios such as affordable pervasive data access, low cost 261 extension of access networks, edge computing, and vehicular networks: 263 Affordable pervasive data access: 264 This scenario encompasses the implementation of NDN in personal 265 mobile nodes (e.g. smartphones) allowing users to share data and 266 messaging services by exploiting existing intermittent wireless 267 connections (e.g. Wi-Fi, Wi-Fi direct) in environment without/or 268 limited Internet access. 270 Low cost extension of access networks: 271 This scenario refers to the usage of wireless nodes (mobile or 272 fix) to extend the reach of an NDN networks while reducing CAPEX 273 costs. 275 Edge/Fog computing: 276 This scenario is related to the efforts being done to bring cloud 277 computing closer to the end-users. This scenario encompasses a 278 large set of heterogeneous (wireless and sometimes autonomous) 279 decentralized nodes able of communicating, directly or via an 280 infrastructure, in order to perform storage and processing tasks 281 without the intervention of third parties. This scenario deals 282 with nodes that might not be continuously connected to a network, 283 such as laptops, smartphones, tablets and sensors, as well as 284 nodes that may be intermittently available due to scarce 285 resources, such as wireless access routers and even Mobile Edge 286 Computing (MEC) servers. 288 V2X networks: 289 This scenario deals with the intermittent connectivity between 290 vehicles as well as between vehicles and the infrastructure. 292 1.3. NFD Adjustment to Opportunistic Networks 294 The main functionality of the Named-Data Networking Forwarding Daemon 295 (NFD) [7] is to forward Interest and Data packets. This section 296 provides a set of design considerations that need to be considered to 297 allow the operation of NFD in opportunistic wireless networks. Such 298 considerations have been implemented in a new branch of NDN, called 299 NDN-OPP [3], which code of available on GitHub 300 (https://github.com/COPELABS-SITI/ndn-opp). 302 NDN-OPP introduces a few modifications in the way NFD performs its 303 forwarding, by leveraging the concept of Faces in order to adapt the 304 operation of the NFD to the intermittent property of wireless 305 connections. This is done by the implementation of a new type of 306 face, called Opportunistic Face - OPPFace. 308 Each OPPFace is based on a system of packet queues to hide 309 intermittent connectivity from NFD: instead of dispatching packets 310 from the FIB, the OPPFace is able of delaying packet transmission 311 until the wireless face is actually connected. OPPFaces are kept in 312 the Face Table of the forwarder and their state reflects the wireless 313 connectivity status: they can be in an Up or Down state, depending 314 upon the wireless reachability towards neighbor nodes. Since packet 315 queuing is concealed inside OPPFaces, no other part of the NFD or any 316 existing forwarding strategy needs to be changed. 318 OPPFaces can be implemented by using any direct wireless/cellular 319 communication mode (e.g., Ad-Hoc Wi-Fi, Wi-Fi Direct, D2D LTE, DTN). 321 The current operational version of NDN-OPP (V1.0) makes usage of 322 group communications provided by Wi-Fi Direct. In this case there is 323 a one-to-one correspondence between an OPPFace and a neighbor node. 324 In this peer-to-peer scenario, OPPFaces can be used in two 325 transmission modes: connection-oriented, in which packets are sent to 326 a neighbor node via a reliable TCP connection over the group owner; 327 connection-less, in which packets are sent directly to a neighbor 328 node during the Wi-Fi direct service discovery phase. In the latter 329 case data transmission is limited to the size of the TXT record (900 330 bytes for Android 5.1 and above). 332 In the peer-to-peer scenario of Wi-Fi direct, DABBER operates as 333 follows: routing information is shared among all members of a Wi-Fi 334 direct group, while Interest Packets are forwarded to specific 335 neighbors. With Dabber it is the carrier of an Interest packet that 336 decides which of the neighbors will get a copy of the Interest 337 packet. Hence, with the current implementation of NDN-OPP, DABBER 338 places a copy of the Interest packet in the OPPFaces of selected 339 neighbors. In what concerns the dissemination of routing information, 340 it is ensured by: i) node mobility, meaning that nodes carry such 341 information between Wi-Fi direct groups; ii) information is passed 342 between neighbor groups via nodes that belong to more than one group. 344 In a scenario where NDN-OPP would have OPPFaces implemented based on 345 a broadcast link layer, such as ad-hoc Wi-Fi, only one OPPFace would 346 be created in each node. Such OPPFace would be used to exchange 347 packets with any neighbor node, making use of the overhearing 348 property of the wireless medium. Since with DABBER, it is the carrier 349 that decides which of the neighbors are entitle to get a certain 350 Interest packet, DABBER would need to encode in the Interest packet 351 information about the ID of the neighbors that should process the 352 overheard Interest packet. 354 This means that the operation of DABBER is the same independently of 355 the nature of the link layer protocol, the only different being the 356 number of transmissions that needs to be done at the link layer to 357 forward Interest packets and to disseminate routing information. 359 Besides the OPPFaces towards neighbor wireless nodes, NDN-OPP makes 360 use of the Wi-Fi Face, already defined in NFD, and will integrate the 361 DTN Face developed in the UMOBILE project[23]. This means that DABBER 362 is able of exploiting any available wireless Face (OPPFace, Wi-Fi 363 Face, DTN Face). Future versions of NDN-OPP will allow DAGGER to 364 exploit interfaces to other wireless access networks, such as LTE. 366 A detailed specification of NDN-OPP and OPPFaces can be found in [3]. 367 In the remainder document we will refer to OPPFaces, Wi-Fi Faces and 368 DTN Faces simply as Faces. 370 1.4. Conventions 372 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 373 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 374 document are to be interpreted as described in RFC 2119. In this 375 document, these words will appear with that interpretation only 376 when in ALL CAPS. Lower case uses of these words are not to be 377 interpreted as carrying significance described in RFC 2119. 379 2. DABBER Architecture 381 This section presents an overview of the overall DABBER protocol 382 architecture. The three major considerations to architect DABBER are: 384 i) In opportunistic networks it is not possible to know the 385 complete network topology. Hence, there is no need to disseminate 386 Adjacency information. 388 ii) In opportunistic networks it is not efficient to flood the 389 network, as shown by all prior solutions based on controlled 390 packet replication forwarding ([12][13][14][18][15]) instead of 391 broadcast as used in Epidemic routing. 393 iii) Selecting the best set of neighbors to replicate packets to, 394 may not be efficient if based only on connectivity based 395 information (e.g. inter-contact times, contact duration). 397 DABBER relies on the same message formats, message exchange process, 398 and same data structures (RIB and FIB), made available by NDN, and 399 used by NLSR. As shown in figure 1, both protocols are able of 400 populating the FIB with a list of next hops towards each name prefix. 401 This is done based on the information collected from neighbor nodes 402 and stored in the RIB. 404 Node A Node B 405 +----------+ +------------+ 406 N - |1 2| - N----- |1 2| 407 | | | | 408 |3 4| - N |3 4| 409 +----------+ | +------------+ 410 | Node C 411 | +------------+ 412 ------ |1 2| 413 | | 414 |3 4| 415 +------------+ 417 RIB FIB 418 +----------------------------+ +-----------------------+ 419 |Prefix Name | Face | Cost | | Prefix Name | Faces | 420 +----------------------------+ +-----------------------+ 421 | N | 2 | 3 | | N | 2,1,4 | 422 | N | 4 | 10 | | | | 423 | N | 1 | 5 | +---------------------- + 424 +----------------------------+ 426 Figure 1: RIB and FIB Management, node A. 428 However, NLSR needs to build a full network topology, based on 429 Adjacency Link State Advertisements (LSA), to compute shortest paths 430 towards each node in the network (based on a simple extension of the 431 Dijkstra's algorithm). After this, NLSR computes shortest paths 432 towards each data source by associating each router with name 433 prefixes, based on the information exchanged via Prefix LSAs. Such 434 name prefixes are ordered in the FIB based on the distance of the 435 path towards the data source (shortest first). 437 While NLSR relies on the dissemination of Adjacency and Prefixes 438 LSAs, DABBER only requires the dissemination of Prefix LSAs and does 439 not require the computation of shortest paths: DABBER replaces the 440 path cost used by NSLR with a data reachability cost, as described in 441 section 2.4, reducing the impact that topological changes would have 442 on the stability of routing information. 444 The computation of data reachability costs towards different data 445 sources, based on the local dissemination of name prefixes, aims to 446 avoid flooding the wireless network with Interest packets that would 447 otherwise be broadcast to all potential data sources. 449 2.1. Assumptions and Requirements 450 DABBER relies on the following assumptions: 452 o Mobile nodes are able of exploiting wireless connectivity. For 453 instance having NDN-OPP installed. 455 o Mobile nodes can be a source and destination of data, being able 456 of operating as a router: there is not a clear distinction, in 457 terms of routing process, between sources, destinations, and 458 routers. 460 In terms of requirements: 462 o LSAs must be exchanged based on Interest / Data messages, as in 463 NSLR. 465 o A synchronization mechanism should be used to exchange LSAs 466 among neighbor node, as in NSLR. 468 o LSAs should be used to distribute only name prefix reachability, 469 since building a network topology based on adjacency information 470 is not feasible in an opportunistic network. 472 o Multiple next-hops for each name prefix must be computed based 473 on local information that encodes data reachability. 475 o Link failure recovery must be local and hence, the recovery 476 process should be based on the operation of OPPFaces (UP/Down link 477 management). 479 o IP addresses or any other form of addressing a node in the 480 network must not be considered, as in NLSR. 482 o Selective information diffusion must be considered, in order to 483 avoid network flooding. 485 o Data sources must set the validity of name prefixes - validity v 486 - as an integer that represents the expiration date of the data. 488 2.2. Naming 490 DABBER makes use of NDN hierarchical naming scheme to identify each 491 wireless node. This strategy is similar to the one used by NLSR. The 492 difference is in the name semantics: being a routing protocol for 493 wired networks, NLSR uses names that reflect network structures and 494 operational practices, making it easy to identify routers belonging 495 to the same network, and operator realms. In NLSR each router is 496 named according to the network it resides in, the specific site it 497 belongs to, as well as an assigned router name, i.e., 498 ///. For example, /ATT/AtlantaPoP1/router3. 499 This semantics provide additional topological information to the 500 routing process. 502 With DABBER, we assume that DABBER is installed in mobile devices 503 (e.g. smartphones), which have a contract with a mobile operator. In 504 a networking environment, a hierarchical naming scheme still makes 505 sense to identify to which network operator does the mobile node 506 belongs to and to the home site, in case the mobile operator has more 507 than one operational site. This naming scheme still makes sense even 508 if DABBER is only used to exchange traffic over 802.11, wifi direct 509 or 802.11 adhoc links, and never over a cellular interface. 511 Since DABBER is used to exchange data directly between mobile nodes 512 in an opportunistic networking scenario, it makes use of a 513 hierarchical naming scheme that reflects the way mobile roaming 514 works: When a mobile node is used outside its home, it attempts to 515 communicate with a visited mobile network. The visited network 516 recognizes that the node does not belong to any of its networks, and 517 checks if there is a roaming agreement between the home network and 518 one of the networks of the visited operator. If so the call is routed 519 towards an international transit network. 521 Based on the operation of a mobile network, the following semantics 522 is used to name DABBER nodes:////, 523 where represents the international transit network allowing 524 roaming services for the mobile operator; refers to the 525 operator providing the mobile service; is the network site of 526 the mobile operator where the node is registered; is the 527 mobile equipment. 529 The hierarchical name is used to implement a trust model to allow 530 nodes to verify the signature of routing messages, as described in 531 section 5. 533 The information included in the hierarchical name may be used to 534 select next hops belonging to the same operator network, or nodes 535 that have the same home network. It is assumed that an opportunistic 536 wireless network is build based on wireless direct connectivity 537 between nodes that may belong to different operators and home 538 networks, but that may have roaming patterns that allows them to have 539 frequent wireless contacts. 541 2.3. LSA Dissemination 543 DABBER runs on top of NDN, making use of Interest/Data packets to 544 exchange LSAs. This means that while IP-based routing protocols push 545 updates to other routers, DABBER nodes need to pull the updates. 546 DABBER can use any underlay communication channels (e.g., TCP/UDP 547 tunnels, Link layer TXT records) to exchange LSA information. 549 DABBER benefits from NDN built-in data authenticity: since a routing 550 update is carried in an NDN data packet and every NDN data packet 551 carries a signature, a DABBER node can verify the signature of each 552 LSA message to ensure that it was generated by the claimed origin 553 node and was not tampered during dissemination. 555 Similarly to what happens with NLSR, DABBER disseminates LSAs via a 556 data synchronization mechanism (e.g. ChronoSync [9], PartialSync 557 [10]) of the local LSDB. 559 The main differences towards NLSR are: 561 o Contrary to NLSR, DABBER does not disseminate Adjacency LSAs to 562 reflect the status of the links towards neighbor nodes. 564 o As NSLR, DABBER advertises Prefix LSAs every time a new name 565 prefix is added or deleted to the LSDB. However in the case of 566 DABBER, name prefixes are advertised with a cost/metric related to 567 the validity of the associated data. 569 This peer synchronization approach is receiver-driven, meaning that a 570 node will request LSAs only when it has CPU cycles. Thus it is less 571 likely a node will be overwhelmed by a flurry of updates. In order to 572 remove obsolete LSAs, every node periodically refreshes each of its 573 own LSAs by generating a newer version. Every LSA has a lifetime 574 associated with it and will be removed from the LSDB when the 575 lifetime expires. The LSA format is shown in Figure 2. 577 Prefix LSA 578 +-----------------------------------------------------------------+ 579 | LSA | Number of |Prefix 1|Cost| ... |Prefix N|Cost| Signature | 580 | Name | Prefixes | | | | | | | 581 +-----------------------------------------------------------------+ 583 Figure 2: Prefix LSA format. 585 Each LSA used by DABBER has the name 586 ////DABBER/LSA/Prefix/. The 587 LSA is increased by 1 whenever a node creates a new version 588 of the LSA. 590 A detailed description of the LSA exchange process is provided in 591 section 3.3. 593 2.4. Multiple path Computation 595 As mentioned, DABBER considers that there is a set of potential next- 596 hops via which a name prefix N can be reached with a certain cost k. 597 This cost k represents the probability of reaching a data object 598 identified by N via a Face F, and is related to the time validity of 599 the name prefix (v). The rationale for this approach is that the 600 selection of faces that have a lower cost k (higher validity v) will 601 improve data reachability. The validity of a name prefix is set by 602 the data source as an integer that represents the expiration date of 603 the data. 605 Since different nodes can announce the same name prefix, a certain 606 name prefix may be associated with different values of k (as v shall 607 differ) over different faces, depending upon the nodes announcing 608 such name prefix: this lead to the identification of multiple next 609 hops, each one with a different cost. 611 The computation of multiple next hops is performed every time DABBER 612 has a new Name Prefix LSA (or a new version of an existing Name 613 Prefix LSA) in its LSDB (c.f. section 2.3). The sequence of 614 operations, as described in the following sub-sections are: Computes 615 a new value for the validity of a new Name Prefix in the LSDB; 616 Updates DABBER internal routing table; Updates the LSDB with the data 617 reachability information (validity) of the current node towards the 618 new Name Prefix; Updates the RIB based on the DABBER internal routing 619 table, following a Downwards Path Criterion (FIB is updated by NFD 620 based on the RIB content). Periodically DABBER will update the 621 validity values of all Name Prefixes in its internal routing table, 622 performing the consequent updates of the local LSDB and RIB, and 623 needed. 625 2.4.1. Name Prefix Validity Computation 627 When DABBER is notified that a new Prefix LSA was entered in the LSDB 628 or an existing Prefix LSA has a new version, it computes a new 629 validity for each name prefix in such Prefix LSA. 631 DABBER starts by computing a new validity v for a prefix N depending 632 upon the validity announced by the neighbor, and the relevancy of the 633 "relation" between the two neighbor nodes (e.g., node A and node B). 634 The cost of the Name Prefix, passed to NFD, will then be computed as 635 an inversely proportional value to its validity. 637 The relevancy of the "relation" between two neighbor nodes can be, 638 e.g., a measure of similarity [7], where similarity is seen as a link 639 measure, i.e., it provides a correlation cost between a node and its 640 neighbors. Or such relation can be weighted based, as is common in 641 opportunistic environments, on metrics derived from average contact 642 duration thus allowing a node to adjust the Name Prefix validity 643 based on the probability of meeting the respective neighbor again. In 644 the current implementation of DABBER, the "relation" between two 645 neighbor nodes is computed based on the three metrics (A, C, and S) 646 provided by the local contextual manager, plus a metric computed by 647 DABBER itself: the time reachability. 649 The variable considered by DABBER for the computation of the validity 650 (and cost) of a Name prefix passed by a neighbor Na are: 652 o Validity (V) - Represents the expiration date of the data 653 associated with the Name Prefix. Currently it is the UNIX 654 Timestamp (10 digit integer). 656 o Similarity metric (S) towards the neighbor Na, as passed by the 657 contextual manager (S >= 0), aiming to select neighbors with whom 658 the current node has a good communication link. 660 o Availability metric (A) towards the neighbor Na, as passed by 661 the contextual manager ( 0 < A < 1), aiming to select neighbors 662 able to process Interest packets with high probability. 664 o Centrality metric (C) towards the neighbor Na, as passed by the 665 contextual manager ( C >= 0), aiming to select neighbors with high 666 probability of successfully forwarding Interest packets. 668 o Time reachability (T) which corresponds to the RTT between 669 sending an Interest packet towards the source of such Name Prefix 670 and receiving a data packet. (0 < T < 1). Currently the value of T 671 is computed as (current time when data packet of received - time 672 when Interest packet was sent) / Validity of Name Prefix. Time 673 reachability allows DABBER to select next hops that lead to closer 674 sources. 676 Neighbor table 677 +------------------------------------------------------+ 678 | Face | Status | Metric C | Metric A | Metric S | 679 +------------------------------------------------------+ 680 | 1 | UP | 6 | 0.3 | 12 | 681 | 2 | DOWN | 4 | 0.8 | 8 | 682 | 3 | UP | 1 | 0.8 | 9 | 683 +------------------------------------------------------+ 685 Figure 3: Neighbor table. 687 The values C, A and S provided by the contextual manager are stored 688 in a Neighbor Table as shown in figure 3. Since an OPPFace is created 689 by NDN-OPP (c.f. section 1.3), the table is indexed by the number of 690 faces. The higher the values of C, A and S, the most preferential a 691 neighbor is. 693 T is measured by observing the flow of Interest and Data packets. 694 Thus, the lowest the T, the most preferential a Face is. Although 695 different nodes may have a different implementation of a face ranking 696 logic, the relevancy of T in comparison to C and A should be higher, 697 since T reflects the measured delay to reach a data source, while C 698 and A are indicators of the neighbors potential as relays. 700 Based on the above mentioned metrics the Validity of a new Name 701 Prefix (V) is updated based on two operations: 702 o V' = f (V, S') = trunc (V * S'), where: 704 S' = (S - Smin) / (Smax - Smin); Smin = 0 and Smax = max (Smax, 705 C) 707 o V'' = f (V', C', A, T) = 0.3* trunc (V' * (C'+A)) + 0.7 * trunc 708 (V' * T), where: 710 C' = (C - Cmin) / (Cmax - Cmin); Where Cmin = 0 and Cmax = max 711 (Cmax, C) 713 2.4.2. Update of DABBER internal information 715 After the computation of the validity of the Name Prefix taking into 716 account the relation of the current node with the neighbor announcing 717 it (c.f. section 2.4.1), DABBER updates its internal routing table 718 and its LSDB. The information on the routing table will be used to 719 updated the RIB of the local NFD and the information of the LSDB will 720 be announced to all the neighbor by Chronosync. 722 To update the Internal routing table, DABBER adds an entry Na for the 723 Name Prefix with a validity V''. The routing table is then ordered by 724 name prefix in decreased order of validity. 726 To update its local LSDB updated with validity of current node 727 towards the Name Prefix, DABBER can use two methods: 728 o Maximal method: Name Prefix entry on current node LSA updated 729 with max (V'', current value on LSA). 731 o Average method: Name Prefix entry on current node LSA updated 732 with max ( average (cost of Name Prefix entries on local routing 733 table), current value on LSA). 735 2.4.2. Update of RIB of the local NFD 737 After computing the new value of the validity V'' of a name prefix, 738 as described in section 2.4.1, DABBER updates the RIB entry of that 739 name prefix with the face over which the Name Prefix LSA was received 740 and the new cost of such Name prefix. The cost (k) of the Name Prefix 741 is computed based on its validity as k = trunc (100/V''). 743 DABBER assigns selection logics to name prefix, such as NDN assigns 744 forwarding strategies to name prefixes. 746 There may be different available logics to choose from: 748 o Increase diversity - The new Face is included in the RIB entry, 749 if the computed cost k helps to increase diversity of the name 750 prefix. For instance the new cost k is higher than the average 751 costs already stored for that name prefix, affected by a 752 configured diversity constant. This is include all neighbors with 753 cost = trunc (100/V''), such that 1/V'' - Avr (Costs in RIB for N) 754 > X (predefined value). 756 o Downward Path Criterion - It is a non-equal cost multi-path 757 logic that is guaranteed to be loop-free. Based on the Downward 758 Path Criterion, the X faces (the maximum number X of desirable 759 faces can be defined by configuration) to be considered for a name 760 prefix include the one with the lowest cost k plus X-1 faces that 761 have a cost k lower than the cost that the current node has itself 762 to the name prefix. This is include X neighbors with cost = 763 trunc(100/V''), such that cost is the lowest value of 1/V'' or 764 cost < 1/ V. 766 o Downward Path Criterion extension - Also considers any face over 767 which the name prefix can be reached with a cost k equal to the 768 cost that the current node has itself to the name prefix. To avoid 769 packet from looping back, there is the need to add a tiebreaker, 770 which assures that traffic only crosses one direction of equal- 771 cost links. This is, include X neighbors with cost = trunc 772 (100/V''), such that cost is the lowest value of 1/V'' or cost 773 <=1/ V. 775 2.5. Packet Forwarding 777 Packets are forwarded based on the information that is stored in the 778 FIB, which is updated by the NFD when there is an update of the RIB 779 (multicast forwarding strategy used). 781 In order to support the operation of NDN in intermittently connected 782 networks, a new type of Face was added to NFD, Opportunistic Faces 783 (OPPFaces), which allows forwarded packets to be queued, being 784 dispatched as soon as a wireless channel is established. The new 785 concept of Opportunistic Faces aims to provide support for 786 intermittent communications without requiring any other changes to 787 NFD itself. This makes co-existence of the opportunistic networks 788 side-by-side with traditional communication schemes possible. 790 The implementation of the OPPFaces depends upon the specific link 791 layer protocols based on two basic policies: In the presence of a 792 peer-to-peer link layer protocol, such as Wi-Fi Direct or D2D LTE, 793 one OPPFace should be created for each wireless neighbor; In the 794 present of broadcast link layer protocols, such as Ad-Hoc Wi-Fi, a 795 unique OPPFace should be created. 797 The state of an Opportunistic Face reflects the fact that the 798 corresponding neighbor device is currently reachable in the Wi-Fi 799 Direct range. Based on this information, the Opportunistic Face 800 decides whether to simply queue the packet or attempt a transmission 801 over the associated Opportunistic Channel. 803 Based on the feedback provided by the wireless channel, the Face can 804 decide whether to remove the packet from the queue once it has been 805 passed on to its intended peer. Furthermore, the Opportunistic Face 806 integrates a mechanism to automatically flush the queue whenever the 807 Face is brought up upon detection of the corresponding peer being 808 available in the same Wi-Fi Direct Group. 810 2.6. Loop Prevention 812 Given the multi-path nature of DABBER, the incoming Face might appear 813 among the potential next-hops for a given name prefix. For this 814 reason, DABBER applies the Incoming Face Exclusion principle [11] in 815 order to prevent forwarding Interest packets back though the Face 816 them came from, thus removing two-hop loops. 818 Furthermore, in order to detect longer forwarding loops (more than 819 two hops), DABBER relies on the nonce-based detection scheme 820 available in NDN in order to drop a looping packet as soon as it is 821 received the second time. 823 In addition, DABBER considers a loop removal mechanism, which takes 824 care of disabling the Face responsible for the looping once it is 825 detected, as described in section 3.4. 827 3. Protocol Overview 828 3.1. Overall Operation Example 830 We consider the scenario in Figure 4 to assist in the protocol 831 operation overview: namely to understand to role of DABBER to allow 832 extension of NDN operation towards wireless dynamic networks. In 833 Figure 4, nodes A, B, and C reside in an opportunistic network and 834 run DABBER, while nodes E and F are wireless edge routers running 835 another NDN routing/forwarding protocol, such as NLSR. G is a 836 wireless node running DABBER. 838 +--------------------+ 839 | +---+ | 840 | | B | . | 841 | +---+ .2+---+ | +---+ +---+ +---+ 842 |+---+ | C |3 ... | E |....| F |....| G | 843 || A |.......1+---+ | +---+ +---+ +---+ 844 |+---+ | 845 +--------------------+ 847 Figure 4: End-to-end operational example. 849 In our example, Node A starts producing some content derived, for 850 instance, from the use of an application (such as a data sharing 851 application). The produced content is stored in its local Content 852 Store with the name /NDN/video/Lisbon/nighview.mpg. Node B stores in 853 its Content Store a data object with name 854 /NDN/video/Lisbon/river.mpg, which node B received from a neighbor 855 (meaning that B have already synchronize its LSDB with such a 856 neighbor). 858 Due to the update of the Content Store, the name prefix 859 /NDN/video/Lisbon/ is stored in the LSDB of node A and B with a 860 validity of 864000 and 518400 in the case of node A and B 861 respectively. In the case of node A, the cost k of the name prefix 862 equals the validity v of the data object, e.g., v=864000 seconds (10 863 days) stipulated by the application. In the case of node B the 864 validity is the result of the computation process described in 865 section 2.4. 867 From a routing perspective, storing a name prefix in the local LSDB 868 allows the node to share the respective Prefix LSA on all its Faces, 869 excepting on the Face over which the LSA was previously received, as 870 explained in section 3.3. This LSA exchange is done when the OPPFaces 871 are up, as described in section 3.2. Node C, which got a new Prefix 872 LSA from nodes A and B, will: 874 o Update its LSDB with the Prefix LSAs received from node A and 875 node B. 877 o Update its internal routing table with two new entries for the 878 name prefix /NDN/video/Lisbon/, associated with the face towards A 879 (face1) and with the face towards B (face2), after computing the 880 values of V' and V'' for the received validity values: 882 o The validity of the name prefix is updated based on the 883 metric configured for node C: average inter-contact time. 885 o Let's assume that A and C encounter each other frequently, 886 while B and C do not meet frequently. This means that node C 887 stores 2 new entries for prefix /NDN/video/Lisbon/ in its 888 internal routing table related to face2 with a validity for A 889 higher than the one for B. 891 o Update its LSDB with the validity of the current node towards 892 the Name Prefix following the maximal or average methods (c.f. 893 section 2.4.2). 895 o Update the RIB with one new entry for the name prefix 896 /NDN/video/Lisbon/ with two faces (face 1 and face 2) with a cost 897 inversely proportional to the validity of the Name Prefix. 899 Based on the status of the FIB (updated based on the status of the 900 RIB) all interest packets that node C gets for the name prefix 901 /NDN/video/Lisbon/ will be forwards to the number of faces associated 902 to the used forwarded strategy, but respecting the ranking of faces 903 done by DABBER. 905 When node C gets in the range of router E (wireless edge router) it 906 will exchange disseminate routing information, based on some 907 interoperability issues need to be considered, as described in 908 section 4. 910 3.2. Peer Discovery and Face Setup 912 In an opportunistic network DABBER needs to manage the dynamic 913 connectivity among neighbor nodes. For this proposes the DABBER 914 protocol relies on a background process, the Connectivity Manager. 916 The current version of DABBER comes with a Connectivity Manager for 917 Wi-Fi Direct. However, such connectivity manager can be easily 918 extended to integrate other type of wireless or cellular support. The 919 description provided in this sub-section is adjusted to the case of 920 Wi-Fi Direct. 922 When booted, the Connectivity Manager starts reacting to changes in 923 the peers available within scanning range of the current node. It 924 oversees managing the connection to a Wi-Fi Direct Group and 925 automatically joins a Group if it is not part of one. 927 Upon the reception of notifications regarding changes in the peers 928 detected in the neighborhood, the Connectivity Manager updates its 929 internal peer list. If it is not currently connected to a Wi-Fi 930 Direct Group, it performs a selection heuristic to determine which 931 node to connect to. The motivation behind this selection process is 932 to attempt to minimize the number of Wi-Fi Direct Groups in a certain 933 area given that nodes can only transmit packets within the Group they 934 are currently connected to. 936 The heuristic simply favors whichever Group Owner is already detected 937 among the available peers. In the case there is exactly one Group 938 Owner, the current node attempts to join its Group. If more than one 939 or no Group Owners are available, the heuristic selects the non- 940 client node with the highest UUID. If the selected node is not the 941 current node, a connection is attempted. This heuristic guarantees 942 that the current node will never attempt to connect to a client, thus 943 breaking an existing Group. Also, all nodes located in an area, and 944 that have the same view of available peers, will all select the same 945 node as the Group Owner to which connection should be attempted. 947 For each node detected in a Wi-Fi Direct Group, a new instance of an 948 OPPFace is created. The status of an OPPFace tells us if the 949 connectivity link towards a specific node is up or down. Based on 950 this information, the OPPFace decides whether to simply queue packets 951 (when OPPFace is down) or flush the queue (when OPPFace is up). 953 In order to achieve this, whenever the node joins a Wi-Fi Direct 954 Group, it gets registered in the Group so that other nodes can send 955 packets to it. After this setup, all service changes detected within 956 the Group (connectivity up or down) are reflected into the Neighbor 957 Table (c.f. Figure 3). Upon disconnection from the Group, the node is 958 unregistered and the node returns to a state of waiting for a Group 959 to be joined. 961 3.3. Peer Communication Modes 963 This section describes the two communication methods implemented to 964 allow for direct communication between wireless neighbors over Wi-Fi 965 Direct: connection-oriented and connectionless. 967 The connection-oriented solution allows peers to exchange packets by 968 means of a reliable TCP connection established over the Wi-Fi direct 969 group owner. This type of communication system is used mostly for 970 large packets that may require reliable communication. The 971 connection-oriented solution requires the formation of a Wi-Fi direct 972 group by the connectivity manager. Once a device joins to the group, 973 it will receive a list containing information related to each 974 connected device. Since we are working with opportunistic networks, 975 it is common that some devices could join or leave the group 976 frequently. In order to deal with it, the group owner is also 977 responsible to keep the list of connected devices updated. 979 The connection-less communication method allows peers to exchange 980 packets directly without the establishment of any Wi-Fi direct group, 981 by exploiting the TXT records available during the Wi-Fi Direct 982 service discovery phase. This type of communication is used to 983 exchange small packets that require fast transmission (e.g. emergency 984 apps, Chronosync status messages). The connection-less solution 985 allows peers to exchange a short number of bytes without the 986 establishment of a TCP socket. To use this methodology, each device 987 has to listen to all announced UUID related with it. Every time that 988 a device needs to send a packet, it serializes the packet and starts 989 announcing it, during the service discovery exchange, over TXT Record 990 with the UUID of the destination. Android versions above 5.1 allow 991 the transfer of up to 900 bytes. 993 In order to implement a reliable connection-less solution, the 994 Connectivity Manager maintains a TXT Record for each intended 995 recipient of packets, which contains data packets and an 996 acknowledgement list. Since the sequence and order in which devices 997 probe and respond to one another is not controlled, a device might 998 perform the acknowledgement of a given packet received from a remote 999 peer, but might receive the packet again in the next TXT Record in 1000 the event the remote peer does not successfully probes the current 1001 device to get the pending acknowledgements. 1003 The decision of using a connection-oriented or connection-less 1004 communication is based on the following reasoning: 1005 o Hypothesis 1: Packets are exchanged between two wireless peers 1006 over a reliable TCP socket is such socket already exists; 1008 o Hypothesis 2: If a TCP connection does not exist, decision is 1009 take based on packet size. The connection-less mechanism is used 1010 for fast dispatching of small packets (limited to the size if the 1011 TXT record, which depends upon the Android version; Bigger packets 1012 will require the establishment of a reliable TCP connection over 1013 the Wi-Fi direct group owner. 1015 3.4. Multi-homing Wireless Communication 1017 Although DABBER is being specified for the operation of NDN 1018 opportunistic wireless networks, wireless devices can exploit the 1019 present of Wi-Fi infrastructure connections made available by a 1020 nearby Wi-Fi Access Point. 1022 For this propose, beside using the new OPPFaces , DABBER also makes 1023 use of the Wi-Fi Face previously implemented in NFD. The Wi-Fi face 1024 may provide higher communication resilience and lower delays, as well 1025 as the possibility for wireless devices to exchange data with 1026 standard NDN devices deployed in a faraway location. 1028 Currently DABBER allows packets to be forwarded to a subset of 1029 available faces (OPPFaces, and Wi-Fi Faces). A more static 1030 alternative can be to avoid replicating Interest packets among 1031 wireless peers devices when a Wi-Fi network is available. 1033 It is expected that NDN-aware Access Points will be able to provide 1034 wireless devices with the IP address of the local NDN router within 1035 wireless beacons. In the current version this information is made 1036 available during the configuration phase. By default, the system is 1037 configured to connect to the NDN router deployed in COPELABS, but 1038 another NDN router may be selected. 1040 3.5. LSA Exchange 1042 DABBER performs the dissemination of LSAs based on a process able of 1043 synchronizing the content of LSDBs. In this sense, all LSAs are kept 1044 in the LSDB as a name set, and DABBER uses a hash of the LSA name set 1045 as a compact expression of the set. Neighbor nodes use the hashes of 1046 their LSA name sets to detect inconsistencies in their sets. For this 1047 reason, neighbor nodes exchange hashes of the LSDB as soon as 1048 OPPFaces are UP. 1050 Current version of DABBER makes use of ChronoSync as synchronization 1051 mechanism. Chronosync allows DABBER to define a collection of named 1052 data in a local repo as a slice. LSA information are synchronized 1053 among neighbor nodes, since Chronosync keeps the repo slice 1054 containing the LSA information in sync with identically defined 1055 slices in neighboring repositories. 1057 If a new LSA name is detected in a repo, ChronoSync notifies DABBER 1058 to retrieve the corresponding LSA in order to update the local LSDB. 1059 DABBER can also request new LSAs from Chronosync when resources (e.g. 1060 CPU cycles) are available. 1062 Figure 5 shows how an LSA is disseminated between two neighbor nodes 1063 A and B, when the OPPFace is UP. To synchronize the slice 1064 representing the LSDB information in the repo, ChronoSync, on each 1065 node, periodically sends Sync Interests with the hash of its LSA name 1066 set / slice (step 1). When Node A has a new Prefix LSA in its LSDB, 1067 DABBER writes it in the Chronosync slice (step 2). At this moment, 1068 the hash value of the LSA slide of node A becomes different from that 1069 of node B. As a consequence, the Chronosync in node A replies to the 1070 Sync Interest of node B with a Sync Reply with the new hash value of 1071 its local LSA slice (step 3). The Chronosync in node B identifies the 1072 LSA that needs to be synchronized and notifies DABBER about the 1073 missing LSA, and updates its LSA name set (step 4). Since DABBER on 1074 node B has been notified of the missing LSA, DABBER sends an LSA 1075 Interest message to retrieve the missing LSA (step 5). DABBER on node 1076 A sends the missing data in a LSA Data message (step 6). When DABBER 1077 on node B receives the LSA data, it inserts the LSA into its LSDB. 1078 Chronosync on nodes A and B compute a new hash for updated the set 1079 and send a new Sync Interest with the new hash (step 7). 1081 Node A Node B 1082 +----------------------------+ +----------------------------+ 1083 | +-------------+ | |+-------------+ | 1084 | DABBER | Chronosync | | || Chronosync | DABBER | 1085 | +-------------+ | |+-------------+ | 1086 +----------------------------+ +----------------------------+ 1087 | | Sync Interest (1) | | 1088 | |------------------->| | 1089 | |<-------------------| | 1090 | New LSA (2)| | | 1091 |----------> | | | 1092 | | Sync Reply (3) | | 1093 | |------------------->| | 1094 | | | Notify (4) | 1095 | | |------------->| 1096 | | LSA Interest (5) | | 1097 |<-----------|--------------------|--------------| 1098 | | LSA Data (6) | | 1099 |------------|--------------------|------------->| 1100 | | | | 1101 | | Sync Interest (7) | | 1102 | |------------------->| | 1103 | |<-------------------| | 1105 Figure 5: LSA exchange process. 1107 When more than one LSA needs to be synchronized, the issued LSA 1108 Interest packet will contain information about as many LSAs as 1109 allowed by the Link maximum transmission unit. In the same sense one 1110 LSA Data packet may include also be used to transport information 1111 about more than one LSA. 1113 3.6. Loop Avoidance 1115 In addition to the loop avoidance mechanism of NDN, DABBER considers 1116 a loop removal mechanism, which takes care of disabling the Face 1117 responsible for the looping once it is detected. 1119 3.7. Failure and Recovery 1121 As described in section 3.2, DABBER relies on a connectivity manager 1122 that is able to react to changes in the peers available within the 1123 wireless scanning range of the current node. 1125 Upon detection of a Wi-Fi Direct Group, the connectivity manager 1126 automatically joins that Group, if it is not part of one. 1128 Upon the reception of notifications regarding changes in the peers 1129 detected in the neighborhood, the Connectivity Manager updates its 1130 internal peer list. 1132 3.8. Interface towards a Contextual Agent 1134 The interface between DABBER and CM provides the former with periodic 1135 information concerning a node's centrality (C) and a node's 1136 availability (A), as well as with a similarity weight (S) between 1137 peers (link relevancy). 1139 This interface integrates premises to perform specific requests to 1140 get the computed values C and A for a list of peers provided by 1141 DABBER. The peers are identified by hashed MACs. 1143 The interface integrates also a premise to provide a similarity 1144 weight (S) between two peers passed by DABBER to the CM. For 1145 instance, if DABBER requests similarity between node A (sender) and 1146 node B (potential successor), then the CM computes similarity for 1147 both nodes based on a specific period of time. Such analysis can 1148 assist in a better selection of peers for data transmission, for 1149 instance. 1151 3.9. Adjustment to data source mobility 1153 As NDN uses a publish/subscribe communication model, where request 1154 resolution and data transfer are decoupled, it is especially relevant 1155 to solve the problem of data source mobility. Supporting data source 1156 mobility requires, first of all, finding the new location of the 1157 source each time data sources move, and, second, updating the name 1158 resolution system according to the new location, in order to maintain 1159 the consistency of NDN forwarding. 1161 This sub-section described a new feature of DABBER which follows a 1162 new reactive approach to face the challenges of the data source 1163 mobility and consistent forwarding in Mobile ICNs. To this end, 1164 DABBER is using the efficient dissemination method for Opportunistic 1165 Networks [26] to efficiently discover data sources by replicating 1166 Interest messages in an efficient way that avoids network flooding. 1168 With this new feature the prospective forwarders for a given Interest 1169 message (which are denoted as discoverers) are limited in number and 1170 carefully selected in terms of three criteria: 1172 o Centrality: how well connected a node is in the network. The 1173 more central a node is, the bigger the chances are to find a data 1174 source. 1176 o Reliability: the likeliness a node does not drop messages. The 1177 more reliable a node is, the least probable is that the Interest 1178 message will be discarded. 1180 o Similarity: how alike the contacted candidate node is in terms 1181 of shared acquaintances. The less similar, the more likely is that 1182 it will find different nodes in the future. 1184 A combination of these three criteria defines a reward function 1185 (discoverer suitability) of an Optimal Stopping (OS) problem. If a 1186 node finds a new node with a certain value for the discoverer 1187 suitability it is difficult to know whether this value is a good one 1188 when compared with what a node could find in future contacts. This 1189 decision is not trivial: if a node chooses early-contacted discoverer 1190 candidates, good results are not guaranteed because selected 1191 discoverers could have a low discoverer suitability metric. On the 1192 other end of the spectrum, selecting late-contacted discoverer 1193 candidates does not guarantee either good discoverer nodes since it 1194 is likely that good candidates with high discovery suitability values 1195 would be skipped. 1197 DABBER is so extended with the ability to perform an OS-based 1198 strategy that allows nodes to select the most suitable node among all 1199 of the contacted ones to forward the Interest message. This strategy 1200 relies on the existence of an optimal set of stopping values such 1201 that the nth discoverer node for a certain Interest message is the 1202 first contacted node which is the best of all the previously explored 1203 nodes, if the node has contacted the first stopping value. If this 1204 node is not found, then it will be the first node which is the second 1205 best of all the previous nodes, if the node has contacted the second 1206 stopping value, and so on. Otherwise, if these nodes are not found, 1207 then, the nth discoverer node will be the last nth node before 1208 reaching the last contacted node. This makes the dissemination of the 1209 Interest messages in Mobile NDNs efficient, even, and pervasive all 1210 over the network, increasing the delivery ratio while decreasing the 1211 network overhead. 1213 4. Interoperability 1215 As mentioned in section 1.2 DABBER is being developed to allow the 1216 deployment of wireless NDN networks where nodes and links can be 1217 intermittently available. In this section we analyze the 1218 interoperability of DABBER in two scenarios: the NDN wireless network 1219 is at the fringes of a wired NDN core; the NDN wireless network can 1220 interconnect topologically separated NDN networks or hosts, via a 1221 DTN. 1223 4.1. Interoperability with NDN operation over DTNs 1225 In this sub-section, we review the deployment of DABBER over existing 1226 DTNs. We only consider deployment scenarios where NDN is deployed as 1227 an overlay over a DTN. In this case, the existing DTN infrastructure 1228 and implementation are leveraged to extend NDN operation in 1229 challenged networks. We consider scenarios such as data mulling, 1230 services to remote locations, and interconnecting different NDN hosts 1231 (fixed or mobile)[23]. 1233 In such challenged network topologies, OPPFaces may not be able to 1234 cope well with long delays or disruption due to frequent 1235 disconnections and node mobility, severely hampering network 1236 operations. A DTN face integrated into NDN-OPP provides the latter 1237 with a robust communications platform supporting communications in 1238 these conditions, by providing the option to propagate Interests to, 1239 and return Data from, remote NDN hosts or networks. These are assumed 1240 to typically reside in access points and wireless edge routers, or 1241 mobile devices and have a corresponding DTN face implementation. 1243 DABBER will employ the DTN face, either in a hop-by-hop or a multi- 1244 hop fashion, when it senses, through the connectivity manager, that 1245 the OPPFaces do not provide a high probability of successful data 1246 delivery (e.g. Time-to-completion is too high). As DTN faces operate 1247 as regular faces, multiple path computation is performed using the 1248 procedure described in section 2.4. 1250 4.2. Interoperability with NDN operation in wired networks 1252 In this sub-section we analyze the interoperability of DABBER with 1253 two potential configurations of an NDN access network based on: a 1254 routing protocol able of disseminating name prefix information, such 1255 as NLSR; a broadcast based forwarding approach. 1257 4.2.1. Interoperability with NLSR 1259 The LSA dissemination mechanism described in section 3.3 is used to 1260 ensure interoperability with NLSR. Such mechanism ensures the 1261 interoperability between a DABBER node and a NLSR edge router, since 1262 the specification used by DABBER follows the same message structure 1263 and sequence of the mechanism used by NLSR [19][20]. 1265 However, when DABBER is executing the LSA dissemination procedure 1266 over a Wi-Fi face (towards a NLSR edge router), the following updates 1267 to the procedure described in section 3.3 need to be done in order to 1268 account for the changes between DABBER and NLSR as stated in section 1269 2.3: 1270 o DABBER will ignore all notifications that Chronosync will send 1271 related to Adjacency LSAs. 1273 4.2.2. Interoperability with broadcast based forwarding 1275 Broadcast-based forwarding is a common mechanism in the design of 1276 some networks, such as switched Ethernet and mobile ad-hoc networks. 1277 In NDN networks this means that NFD broadcasts Interest packets that 1278 do not match an entry in the FIB, inserting then into the FIB the 1279 forwarding path learned through observation of Data return paths. The 1280 main challenge in broadcast based forwarding schemes is the prefix 1281 granularity problem: determine the name prefix of an inserted FIB 1282 entry from the Data name. Several solutions exist [16], including the 1283 announcements of name prefixes, as done by DABBER. 1285 In any case DABBER interoperability with such NDN networks relies on 1286 the following considerations: 1288 o When in contact with a wireless edge router, DABBER always 1289 forward Interest packet towards the Wi-Fi Face, even when the 1290 Interest packet does not match an entry in the FIB. o Interest 1291 packets received from a wireless edge router will not be 1292 broadcast. Interest packets will be forwarded if they match an 1293 entry in the FIB, or dropped otherwise. 1295 5. Security Considerations 1297 As happens with NLSR, DABBER routing messages are carried in NDN data 1298 packets containing a signature. Hence, a DABBER node can verify the 1299 signature of each routing message to ensure that it was generated by 1300 the claimed origin node and was not tampered with during 1301 dissemination. For this propose, DABBER makes use of a hierarchical 1302 trust model for routing, as used by NLSR within a single domain, to 1303 verify the keys used to sign the routing messages. 1305 Following the name structure described in section 2.2, DABBER models 1306 the trust management as a five-level hierarch, as in NLSR, although 1307 reflecting a different administrative structure: represents 1308 the authority responsible by the international transit network 1309 allowing roaming services; represents the operator 1310 providing the mobile service; represents the network site of 1311 the mobile operator where the node is registered; represents 1312 the mobile equipment. Each node can create a DABBER process that 1313 produces LSAs. 1315 With this hierarchical trust model, one can establish a chain of keys 1316 to authenticate LSAs. Specifically, a LSA must be signed by a valid 1317 DABBER process, which runs on the same node where the LSA was 1318 originated. To become a valid DABBER process, the process key must be 1319 signed by the corresponding node key, which in turn should be signed 1320 by the registered home network of the network operator. Each home 1321 network key must be signed by the operator key, which must be 1322 certified by the network authority using the network key, which is 1323 called trust anchor in NDN. 1325 Since keys must be retrieved in order to verify routing updates, 1326 DABBER allows each node to retrieve keys from its neighbors. This 1327 means that a DABBER node will use the NDN Interest/Data exchange 1328 process to gathers keys from all its direct neighbors. Upon the 1329 reception of an Interest of the type //broadcast/KEYS each 1330 neighbor looks up the requested keys in their local key storage and 1331 return the key if it is found. In case a neighbor does not have the 1332 requested key, the neighbor can further query its neighbors for such 1333 key. The used key retrieval process makes use of a broadcast 1334 forwarding strategy, stopping at nodes who either own or cache the 1335 requested keys. 1337 6. Implementation and Deployment Experience 1339 DABBER is implemented as the routing scheme for the NDN framework for 1340 Opportunistic Networks (NDN-OPP) [3]. NDN-OPP is an extension of the 1341 NDN Android implementation, aiming to support NDN communication in 1342 wireless networks by exploiting direct communication between wireless 1343 nodes, as well as intermittent Wi-Fi connectivity to the Internet 1344 (NDN global test-bed). 1346 NDN-OPP has been demonstrated in ACM ICN 2017 in Berlin [4], as well 1347 as in the NDNComm in Memphis [5]. NDN-OPP code is available in 1348 GitHub: https://github.com/COPELABS-SITI/ndn-opp 1350 6.1 Improvement of Network Service Discovery 1352 This section provides information about a set of improvements that 1353 were included in the operation of Wi-Fi Direct during the development 1354 of DABBER. Such improvements are related to the operation of the 1355 Network Service Discovery mechanism. 1357 NSD gives access to services that other devices provide on a local 1358 network. NSD implements the DNS-based Service Discovery (DNS-SD) 1359 mechanism, which allows services to be requested by specifying their 1360 type and the name of a device instance that provides the desired 1361 service. DNS-SD is supported both on Android and on other mobile 1362 platforms. 1364 NSD was also implemented on NDN-OPP, were it is responsible for 1365 detecting other devices that are using NDN-OPP via a Wi-Fi Direct 1366 network. 1368 After a set of tests, the DNS-SD library revealed some flaws: it was 1369 noticed that in some old versions of Android, sometimes devices could 1370 not get registered. This means that such devices could not be 1371 discovered. Moreover, registration and discovering processes revealed 1372 to be too slow. For that reason, NSD service should be running all 1373 the time, not only to detect new devices but also device 1374 disconnections. Once NDN-OPP deals with opportunistic communications, 1375 it should be capable of performing such processes quickly. 1377 Hence, in order to solve these issues, we developed a NSD similar 1378 implementation, based on the following guidelines: since a device 1379 joins a Wi-Fi Direct network, that device already knows the group 1380 owner's IP address. Then, we use this information to build a solution 1381 based on sockets, which has higher performance. Our solution 1382 implementation has four main components. All of them are explained in 1383 the next sub-sections. 1385 6.1.1. Peer Registration Service 1387 The registration service allows devices in a Wi-Fi group to discover 1388 NDN-OPP peers by sharing information via the group owner. When a Wi- 1389 Fi Direct connection is performed successfully, the device that 1390 performed this connection only knows the group owner's IP address. In 1391 order to be discovered, this device must advertise that it already 1392 joined the network. In order to do that, the device should make its 1393 IP address and UUID available in the group. These data is 1394 encapsulated in an NsdInfo object that is serialized and then sent 1395 over a socket to the group owner: the register service remains 1396 sending this object in configured time intervals. 1398 If the Wi-Fi Direct connection goes down, the mechanism that sends 1399 these objects stops. Then, eventually the Disconnect Detector Service 1400 classifies this device as a disconnected device. 1402 6.1.2. Peer Announcement Service 1403 This component is responsible to guarantee communications among all 1404 connected peers. In order to do that, the Discovery Service uses a 1405 socket system: when a device tries to register itself, it starts by 1406 sending, to the group owner, a NSD packet containing its personal 1407 information. The Announcement Service, which runs on the group owner, 1408 receives this packet through a socket and will notify all registered 1409 listeners. 1411 6.1.3. Leader Service 1413 This service is instantiated only by the group owner. The group owner 1414 is responsible to keep the list of connected devices consistent and 1415 updated. In order to do that, when a device joins a network and 1416 registers itself, the group owner will be notified. The Leader 1417 Service will receive the UUID and IP address of the registered device 1418 and then, if that device is not already in the list, the Leader 1419 Service will add it, and also notify all connected devices in order 1420 to keep them updated. 1422 The periodical registration requests are sent by the Register Service 1423 in order to inform the Leader Service that this device is still 1424 alive. Also a copy of these requests is sent to Disconnect Detector 1425 Service that decides when a device is considered disconnected. 1427 When a device is considered disconnected, the Disconnect Detector 1428 Service notifies the Leader Service saying that this device is 1429 considered disconnected. At that moment, the Leader Service removes 1430 that device from the list of connected devices, and notifies all 1431 connected devices. 1433 6.1.4. Disconnect Detector Service 1435 Since the group owner does not know when a device leaves the network, 1436 we developed an additional component to deal with it. The Disconnect 1437 Detector Service is responsible to define when a device is considered 1438 disconnected from the network. 1440 The Disconnect Detector Service runs periodically, incrementing a 1441 counter per each device. When this counter achieves a pre-configured 1442 number, that device is considered disconnected; The Disconnect 1443 Detector Service notifies the Leader Service that such device is 1444 disconnected. This notification is performed through onPeerLost 1445 method. 1447 The reset of this counter is performed every time the Leader Service 1448 receives a register request from that device. 1450 7. Acknowledgments 1452 The research leading to these results received funding from the 1453 European Union (EU) Horizon 2020 research and innovation programmer 1454 under grant agreement No 645124(Action full title: Universal, mobile- 1455 centric and opportunistic communications architecture, Action 1456 Acronym: UMOBILE). 1458 We thank all contributors, as well as the valuable comments offered 1459 by Lixia Zhang (UCLA) and Lan Wang (University of Memphis) to improve 1460 this draft. 1462 8. References 1464 8.1 Normative References 1466 [1] Lixia Zhang, Deborah Estrin, Jeffrey Burke, Van Jacobson, James 1467 D. Thornton, Diana K. Smetters, Beichuan Zhang, Gene Tsudik, KC 1468 Claffy, Dmitri Krioukov, Dan Massey, Christos Papadopoulos, 1469 Tarek Abdelzaher, Lan Wang, Patrick Crowley, Edmund Yeh "Named 1470 Data Networking", NDN Technical Report NDN-001, October 2010. 1472 [2] A. Afanasyev, J. Shi, B. Zhang, L. Zhang, I. Moiseenko, Y. Yu, W. 1473 Shang, Y. Li, S. Mastorakis, Y. Huang, J. P. Abraham, E. 1474 Newberry, S. DiBenedetto, C. Fan, C. Papadopoulos, D. Pesavento, 1475 G. Grassi, G. Pau, H. Zhang, T. Song, H. Yuan, H. B. Abraham, P. 1476 Crowley, S. O. Amin, V. Lehman, M. Chowdhury, and L. Wang, "NFD 1477 Developer's Guide", NDN, Technical Report NDN-0021, February 1478 2018. 1480 [3] Miguel Tavares, Paulo Mendes, "NDN-Opp: Named-Data Networking in 1481 Opportunistic Networks", Technical Report COPE-SITI-TR-18-01, 1482 January 2018. 1484 8.2 Informative References 1486 [4] Seweryn Dynerowicz, Paulo Mendes, "Named-Data Networking in 1487 Opportunistic Networks", in ACM ICN, Berlin, Germany, September 1488 2017. 1490 [5] Seweryn Dynerowicz, Omar Aponte, Paulo Mendes, "NDN Operation in 1491 Opportunistic Wireless Networks", in NDNcomm, Memphis, USA, 1492 March 2017 1494 [6] Christos-Alexandros Sarros, Sotiris Diamantopoulos, Sergi Rene, 1495 Ioannis Psaras, Adisorn Lertsinsrubtavee, Carlos Molina-Jimenez, 1496 Paulo Mendes, Rute Sofia, Arjuna Sathiaseelan, George Pavlou, 1497 Jon Crowcroft, Vassilis Tsaoussidis, "Connecting the Edges: A 1498 Universal, Mobile centric and Opportunistic Communications 1499 Architecture", IEEE Communication Magazine, February 2018 1501 [7] Rute C. Sofia, Igor Santos, Jose Soares, Sotiris Diamantopoulos, 1502 Christos-Alexandro Sarros, Dimitris Vardalis, Vassilis 1503 Tsaoussidis, Angela; d'Angelo, "UMOBILE D4.5 - Report on Data 1504 Collection and Inference Models" Technical Report, September 1505 2018. 1507 [8] NDN Project, "NFD Developer's Guide", Technical Report NDN-0021, 1508 October 2016. 1510 [9] Zhenkai Zhu and Alexander Afanasyev, "Let's ChronoSync: 1511 Decentralized Dataset State Synchronization in Named Data 1512 Networking", in Proc. IEEE ICNP, Goettingen, Germany, Oct 2013 1514 [10] Minsheng Zhang, Vince Lehman, and Lan Wang, "PartialSync: 1515 Efficient Synchronization of a Partial Namespace in NDN", NDN 1516 Technical Report NDN-0039, June 2016. 1518 [11] Klaus Schneider, Beichuan Zhang, "How to Establish Loop-Free 1519 Multipath Routes in Named Data Networking", NDN Technical Report 1520 NDN-0044, April 2017. 1522 [12] A. Lindgren, A. Doria, E. Davies, S. Grasic, "Probabilistic 1523 Routing Protocol for Intermittently Connected Networks, IETF RFC 1524 6693, Aug 2012. 1526 [13] Waldir Moreira, Paulo Mendes, Susana Sargento, "Social-aware 1527 Opportunistic Routing Protocol based on User's Interactions and 1528 Interests", in Proc. of AdhocNets, Barcelona, Spain, October 1529 2013 1531 [14] Waldir Moreira, Paulo Mendes, Susana Sargento, "Opportunistic 1532 Routing based on daily routines", in Proc. of IEEE WoWMoM 1533 workshop on autonomic and opportunistic communications, San 1534 Francisco, USA, June, 2012 1536 [15] P. Hui, J. Crowcroft, and E. Yoneki, "Bubble rap: social-based 1537 forwarding in delay tolerant networks," Mobile Computing, IEEE 1538 Transactions on, vol. 10, pp. 1576-1589, November, 2011. 1540 [16] Junxiao Shi, Eric Newberry, Beichuan Zhang, "On Broadcast-based 1541 Self-Learning in Named Data Networking", in Proc. Of IFIP 1542 Networking, Stockholm, Sweden, June 2017 1544 [17] The H2020 UMOBILE project. Grant number 645124, 2015-2018. 1546 Available via http://www.umobile-project.eu/ 1548 [18] Waldir Moreira, Paulo Mendes and Eduardo Cerqueira, 1549 "Opportunistic Routing based on Users Daily Life Routine", IETF 1551 [19] Vince Lehman, A K M Mahmudul Hoque, Yingdi Yu, Lan Wang, 1552 Beichuan Zhang, Lixia Zhang "A Secure Link State Routing 1553 Protocol for NDN", NDN Technical Report NDN-0037, January 2016. 1555 [20] Vince Lehman, Muktadir Chowdhury, Nicholas Gordon, Ashlesh 1556 Gawande, "NLSR Developer's Guide", November 2017. 1558 [21] V. Cerf, S. Burleigh, A. Hooke, L. Torgerson, R. Durst, K. 1559 Scott, K. Fall, H. Weiss, "Delay-Tolerant Networking 1560 Architecture", IETF RFC 4838, April 2007 1562 [22] K. Scott, S. Burleigh, "Bundle Protocol Specification", IETF RFC 1563 5050, November 2007 1565 [23] C.A. Sarros, A. Lertsinsrubtavee, C. Molina-Jimenez, K. 1566 Prasopoulos, S. Diamantopoulos, D. Vardalis, A. Sathiaseelan, 1567 "ICN-based Edge Service Deployment in Challenged Networks" 1568 (demo), in Proceedings of the 4th ACM Conference on Information- 1569 Centric Networking, Berlin, Germany, September 26-28, 2017 1571 [24] Paulo Mendes, Rute Sofia, Vassilis Tsaoussidis, Sotiris 1572 Diamantopoulos, Christos-Alexandros Sarros, "Information-centric 1573 Routing for Opportunistic Wireless Networks", in ACM ICN, 1574 Boston, USA, September 2018. 1576 [25] Miguel Tavares, Omar Aponte, Paulo Mendes, "Named-data Emergency 1577 Network Services", in ACM MOBISYS, Munich, Germany, June 2018. 1579 [26] Borrego, Carlos, Joan Borrell, and Sergi Robles. "Efficient 1580 broadcast in opportunistic networks using optimal stopping 1581 theory." Ad Hoc Networks 88 (2019): 5-17 1583 Authors' Addresses 1585 Paulo Mendes 1586 Airbus Defence and Space GmbH 1587 Willy-Messerschmitt Strasse 1 1588 82024 Taufkirchen 1589 Germany 1590 Email: paulo.mendes@airbus.com 1591 URI: http://www.paulomilheiromendes.com 1593 Rute Sofia 1594 COPELABS, University Lusofona 1595 Campo grande 376 1596 1749-024 Lisboa 1597 Portugal 1598 Email: rute.sofia@ulusofona.pt 1599 URI: http://www.rutesofia.com 1601 Vassilis Tsaoussidis 1602 Democritus University of Thrace 1603 University Campus 1604 69100 Komotini 1605 Greece 1606 Email: vtsaousi@ee.duth.gr 1608 Sotiris Diamantopoulos 1609 Democritus University of Thrace 1610 University Campus 1611 69100 Komotini 1612 Greece 1613 Email: diamantopoulos.sotiris@gmail.com 1615 Christos-Alexandros Sarros 1616 Democritus University of Thrace 1617 University Campus 1618 69100 Komotini 1619 Greece 1620 csarros@ee.duth.gr 1622 Carlos Borrego 1623 Department of Information and Communications Engineering 1624 Autonomous University of Barcelona 1625 08193 Bellaterra 1626 Spain 1627 carlos.borrego@uab.cat 1629 Joan Borrell 1630 Department of Information and Communications Engineering 1631 Autonomous University of Barcelona 1632 08193 Bellaterra 1633 Spain 1634 joan.borrell@uab.cat