IN DEGREE PROJECT COMPUTER SCIENCE AND ENGINEERING,SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2017

Information retentionin disaster-stricken networksusing Content Centric Networking

ELIAS ANDERSSON

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF ARCHITECTURE AND THE BUILT ENVIRONMENT

Information retention in disaster-stricken networksusing Content Centric Networking

Elias Andersson, eliaa@kth.se

Master’s Thesis in Computer Science (30 ECTS credits).

Master’s Programme, Computer Science &Degree Programme (Civilingenjör) in Computer Science and Engineering.

School of Computer Science and Communication (CSC).KTH Royal Institute of Technology. Stockholm, Sweden.

Supervisor at CSC was Sonja Buchegger.Examiner was Johan Håstad.

Commissioner was Ericsson.Supervisor at Ericsson was Adeel Malik.

2017-MM-DD.

Information retention in disaster-stricken networksusing Content Centric Networking

Abstract

The underlying architecture of the Internet has been mostly the samesince the beginning in the 1960s and the TCP/IP protocol stack remainsubiquitous. However the Internet is today used for much wider purposesthan what was originally intended and now the most common use of theInternet is for the distribution of various forms of content. InformationCentric Networking (ICN) is an alternative architecture responding tothis change in usage, intended to be more prepared to handle the newrequirements of the Internet not only today but also in the future. In ICNthe primary concern is the secure and efficient distribution of content. Incurrent research ICN is often applied to various disaster scenarios as itis believed that ICN has properties that match the requirements of suchscenarios. This thesis continues that research by developing an especiallydesigned information retention solution, that expands on the existing ICNimplementation of Content Centric Networking (CCN), with the aim ofmaximising and prolonging the availability of content in disaster-strickennetworks. The solution was then evaluated against a scenario consisting ofa sizeable network topology, created using virtual machines, with the finalresult being that the solution perform satisfactorily and thus demonstratethe potential of ICN when applied to such scenarios.

Informationsbevarande i katastrofdrabbade nätverkgenom Content Centric Networking

Referat

Internets underliggande arkitektur har varit i stort sett oförändrad se-dan begynnelsen på 1960-talet, och TCP/IP protokollstacken är fortsattuniversell. Dock så används Internet idag för betydligt bredare ändamålän de ursprungliga syftena, och nu används Internet främst för att dis-tribuera olika former av innehåll. Information Centric Networking (ICN)är en alternativ arkitektur som svarar på denna förändring i använding,avsedd att vara mer förberedd att hantera de nya kraven på Internet intebara idag men också i framtiden. I ICN är den största angelägenhetenatt distribuera innehåll på ett säkert och effektivt vis. I nuvarande forsk-ning tillämpas ICN ofta på olika sorters katastrofscenarier då tron är attICN har egenskaper som motsvarar kraven hos sådana scenarier. Den häravhandlingen fortsätter denna forskning genom att utveckla en specielltformgiven informationsbevaringslösning, som expanderar på den existe-rande ICN-implementationen Content Centric Networking (CCN), medmålet att maximera och förlänga tillgängligheten av så mycket innehållsom möjligt i katastrofdrabbade nätverk. Lösningen evaluerades sedanmot ett scenario bestående av en ansenlig nätverkstopologi, skaped medhjälp av virtuella maskiner, där det slutgiltiga resultatet var att lösning-en presterar tillfredsställande och på så vis demonstrerar potentialen hosICN vid tillämpning på sådana scenarion.

Preface

This thesis constitutes the final project for my degree in both Degree Programmein Computer Science and Engineering (Civilingenjörsutbildning i datateknik)and Master’s Programme in Computer Science at KTH. It has been a both ed-ucational end entertaining experience that I have very much appreciated.

I would like to take this opportunity to extend a special thank you to peoplewho in one way or another, directly or indirectly, contributed to this thesis.

Sonja Buchegger, for being my supervisor at KTH and providing academicguidance.

Johan Håstad, for being my examiner at KTH and ensuring that the thesisreached a sufficient academic level.

My thesis opponent, for providing extensive feedback and constructive criti-cism.

My fellow students in our thesis group at KTH, for providing feedbackand inspiration.

My managers at Ericsson, for giving me the opportunity to perform mythesis project at Ericsson.

Adeel Malik, for being my supervisor at Ericsson and providing technical guid-ance.

The rest of the team at Ericsson, for the welcoming atmosphere and greatwork environment.

Elias AnderssonStockholm, June 2017

Contents

Glossary 1

1 Introduction 51.1 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Background 82.1 Information Centric Networking . . . . . . . . . . . . . . . . . . . 82.2 Content Centric Networking . . . . . . . . . . . . . . . . . . . . . 92.3 Network requirements in a disaster . . . . . . . . . . . . . . . . . 122.4 ICN in disaster-stricken networks . . . . . . . . . . . . . . . . . . 132.5 Delay Tolerant Networking . . . . . . . . . . . . . . . . . . . . . 14

3 Related work 163.1 The disaster scenario context . . . . . . . . . . . . . . . . . . . . 163.2 Information discovery and retrieval . . . . . . . . . . . . . . . . . 173.3 Research gap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Methodology 19

5 Design 215.1 The solution system . . . . . . . . . . . . . . . . . . . . . . . . . 215.2 Delimitations and assumptions . . . . . . . . . . . . . . . . . . . 235.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6 Implementation 266.1 The CCNx codebase . . . . . . . . . . . . . . . . . . . . . . . . . 266.2 The solution application . . . . . . . . . . . . . . . . . . . . . . . 31

6.2.1 Publishing content . . . . . . . . . . . . . . . . . . . . . . 326.2.2 On a node . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.2.3 On a Content Tracker . . . . . . . . . . . . . . . . . . . . 346.2.4 Retransmissions . . . . . . . . . . . . . . . . . . . . . . . 35

7 Evaluation 377.1 The scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

8 Discussion 42

9 Conclusion 46

Bibliography 47

Glossary

This glossary covers most of the non basic terminology used throughout thisthesis and is presented in alphabetical, rather than chronological, order.

Ad hocnetwork

A network that is built spontaneously between local devices, wherethe individual network nodes forward packets to and from eachother without relying on any centralised infrastructure.

CCN Content Centric Networking. A project, started at PARC, follow-ing the ICN paradigm.

CCNx A codebase implementing the CCN specification. Originally de-veloped at PARC as part of their CCN project, it has since beenacquired by Cisco as a part of their CICN effort.

CDN Content Delivery Network or Content Distribution Network. Awidely distributed network of proxy servers that enable efficientcontent access for consumers.

CI Confidence Interval. An interval estimate for a population param-eter based on sample data from the population.

CICN Community Information Centric Networking. An ICN effort atCisco that has acquired the CCNx codebase from PARC.

ContentObject

In CCN when a consumer has requested some content it is deliv-ered from the publisher in a Data packet, in the form of a ContentObject. Content Object is thus the CCN specific term for thegeneric ICN NDO.

CT Content Tracker. In the solution developed as part of this thesis,a Content Tracker is a node in the network topology that has beenelected to maintain an overview of the content available as a wholein its identified fragment.

CS Content Store. One of the three primary data structures of a CCNrouter, along with the FIB and the PIT. It serves as a cache forContent Objects in the network.

D2D Device-to-device. End user devices communicating directly, with-out passing through the core network.

Daemon A computer program running as a background process, that is notcontrolled through user interaction.

1

Data mule A data mule enables intermittent connectivity between discon-nected network sections by physically carrying traffic betweenthem.

DNS Domain Name System. A naming system that maps human read-able domain names to numerical IP addresses.

DONA Data-Oriented Network Architecture. A project following the ICNparadigm.

DoSattack

Denial-of-Service attack. An attack intending to make some ser-vice in a network unavailable for its users by temporarily or indef-initely disrupting the host or hosts of that service.

DSMR Design Science Research Methodology. A methodology for con-ducting research in information systems that attempts to createresults serving human purposes.

DTN Delay Tolerant Networking. An architecture for delay and dis-ruption tolerant networking, originally designed for interplanetarycommunication.

Face The CCN specific term for a network interface.

FIB Forwarding Information Base. A data structure found in bothTCP/IP and CCN routers. In a CCN router it is one of threeprimary data structures along with the CS and the PIT. It mapsContent Objects to those interfaces on which a next hop on thepath toward a publisher can be found.

Frag-mented

A network is fragmented if previously connected network sectionsbecome disconnected through link failures or disruptions. Eachsuch disconnected section is then referred to as a fragment.

ICN Information Centric Networking. A paradigm for an alternativearchitecture of the Internet currently being investigated in theresearch community. Its fundamental purpose is to enable efficientand secure distribution of NDOs.

Interest One of the two primary packets used in CCN, the other beingData packets. A consumer requests some content with an Interestpacket.

IP Internet Protocol. The principal communications protocol of theInternet protocol suite. It is located on the network layer and isused for relaying datagrams across network boundaries.

JSON JavaScript Object Notation. A human readable text format fortransmitting data objects consisting of key and value pairs.

Metis A packet forwarder that was initially part of the CCNx codebaseand later became a part of the CICN effort at Cisco when Ciscoacquired CCNx. Applications interact with Metis through an API.

Name A globally unique identifier associated with a piece of content. InICN names, rather than hosts, are used for addressing and routing.

2

NDN Named Data Networking. A project following the ICN paradigmcurrently under active development, originally forked from theCCN project at PARC.

NDO Named Data Object. A piece of content with a globally uniquename in ICN. Examples include web pages, videos, documents orany other arbitrary piece of content.

NetInf Network of Information. A project following the ICN paradigm.

P2P Peer-to-peer. A distributed application architecture where tasksare partitioned between equal peers.

PARC Palo Alto Research Center. A research and development companybased out of Palo Alto in the US state of California.

PIT Pending Interest Table. One of the three primary data structuresof a CCN router, along with the CS and the FIB. It stores stateallowing Content Objects to follow the reverse request path backto the consumer.

PKI Public Key Infrastructure. A set of roles, policies and proceduresthat constitute the most common approach to manage public keyencryption and digital signatures.

Proof ofConcept

Also known as PoC. A realisation of a concept with the purposeof demonstrating its feasibility.

PSIRP Publish-Subscribe Internet Routing Paradigm. A project follow-ing the ICN paradigm.

Reverserequestpath

In CCN Content Objects are not routed back to the requestingconsumer. Instead they follow the same path as the original Inter-est packet, by consuming state left behind by the Interest. Thispath is called the reverse request path.

TCP Transmission Control Protocol. One of the primary protocols ofthe Internet protocol suite, located on the transport layer. It pro-vides reliable, ordered and error-checked communication betweenapplications running on hosts of an IP network.

TCP/IP The today ubiquitous protocol suite used throughout the Internet.

TRIAD The Internet architecture that pioneered the ICN paradigm in theearly 21st century.

UDP User Datagram Protocol. It is a protocol in the Internet proto-col suite, located on the transport layer. It is simple and con-nectionless, and while it does provide data integrity there are noguarantees for delivery, ordering or duplicate protection.

Quality ofService

Also known as QoS. The overall performance of a computer net-work, particularly the performance seen by the users of the net-work.

Vagrant A software product by HashiCorp for managing portable virtualdevelopment environments.

3

VM Virtual Machine. An emulation of computer system providing thefunctionality of a physical computer that runs on a host operatingsystem.

Web ofTrust

Also known as WoT. A cryptographic concept used for establish-ing the authenticity of bindings between public keys and theirsupposed owners.

4

Chapter 1

Introduction

This chapter serves as an introduction to the thesis, presenting the problemdomain, the objective of the thesis within that domain and the underlying moti-vation.

During the early days of Internet development in the 1960s and 1970s the pri-mary concern was to enable communication between pairs of hosts [1], oftenin the context of sharing scarce resources such as peripherals or mainframecomputers [2]. Since then the Internet has developed both continuously andsignificantly. Today it is not only exponentially greater in size but it is alsoused for much wider purposes. Unlike the original intentions, the Internet iscurrently used primarily for the distribution of various forms of content such asweb pages, videos, documents and other pieces of data [3]. On a more abstractlevel pieces of content can in this context be said to refer to any arbitrary in-formation. Overall the amount of traffic on the Internet is increasing rapidly,with the vast majority of consumer traffic being for video applications [3]. Thisnew usage pattern potentially brings with it changed or additional requirements.Because of this the today ubiquitous TCP/IP protocol suite, which was basedon the end-to-end principle with the original purposes in mind, might not bethe best choice for the future architecture of the Internet.

A relatively recent alternative approach currently being investigated in the re-search community is Information Centric Networking (ICN). The primary ob-jective of ICN is to enable efficient and secure distribution of content, drasticallydifferentiating it from TCP/IP which focuses on establishing reliable and securechannels between pairs of hosts. The ICN objective is more aligned with theincreasingly content-centric Internet usage of today [3]. This is the fundamentaldifference between TCP/IP and ICN, the former is host-centric while the latteris content-centric. In ICN the basic question concerning the network topologyis “What content is available? ” rather than “What hosts are available? ” as inTCP/IP. The ambition behind ICN is that it will be well prepared to handlethe requirements put on the Internet not only in the present but also in thefuture.

In recent research efforts ICN is often applied to different types of disasterscenarios. Emergency support and disaster recovery is in fact one of the sce-

5

narios suggested to be considered in performance evaluation studies of ICNapproaches [4]. In a disaster scenario the requirements put on a communicationnetwork, such as the Internet, differ quite significantly from those during normaloperations and it is believed that ICN could be beneficial when responding tothese requirements [5][6]. The severe consequences of a disaster were illustratedby the earthquake and subsequent tsunami that in 2011 struck the Tohokuregion on the northeast coast of Japan. Over 15,000 lives were lost and theaffected coastal areas were devastated causing around 4.4 million households tolose electricity [7], fires and a nuclear crisis in Fukushima [6]. In addition tothe terrible humanitarian consequences there was also significant damage to thecommunication infrastructure, leading to disruptions and reduced capacity [7]which limited the effectiveness of potential responses to the disaster [8].

What happened in Tohoku is one example of the possible severity of a disas-ter. The number of natural disasters has increased during the last decades [5].In 2015 the total number of people affected by natural disasters planet widewas just over 110 million with an estimation for the total economical cost be-ing approximately US $70 billion [9]. In addition to natural disasters such asearthquakes, tsunamis and hurricanes there are also human-generated disasters.For these there is a distinction between accidental, such as major industrialaccidents and deliberate, such as terrorist attacks. While these scenarios are inmany ways significantly different from each other and every event is to someextent unique, the consequences for the affected networks are often similar, inparticular relating to response, recovery and communication [6][10].

Of the consequences caused by a disaster striking a network one of the mostsevere is fragmentation. Fragmentation can happen if the disaster inflicts sig-nificant damage to the underlying network infrastructure, disrupting or evendisabling links between different network sections [10]. The previously con-nected network sections then instead become disconnected network fragments.Any communication between these fragments will then be at best heavily con-strained and at worst impossible. As a consequence of this content published inone fragment would no longer be available to hosts in other fragments.

1.1 Problem statement

The need for a high performance communication network in disaster scenariosand the hope that ICN could make the Internet satisfactorily answer that need,creates the problem domain considered in this thesis. The overarching purposeof this thesis is captured by an ambition to investigate to what degree ICN canimprove communications when applied to disaster-stricken networks This is awide ambition and the contribution made in this thesis is an approach focusingon mitigating the negative effects consequences of any network fragmentation.The more specific problem statement is then contained in the following researchquestion:

“To what degree can ICN be applied to disaster-stricken networks inorder to mitigate the decreased content availability caused by networkfragmentation?”

6

1.2 Motivation

The high number of people affected by disasters yearly, in combination with thebelief that ICN would perform better than TCP/IP as a network architecturein such circumstances, explain why disaster scenarios feature so heavily in thecurrent ICN research efforts. The primary motivation behind these researchefforts is the clear potential for humanitarian gains as communication networksperform vital functions both during and in the immediate aftermath of a disas-ter [5][6]. Examples of such vital functions are coordination of disaster responseefforts and dissemination of warnings or instructions from authorities. In thisway applying ICN could potentially lead to benefits for society, from ethicaland social perspectives. Further, achieving good communication performancein disaster scenarios would act as a demonstration of the potential of ICN as aa paradigm and as a possible replacement for TCP/IP [4], as it is an importantapplication for any candidate for the future Internet architecture.

1.3 Objective

Ericsson as a company strives to maintain sustainability and corporate respon-sibility throughout its operations. One part of that is the Ericsson Responseprogram1 which is a voluntary effort to help establish and maintain connectivityin areas affected by a disaster. The belief is that an ICN solution could act asa complement to the already existing Ericsson response solutions, by preemp-tively and proactively mitigating the negative consequences caused by networksfragmenting in a disaster scenario.

For this purpose Ericsson envisions a system utilising Content Centric Network-ing (CCN), one of several approaches that implements the ICN paradigm. Thissystem would have the primary purpose of retaining the availability of as muchcontent as possible for as long as possible in a disaster-stricken network. Thesystem would achieve this by identifying through demarcation how the networkwould most likely fragment in the event of a disaster, and proactively replicatecontent across these potential fragments while the links are still functioning re-liably. Storing the content in multiple fragments in this fashion would mitigatethe decreased content availability caused by any network fragmentation.

This system would constitute a contribution to the currently very active ICNresearch field, and its design should preferably leverage the content-centric prop-erty of ICN to a level which much of the previous work in the area has not yetdone. The ambition is further for the evaluation of the system to serve as ademonstration of the value of ICN as a paradigm by evaluating it when un-der conditions, inspired by actual disaster scenarios, that elucidate the systemcapabilities. As a system with these objectives unavoidably becomes quite am-bitious in scope, this thesis will focus only on the information replication aspect,as described in more detail in Section 5.2. The objective of the thesis can hencebe summarised into implementing and evaluating the information replicationfunctionality of this information retention system.

1https://www.ericsson.com/thecompany/press/mediakits/ericsson_response

7

Chapter 2

Background

This chapter lays the foundation for the remainder of the thesis, explaining theconcepts and technologies that are essential in order to understand the problemdomain.

2.1 Information Centric Networking

The ICN approach began with the TRIAD [11] architecture in the early 21st

century. Currently there are several research projects under active develop-ment that follow the ICN paradigm [3]. These include Data-Oriented NetworkArchitecture (DONA), Publish-Subscribe Internet Routing Paradigm (PSIRP),Network of Information (NetInf) and Content Centric Networking (CCN). Thesefour ICN projects all follow the basic ICN paradigm and thus they have manycommonalities, the most important being the following three key design princi-ples of ICN [12][2].

• Globally unique identifiers for content. Content is addressed and routedusing globally unique identifiers, which in the ICN context are callednames. This decouples content from source creating so called NamedData Objects (NDOs) [3]. An NDO is simply a piece of content with anassociated name. NDOs are completely independent from the location, orlocations, where they are hosted or stored in the network as the name re-mains the same no matter where the content is located. This is in contrastwith TCP/IP where the addressing primitive are the network hosts.

• Content oriented security model. Security is applied to content itself,rather than being based on where and how the content was obtained asis the case in TCP/IP [13]. In TCP/IP security is the responsibility ofthe communicating end points and content security is achieved throughsecuring the channel content is transmitted over. In ICN each piece ofcontent is intrinsically and permanently bound with security features ofits publisher, but exactly what those security features entail differs amongthe different ICN projects. This means that in ICN secure content can betransmitted over insecure network sections without issue. Further it does

8

not matter which device in the network that answers a content request.As long as the device has the requested content it can reply, regardlessof its relationship with the original publisher, and finally the consumerverifies the content when it is received. Trust in content is thus based ontrust in the original publisher, rather than which specific host the contentwas delivered from.

• Universal caching. Due to the significantly diminished cost of memory andcomputing power it is today feasible to have content caches at every nodein the network, something which was practically impossible in the 1960s or1970s. In ICN any node can store any content from any source in its cacheand subsequently respond to requests for that content. This enables fastcontent access reminiscent of today’s CDNs or P2P networks, but as anintrinsic part of the network architecture available for all applications [3].

These principles constitute the essence of the ICN paradigm. The primary ex-pected advantages of ICN are scalable and cost-efficient content distribution,persistent and unique naming, mobility and multihoming, disruption toleranceand a security model that decouples trust from the location content was receivedfrom [3]. These properties are critical for the future architecture of the Inter-net [3]. Some of the challenges faced by ICN are similar to those of TCP/IPbut there are also brand new ones, including determining the naming schemeand the security architecture to use [14]. While ICN is often considered a re-placement for TCP/IP, that should preferably be deployed incrementally [3], ithas alternatively been suggested to instead carefully exploit key ICN benefitsin TCP/IP in order to improve performance of services [15]. Research on ICNis overall still at a relatively early stage and therefore work continues on thesechallenges and several other remaining open issues, such as routing, resourcecontrol, privacy, legal aspects and adoptability [6][3][2][14].

2.2 Content Centric Networking

The Content Centric Networking (CCN) project was originally started at thePalo Alto Research Center (PARC) in the US state of California. Currentlythe CCN approach is being pursued by for example the Named Data Network-ing (NDN) project [3][16] and the Community Information Centric Networking(CICN) project at Cisco. In CCN communication is driven by the consumersof data, with publishers making content available for access. There are twoprimary types of packets. Consumers request some data by expressing interestin it using an Interest packet and later the corresponding content is delivered,in the form of a Content Object, in a Data packet [13]. Content Object is theCCN specific term for the generic ICN NDO.

Routing is name-based and Interests are routed hop-by-hop toward publishersusing longest prefix matching [3]. Longest prefix matching is originally a for-warding algorithm used by TCP/IP routers. When applied to CCN it meansthat a message will be forwarded according to the entry in the forwarding tablewith the name that has the longest prefix in common with the name of the mes-sage. The namespace of CCN is hierarchical, unlike several other ICN projects

9

which use flat namespaces. The structure is similar to the current URLs, wherethe hierarchy is rooted in a publisher unique prefix under which content ispublished. This means names are aggregatable when routing in a manner rem-iniscent of TCP/IP route aggregation, which improves routing scalability. ACCN router has three primary data structures [3][13].

• Forwarding Information Base (FIB). An alternative name for a forwardingtable. In CCN the FIB operates similarly to the FIB of a TCP/IP router,hence the identical name. It serves as a mapping from a Content Objectto on which network interface the next hop toward a publishing locationfor that content can be found. In CCN terminology interfaces are referredto as simply faces [3]. The primary difference when compared to the FIBof TCP/IP is the fact that CCN supports multi-sourcing. In CCN eachFIB entry can map a single Content Object to multiple faces, as the samecontent can be published at multiple network locations. How to populatethe FIB is an important problem and a common suggestion is to use arouting protocol, much like how it is done in TCP/IP. When there aremultiple alternative faces to choose from for a Content Object then aforwarding strategy is used for determining to which faces the ContentObject should actually be used forwarded.

• Pending Interest Table (PIT). The PIT stores state about forwarded Inter-ests in the form of mapping Content Objects to faces from which Interestfor that Content Object has been received. The PIT state serves as bread-crumbs for the corresponding Content Objects, as they follow the reverserequest path back to the consumer. For each hop passed the ContentObject consumes the state left behind by the initial Interest in the PIT.

• Content Store (CS). The CS is the cache where each network node canstore content, enabling on path caching. On path caching is the possibilitythat, as an Interest is routed toward a publisher, a cache hit occurs in theCS of one of the passed nodes. This reduces content download time,network traffic and the server workload [17]. The CS operates accordingto some cache strategy, for instance Least Recently Used (LRU) or LeastFrequently Used (LFU). There is no requirement for every node to sharea single cache strategy, meaning the cache strategy can be decided on anindividual node basis.

CCN has flow balance in that each Interest packet is matched by either zero,if something went wrong, or one Content Object [3][13]. In the case that theContent Object could not be delivered it is the choice of the consumer whetheror not to retransmit the Interest. The flow balance is achieved by CCN routersdoing request aggregation. If a CCN router receives a second Interest for aspecific Content Object when the first Interest has not yet been satisfied therewill already be an entry in the PIT. The only actions required are then toadd the faces the second Interest was delivered on to the mapping of the PITentry, if it is not there already and then finally to drop the Interest. Becauseof this routing in CCN is not concerned with preventing loops which are verytroublesome for TCP/IP, allowing for more liberal routing policies.

As CCN has no concept of host location it provides inherent consumer mobil-ity [3]. A consumer can disconnect from one network section, reconnect in a

10

different section and continue operating as if nothing changed. For publish-ers it is not so simple as changing the network location requires updating theFIB entries of affected network routers so they refer toward the new location,though this is mitigated somewhat by the support for multi-sourcing [18][19].Using a routing protocol it can take significant amount of time for the FIBs toreconverge. This has lead to alternative proposals for managing this mobilityissue, including introducing temporary names and proactively updating FIB en-tries [19]. Since hosts are not used in the routing process it is also difficult todisrupt a service provided by any specific device by using a Denial-of-Service(DoS) attack. However devices could instead be vulnerable against Interestflooding.

Content security is in CCN achieved through public key cryptography [3]. Pub-lishers sign content with their private key and consumers verify the contentusing the publisher’s public key. The binding between content and publishersignature is intrinsic and permanent, which is critical for enabling the universalcaching property [13]. Trust in the keys themselves must however be establishedusing external means [3]. There are multiple suggestions for how to accomplishthis including a global Public Key Infrastructure (PKI), direct experience, in-formation provided by friends and a trusted directory of keys [3]. Mahadevanet al. [20] introduced a Key Resolution Service for specifically this purpose,providing yet another alternative.

As evidenced by this description the CCN specifications of today leave manyimplementation details to be decided by the implementing party of a functionalprotocol. Examples include exactly how the routing protocol used to populatethe FIBs should function as well as the strategies for both caching and forward-ing. There exist several different such protocol implementations with workingcodebases, including CCNx2, the NDN platform3, CCN-lite4 and CICN5 byPARC, the NDN project, the University of Basel in Switzerland and Cisco re-spectively. The somewhat non apparent relationship between the different CCNprojects and codebases, in the greater context of several ICN research efforts,can be seen in Figure 1.

2http://blogs.parc.com/ccnx/3https://named-data.net/codebase/platform/4http://ccn-lite.net/5https://wiki.fd.io/view/cicn

11

Figure 1: An overview of the relationship between several ICN research efforts.

2.3 Network requirements in a disaster

Communication is a primary challenge in any disaster scenario [8][21]. Thereinlies a complication as disaster-stricken networks present several technical com-munication challenges [6][10].

In a disaster scenario much of the important communication is often of a content-centric nature [5]. Examples include warning dissemination and people messag-ing friends and family, requesting help or trying to retrieve disaster relatedinformation. If end-to-end paths are required communication of this naturecan fail during a disaster even if the desired content is actually available in thenetwork.

Links between different network sections might be disabled, causing the networkto become fragmented [6]. The fragments are then forced to rely on data mulesfor communication with the outside, most likely disconnecting network devicesfrom any centralised services. A data mule can for example be an ambulance,a drone or even a moving person carrying a handheld device. In a fragmentednetwork establishing end-to-end communication is unreliable at best and unfea-sible at worst. The potential dependency on data mules means delay tolerancebecomes a key property [6], as significant amounts of time can pass betweencontest requests and contest replies. The network fragmentation also makes itpreferable for any security solution to be as decentralised as possible. Addi-tionally, while security is always a primary concern for any network operatingunder any conditions, it is potentially even more essential in a disaster scenariowhere erroneous or malicious content can make the difference in life or deathsituations.

12

Due to infrastructure damage such as broken cables, failed routers and similarit is very likely that the overall network capacity is significantly reduced [6].This raises concerns of message prioritisation and how to avoid congestion [10]while also guaranteeing fairness. Problems with congestion further exacerbatethe requirement for delay tolerance. Power outages can also force network nodesto run on batteries or generators. This means energy is a limited resource andthus the energy efficiency of communication becomes an important considera-tion.

Huang and Lien [22] summarised seven high level requirements for deployingan emergency communication network for disaster response relevant to thesechallenges, where the first two are for end users while the latter five are foroperators:

• Popularity. The devices used in the solution should already be availableand familiar to the people that need to use them in a disaster, not justtrained professionals. For this purpose using cell phones is one viableoption [22], made increasingly attractive by recent advancements in wire-less communication technologies and protocols such as 5G and Device-to-Device communication [23].

• Usability. The solution should support task-oriented communication andprovide sufficient Quality of Service (QoS), mobility and energy efficiency.

• Practicability. If the solution needs to be deployed it should minimisedeployment cost in addition to having a simple deployment procedure.Preferably equipment in the already existing network infrastructure shouldbe used, but if additional equipment is required it should be as easy aspossible to acquisition.

• Capacity. There is significant amounts of communication in a disasterscenario, including sudden bursts in traffic, and the solution should beable to handle this satisfactorily. The communication should additionallybe fair and not starve any of the affected areas.

• Reliability. The solution should be able to operate for extended periodsof time and recover from failures.

• Operability. In order to achieve desired operations continuously for the re-quired duration of time the solution should be administrable, maintainableand repairable.

• Adaptability. In a disaster scenario circumstances and requirements canchange quickly and the solution should be able to adapt toward suchchanges.

2.4 ICN in disaster-stricken networks

ICN has several properties that make it an attractive candidate for address-ing the network challenges posed by a disaster [10]. It provides informationresilience [5] by decoupling content from source. In ICN content is addressedand routed by name so there is less dependency on the availability of certain

13

hosts or locations in the network, which is further improved by the inherentuniversal caching of an ICN network. The caching has the additional benefit ofreducing the amount of traffic in the network, which reduces both congestionand energy usage [10]. Previous research has in fact indicated than an ICN solu-tion, specifically CCN, would in general be more energy efficient than CDNs orP2P networks, which can be used for comparable functionality in conventionalTCP/IP networks [24].

The universal caches also enables cache and forward operations which can beused to achieve disruption and delay tolerance [5][10]. It is even possible toconfigure caches to operate according to cache strategies designed particularlyfor disaster scenarios. This means that as long as the content is available atsome node in the still functioning network it could remain accessible, as long asthe routing protocol is sufficiently dynamic. ICN being content-centric makesit straightforward to use data mules for communication between network frag-ments [10], allowing for intermittent levels of connectivity. It is additionallyfeasible to attach some form of priority level to content as every piece of contenthas a globally unique name [6][10].

In order to not be completely reliant on data mules it is of course necessary tomaintain some level of physical connectivity even in ICN, and ICN could in factalso provide benefits regarding connectivity resilience [5]. Communication inICN is stateless, meaning there is no need for extended long term connectionsbetween two individual hosts as in TCP/IP [10]. Further ICN natively supportsrequests being forwarded on multiple faces of a router [3]. The decoupling ofcontent from source means less reliance on a static network topology, making iteasier to establish ad hoc networks [25] on the fly between mutually reachablenodes.

There are however still issues that remain open regarding how to best use ICNin disaster scenarios [5]. One such issue is content discovery i.e. users need tolearn what name to use when requesting some emergency information. If thismapping is done by a DNS style system then that raises concerns as such a solu-tion is quite centralised. The problem of the routes used in the routing processrequiring reconverging every time the network topology changes also remains inICN. Additionally communication is in most ICN projects by default pull-based,where users request desired content. This is useful in the sense that it gives userscontrol over how and when communication is done and thus by extension overthe energy usage [5]. However it is also limiting as in a disaster scenario im-portant communication, like warnings or instructions from authorities, is oftenpush-based. While ICN having security on individual content makes decen-tralised solutions feasible [10], the security of content is still a concern. Thisis because many of the established solutions, such as centralised authenticationentities and Web of Trust (WoT) keyservers, are highly centralised [26].

2.5 Delay Tolerant Networking

A related field to ICN is Delay Tolerant Networking (DTN). DTN is a network-ing architecture originally designed for interplanetary communication, where the

14

massive distances involved means communication schemes must be able to han-dle significant delays between information requests and information responses.The architecture has since been found to be appropriate for certain terrestrialapplications as well [4]. DTN attempts to address a variety of problems withconventional TCP/IP that makes it unworkable or impractical in scenarios wheredelay and disruption tolerance is key [27]. DTN is typically preferable in situa-tions where delays are longer than TCP can handle or disruptions are the normrather than the exception [4]. DTN manages these by operating according to astore, carry and forward principle while using data mules to move data betweenfragmented network sections [4]. However DTN is still based on the end-to-endprinciple, just like TCP/IP [10].

As delay tolerance is one of the primary requirements for a network in a disasterscenario DTN has been researched in the context of disaster scenarios, justlike ICN and CCN. For example Camara, Bonnet and Filali [28] suggesteda DTN approach, using wireless networks and satellite technologies, for bothaccelerating and broadening the distribution process of public safety warningmessages. Tyson, Bigham and Bodanese [29] even suggested for future ICNdesigns to strongly consider the tolerance of high delays and disruptions in end-to-end paths of DTN, resulting in a merger of the two research directions intoa Information-Centric Delay-Tolerant Network (ICDTN). The two principlescomplement each other as ICN fundamentally provides information resiliencewhile DTN fundamentally provides connectivity resilience [4].

15

Chapter 3

Related work

This chapter places the thesis in its scientific context, surveying what relevantresearch has been done previously in the area.

3.1 The disaster scenario context

As disaster scenarios constitute a very active area of ICN research there havebeen several papers published on the topic. These usually focus on one or atmost a few of the myriad different aspects of ICN and often assumptions have tobe made regarding the existence of functioning solutions for the aspects that arenot considered. In general the ICN paradigm and its associated research effortsare both relatively young, which is illustrated by this general lack of completesolutions. For example there are papers in a disaster scenario context concern-ing security as in [26], communication schemes as in [30][31][32][33][34][35] andapplications designed specifically to take advantage of the ICN principles andproperties as in [36][37][38][39]. These papers share with this thesis primarilythe disaster scenario angle, making them tangentially relevant. However thereare further works in the disaster scenario area that are highly relevant when con-sidered from the perspective of trying to achieve information retention.

Psaras et al. [40] introduce an ICN mobile name-based replication systemcalled NREP, that is supposed to manage communications in the immediateaftermath of a disaster. At that point the network infrastructure is severelydamaged simultaneously as traffic substantially increases as people try to con-tact rescue services or affected friends and relatives. NREP enables ad hoccommunications with both spatial and temporal scoping, as well as messageprioritisation. When two devices are in close proximity to each other they sharemessages according to a weight scheme, where each message is assigned a weight.The basis of the weight includes scoping and priority level. The evaluation showsthat using NREP do in fact cause higher priority messages to get disseminatedto more nodes in the network as when compared to TCP/IP.

Monticelli et al. [41] suggest an enhanced ICN approach for information re-silience in fragmented networks where it is assumed that each fragment has an

16

assigned gateway responsible for communication with nodes outside the frag-ment. By introducing logical interfaces separate from the actual physical inter-faces they attempt to achieve good usage of any passing mobile data mules. Thegateway transmits messages to the mules according to a prioritisation scheme.The priority is based on the number of requesters for that message in the frag-ment, the size of the message and the estimated probability that the mule willbe able to successfully deliver the message. Their evaluation indicates that thesolution performs well when compared to other relevant approaches.

Yagyu and Maeda [42] present a dynamic name-based routing protocol calledDSDVN that uses the NDN architecture. It is based on an existing routingprotocol for ad hoc mobile networks called Destination-Sequenced Distance-Vector (DSDV). The DSDVN protocol is designed for reliable content retrievalin fragmented networks during disaster scenarios and provides dynamic routingand retransmission control. It fulfills two separate functions, both establishingthe route to name prefixes and detecting the state of connectivity in the network.PIT entries are more long lived than in the original NDN architecture for delaytolerance purposes. Further, retransmission is employed on a hop by hop levelrather than exclusively by the end nodes. The protocol is finally evaluatedthrough a demo where it is shown that it indeed delivers reliable content retrievalin fragmented networks.

Sourlas et al. [43] investigate a scheme for information resilience in the contextof CCN in disrupted and fragmented networks. The CCN architecture is modi-fied to support caching in end user devices in addition to routers. This enablesthe resolution and fetching of content even when the original publisher is notaccessible from the fragment. The primary addition is a new data structure inthe CCN routers called the Satisfied Interest Table (SIT). The SIT functionssimilarly to the FIB except that rather than directing toward a publisher it di-rects toward nodes where the requested content has been successfully deliveredin the past. The hope is then that at least one of these nodes will still havethe desired content stored in its cache. Simulations show that the scheme is avalid tool that prolongs the availability of content in networks where the originalpublisher is no longer accessible.

3.2 Information discovery and retrieval

In order to achieve information retention in fragmented networks it can be usefulto have solutions for content discovery and content retrieval, two broad termsconcerning schemes for learning what content is available in the network and howto retrieve it respectively. In the context of information retention in disasterscenarios content discovery can be used to learn what content is available ineach fragment while content retrieval can be used to replicate content across thefragments. There have been papers written on content retrieval in ICN including[44][45] and the work by Yagyu and Maeda [42] mentioned earlier.

Likewise there are also papers on content discovery in ICN, as in [46][47][48].In one such paper particularly relevant for this thesis Anastasiades, Sittam-palam and Braun [49] investigate three different algorithms for supporting op-

17

portunistic content discovery based on broadcast requests in wireless networkswith a broken fixed infrastructure, specifically intended for disaster scenarios.The network topology is represented as a graph and the three algorithms arebased on Breadth First Search (BFS), Depth First Search (DFS) and a hybridof the two respectively. The discovered topology of content is then stored onthe node that initiated the discovery process. In the evaluation, which coversboth flat and hierarchical namespaces, the hybrid algorithm achieves the bestoverall performance.

3.3 Research gap

The solutions designed for disaster scenarios that achieve some form om infor-mation retention primarily do so by using a routing solution [40][41][42][43].However as routing solutions require time to converge they perform best whenthe network topology is stable, which is typically not the case in a disasterscenario [5]. The changing and unreliable topology also raises concerns regard-ing the amount of network traffic and subsequently also energy usage, that arerequired by solutions that rely on broadcasting or similarly high amounts oftraffic. Therefore the aim is for the solution developed as part of this thesis tomove away from any existing solutions heavily reliant on either routing or highamounts of traffic. Instead the idea is to more reliably achieve this functionalityby leveraging the content-centricity of ICN to a higher degree and operatingin a more ad hoc manner and consequently hopefully reach greater levels ofperformance. Likewise much of the previous works are set during or after thedisaster, while this thesis focuses on preemptive efforts that will mitigate thenegative consequences of a disaster if and when it occurs.

The system considered in this thesis will, in order to succeed, have to provide acontrol structure that can integrate both content discovery and content retrievalso that it can both identify and replicate content in the network. However asmost of the existing solutions are not adjusted for the conditions that wouldapply in a disaster scenario, or make other incompatible assumptions and de-limitations, they are not directly applicable. Many of the previous works arefurther very ambitious in scope and approaches problems deemed out of scopefor this thesis, which means that much functionality they implement can beregarded as superfluous for the considered problem. A further side effect of thisis that they become increasingly complex, when in a situation as unreliable andunpredictable as a disaster scenario it is preferable to maintain simplicity andto be dependent on as few assumptions as possible. Much of the research is stillon a general ICN level rather than focusing specifically on any one specific ICNproject, such as CCN, which is the one being considered in this thesis.

This leaves an opportunity to provide an information retention solution takingthe above into account, which is a significant part of what this thesis aims toachieve by both implementing and evaluating certain functionality of such asystem.

18

Chapter 4

Methodology

This chapter covers the thesis work process, describing and motivating the usedmethodology.

In order to ensure that the work constituting this thesis was performed in astructured and scientific manner, the used methodology was inspired primarilyby the Design Science Research Methodology (DSMR) presented by Pefferset al. in their article A Design Science Research Methodology for InformationSystems Research [50]. DSMR incorporates principles, practices and proceduresrequired for conducting research in information systems that attempts to cre-ate results serving human purposes. This is both appropriate and applicablegiven that the nature of the work conducted as a part of this thesis was highlydevelopment oriented, since the primary result produced was a solution arte-fact. DSMR covers the entire process for developing the solution artefact, frombeginning to end. It consists of a total of six steps in a nominally sequentialorder:

1. Problem identification and motivation. Define the research problem toconsider and justify the value of a solution to that problem. If it is neededdivide the problem into smaller problems that can be approached sepa-rately.

2. Definition of the objectives of a solution. Rationally derive the solutionobjectives from the problem definition and an analysis of what is feasibleto achieve.

3. Design and development. Determine the architecture and functionality ofthe solution, followed by actually creating it.

4. Demonstration. Use the solution to solve problem instances through ex-perimentation, simulation or any other viable method.

5. Evaluation. Observe and measure how well the solution performs as anapproach toward managing the problem and compare the observed resultswith the solution objectives.

6. Communication. If appropriate, communicate the performed work to rel-evant target audiences.

19

The work process behind this thesis closely followed DSMR as it has been de-scribed here. Having used such an established approach should ensure a method-ology of sufficient scientific and academic standard.

The first step was to identify and motivate the considered problem, as presentedin Chapter 1. This was done through an extensive literature study. Secondly,the requirements for a desired solution system to the chosen problem were deter-mined through extraction from the literature study. However the requirementsinevitably had to be adapted toward the fact that due to the ambitious scopeof the considered problem a thesis could only reasonably and feasibly approachpart of the entire imagined solution system. This delimitation restricted thefinal solution artefact produced in this thesis to a solution application, respon-sible only for the content replication aspects of the greater solution system. Theresulting requirements then served as the basis for the design of the imaginedsolution application in an iterative process. However, again for the sake of feasi-bility, the designed solution application was limited to a Proof of Concept (PoC)level scope. Following that the solution application was implemented on top ofan existing CCN codebase which provided the required underlying network func-tionality. Then the solution application implementation was both demonstratedand evaluated, as described by the DSMR methodology, by running it on severalvirtual machines (VMs) connected in a network topology. This resulted in anevaluation scenario designed especially for the purpose of enabling analysis ofhow well the solution performed and if it achieved that which it was supposedto. Finally the solution itself and the evaluation are communicated through thisthesis and its associated presentations.

Note that in order to dissuade from any disambiguity the terms solution sys-tem and solution application refer to two vastly different concepts throughoutthis thesis. The solution system is the entire imagined solution meant to ap-proach the problem of managing the decreased content availability caused bynetworks fragmenting in disaster scenarios and is thus mostly of a theoreticaldesign nature. Meanwhile the solution application refers to the subset of thesolution system resulting from the delimitations in scope made in this thesis.The solution application thus covers only parts of the solution system and is ofa mostly practical implementation nature. The design of the solution systemis described in depth in Chapter 5, which also includes detailed descriptions ofthe made delimitations in addition to made assumptions. Following that theimplementation and evaluation of the resulting solution application are thendescribed in Chapter 6 and Chapter 7 respectively.

20

Chapter 5

Design

This chapter details the design of the system solution, describing its architectureand functionality. It also covers the made delimitations and assumptions andthe resulting solution application.

5.1 The solution system

The basic concept for the solution system is to on a best effort basis strive toensure a high degree of information retention. This is done by investigating howthe network will most likely fragment in the event of a disaster and thus identifythe potential future network fragments. Afterwards content is proactively repli-cated across these fragments and stored at strategic locations. If connectivitydeteriorates and formerly connected network sections actually become discon-nected network fragments then the ambition is that each fragment will alreadyhave separate copies of as much content as possible, ensuring more content re-mains accessible for the nodes of that fragment. This imagined functionalityis achieved by the solution system operating according to the semi-sequentialphases of the following strategy:

1. Identify the potential future network fragments, where a fragment consistsof network nodes that are relatively likely to maintain connectivity witheach other in the event of a disaster.

2. One node in each fragment is elected to serve as a Content Tracker (CT)for that fragment. The CT is responsible for having an overview of whatcontent is available in the fragment as a whole. The CT also managesthe content replication process and decides where exactly to store thereplicated content.

3. Each CT aggregates the content that is available across all nodes in itsfragment into a content map. The CT and the other nodes in the samefragment then communicate periodically in order to update the contentmap to reflect changes in available content

21

4. CTs periodically compare content maps with neighbouring CTs so thatevery fragment can learn what content is available in the other fragments.Two CTs are considered to be neighbours if any node in one of the frag-ments is connected to a node in the other fragment.

5. During these comparisons, if a CT notices that the content map of one ofits neighbours contains content it itself is missing, the CT will request suchcontent from its neighbour. In that way content is proactively replicatedto more and more fragments and eventually it will propagate throughoutthe entire topology.

According to this strategy every node in the network topology is either anordinary node, henceforth referred to simply as a node, or a CT. How thesolution system could demarcate a network topology into identified fragmentsis illustrated by the small example seen in Figure 2. In this example threefragments have been identified, each consisting of four nodes. Further, in eachfragment one of its four nodes has been elected to serve as a CT. In this example,as all three fragments are interconnected every CT has two neighbours. Notethat it is not always the case that it is only the CTs that have connections tonodes outside the local fragment, as it is fully possible for any given node in afragment to be connected to a node in another fragment.

Figure 2: An example scenario with three fragments.

The functionality for this solution system is added to all the nodes in the net-work, in the form of a solution application running on each node. This solutionapplication executes the described strategy, which obviously involves commu-nicating with other nodes in the network. This communication over the net-work is achieved using an existing CCN codebase, namely the CCNx projectof Cisco’s CICN effort. The resulting architecture is shown in Figure 3, whichillustrates how communication is structured between the solution applicationsof two arbitrary network nodes using the Metis message forwarder of CCNx asan intermediary.

22

Figure 3: The complete solution architecture.

The solution application send and receive messages only from and to Metisrespectively. Metis is an independent process also running on the node andcommunicating with it can be done through using an API provided in the CCNxcodebase. It is then the responsibility of Metis to deliver messages sent by thesolution application over the network to the solution application of the targetnode, via the Metis process running on that node.

5.2 Delimitations and assumptions

The initial delimitation made was that the solution application developed aspart of this thesis should be limited to a PoC level scope, as its purpose was notto provide a perfect implementation but rather to investigate the potential of thesolution system. The most significant delimitation made was that the solutiononly considers steps three through five of the solution algorithm described inSection 5.1, as considering all five steps would make for a scope of infeasible size.Notably this means that the developed solution application has no responsibilityfor demarcating the network topology into fragments or for electing CTs forthose fragments. The solution application thus covers the final three steps ofthe entire solution system and therefore there was no concern of any possiblefollower application with dependencies. Another significant delimitation wasthat no expectation was placed on the solution application being able to handleinput and output simultaneously as such a feature would require threading,which was deemed to be outside of the focus area of this thesis. A furtherdelimitation was that only pieces of content that can fit into a single CCNContent Object, as supported by the existing CCNx codebase, are handled for

23

replication across fragments. The reasoning behind this was again that theproblem of splitting a single piece of content into several smaller pieces andthen reassembling them at the receiver was not within the focus of this thesis.Rather it was judged a practical implementation detail of no great significancefor the overall theoretical design. Finally the solution takes the right to reservecertain names for its own use, making them unavailable in the object namespace,which otherwise is global, for other users or services on the network.

Beyond these delimitations several assumptions were also made for the sakeof practicability and feasibility. Firstly it was assumed that all nodes in thenetwork runs the complete solution architecture, as in Figure 3. As such boththe solution application and the Metis forwarder are running on every node,whether that node is a CT or not, in the topology. Additionally, since stepsone and two of the solution system are out of scope for the solution applicationof this thesis the results for those steps are covered instead by assumptions.Those results, which are thus assumed to be completed beforehand, consist ofthe following:

• The network toplogy have been demarcated into fragments in an appro-priate way.

• All network nodes have an identifier unique in the topology, called a nodeidentifier (node ID) and that identity is accessible to the node.

• All fragments have an identifier unique in the topology, called a fragmentidentifier (fragment ID) and all network nodes have been assigned to afragment. The fragment ID of the fragment that a node has been assignedto is accessible for that node.

• CTs have been elected for all fragments and all network nodes know ifthey have been elected to serve as a CT or not.

• All network nodes in a fragment has FIB entries leading toward the CT ofthat fragment. This means that nodes can send Interest messages to theirCT, which can then respond with Content Objects on the reverse requestpath.

• All CTs know which other CTs in the network topology are their neigh-bours and all network nodes on the path between any two neighbouringCTs have FIB entries leading toward both of those CTs. This means thatCTs can send Interest messages to their neighbouring CTs, which can thenrespond with Content Objects following the reverse request path.

5.3 Requirements

The requirements for the solution application were primarily inspired by theconsiderations presented in Section 2.3, which were in turn a result of an ex-tensive literature study of research efforts concerning applying ICN to disasterscenarios. Additionally the requirement level was adapted due to feasibilityconcerns, as the corresponding solution application was intended to be on aPoC level. The result was a selection of requirements deemed appropriate for

24

the imagined solution application while also maintaining feasibility within thescope of a master’s thesis. The primary aim was for the requirements to en-able both satisfactory performance and a sufficient evaluation. The final list ofrequirements was thus concretised into the following items:

• The application should implement its assigned part of the solution system,as specified by the made delimitations. Further it should operate on abest effort basis while leveraging the content-centricity of ICN and CCNas much as possible. Its primary purpose should be to achieve informationretention by replicating all available content to at least one network nodein each fragments.

• The application should utilise the already existing capabilities and func-tionalities of the used CCN specification and implementation as much aspossible, rather than making extensive application specific modifications.

• The application should not take an unreasonable amount of time to achievethe content replication.

• The application should not fail to replicate an unreasonable amount ofcontent.

• The application should not require an unreasonable amount of networktraffic.

Of these requirements the first two are quite abstract in nature and could per-haps be more accurately described as guiding principles, and of these the firstone is the most essential as it captures the purpose of the entire solution system.The latter three requirements are more related to what the solution applicationshould actually achieve and what is the desired performance level. While theydo not specify any concrete performance milestones that should be reached theyare however still sufficient in order to reliably conclude whether or not the so-lution application has any potential in achieving information retention. In fact,any requirements including a more specific performance milestone remain un-feasibly elusive as formulating them properly would require knowledge of resultssuch as those that are aimed to be achieved in this very thesis. This is becauseone cannot know where to reasonably set the bar for performance until oneknows more concerning what is and what is not feasible. As such these fiverequirements together enable an investigation of feasibility, from which in turnthe level of potential for information retention can be deduced.

25

Chapter 6

Implementation

This chapter covers the development done as part of this thesis, describingboth the solution application itself and how it interacts with the Metis for-warder.

6.1 The CCNx codebase

After about a decade of development at PARC the CCNx codebase, an imple-mentation of the CCN specification, was acquired by the US based technologyconglomerate Cisco in early 2017 and thus became a part of Cisco’s CICN ef-fort. Cisco has since then made additions to the codebase but much of theoriginal code remains, including a library containing general utilities and datastructure implementations for the C programming language. Many of the datastructures of this library are inspired by classes of Java and provide similar func-tionality. Examples include analogues to the String, ArrayList and HashMapclasses.

While this library was a convenient resource the most important part of theCCNx codebase, in the context of this thesis, was the Metis CCN forwarder.Metis has the functionality of a CCN router, in the form of an independentdaemon process, which through a provided API enables applications to sendmessages to each other over a network, exactly as described in Section 5.1. Metiscan be configured using a configuration file, which is parsed by Metis when thedaemon process is initially started. The configuration file defines the CCN layerof the network topology, which is located just above the network layer. Thistopology is created by specifying which network nodes are connected, whereeach connection corresponds to two endpoints specifying the IP addresses andports of both connected nodes. One of the endpoints is the local node, while theother is the node that it is connected to. For each connection a correspondinglistener must also be specified, which enables Metis to react when a messageis received on that connection. An additional listener is also added for thepredefined port 9695 on the localhost IP address (127.0.0.1). This endpoint iswhat local applications use when sending or receiving messages to or from Metis

26

via the provided API. Finally the configuration file can also specify FIB entries,which in Metis are referred to as routes. A route is simply a mapping between aCCN name and the connection on which messages matching that name shouldbe forwarded, where the matching strategy used is longest prefix matching. Anexample of a Metis configuration file can be seen in Figure 4 which shows howlisteners, connections and routes can be configured.

1 add listener tcp local0 127.0.0.1 96952 add listener udp local1 127.0.0.1 96953 add listener udp remote0 10.0.1.22 333024 add listener udp remote1 10.0.3.22 333025 add connection udp c0 10.0.1.21 33302 10.0.1.22 333026 add connection udp c1 10.0.3.23 33302 10.0.3.22 333027 add route c1 ccnx:/ fragX 1

Figure 4: An example configuration file for the Metis forwarder.

This example shows a Metis configuration file for a node with interfaces totwo separate networks, one with addresses in the range 10.0.1.0 to 10.0.1.255and the other with addresses in the range 10.0.3.0 to 10.0.3.255. The nodeis thus a border node for these two networks. The first two listeners are, asmentioned previously, for communicating with any applications running on thelocal node using the Metis API, with either TCP or UDP. The third and fourthlisteners enable the Metis forwarder to react to messages forwarded by otherMetis forwarders in the network. In this case there are two such listeners, onefor each of the two separate networks the local node is connected to. Next twoconnections are specified, meaning that this particular node is connected to twoother nodes and in this case it is connected to one other node on each of itsnetworks. The Metis forwarder of the local node uses the endpoint with the IPaddress 10.0.1.22 and the port number 33302 for its first network and anotherone with the IP address 10.0.1.22 and the port number 33302 for its secondnetwork. Consequently, the Metis forwarder on the first connected node usesthe endpoint with IP address 10.0.1.21 with port number 33302 and the secondconnected node uses the endpoint with IP address 10.0.3.23 and port number33302. Both of these connections use UDP and are given the identifiers c0 andc1 respectively. Finally a route is added for the CCN name ccnx:/fragX thatmaps to the connection with the identifier c1, with a cost of 1. The purpose ofspecifying a cost is so that the forwarding strategy used by Metis can make amore informed decision if there is no unique best matching FIB entry. In practiceadding this route means that an FIB entry will be created in the Metis forwarderfor the CCN name ccnx:/fragX that maps to the next hop node represented bythe endpoint with IP address 10.0.3.23 and port number 33302.

As mentioned earlier, the CCNx codebase also provides an API enabling appli-cations to communicate with Metis through portals. A portal is an abstractionof the Metis forwarder and applications can use it to send messages they wantforwarded to the Metis forwarder for that purpose. Likewise the portal can alsobe used to receive any incoming messages to the application. An example ofhow a basic application can use the portals of the Metis API to receive CCN

27

messages is shown in Figure 5.

1 PARCIdentity ∗ get_ident i ty ( ) ;2 void hand le_inte re s t (CCNxPortal ∗ , CCNxInterest ∗ ) ;34 i n t main ( i n t argc , char ∗ argv [ argc ] )5 {6 parcSecur i ty_In i t ( ) ;7 PARCIdentity ∗ i d e n t i t y = get_ident i ty ( ) ;89 CCNxPortalFactory ∗ f a c t o r y ;

10 CCNxPortalStack ∗ s tack ;11 CCNxPortal ∗ po r t a l ;12 f a c t o r y = ccnxPortalFactory_Create ( i d e n t i t y ) ;13 s tack = ccnxPortalRTA_Message ; // constant14 po r t a l = ccnxPorta lFactory_CreatePorta l ( f ac to ry , s tack ) ;15 ccnxPortalFactory_Release(& fa c t o ry ) ;1617 CCNxName ∗ name ;18 time_t t t l ;19 CCNxStackTimeout timeout ;20 name = ccnxName_CreateFromCString ( "ccnx : / fragX" ) ;21 t t l = 60 ∗ 60 ; // seconds22 timeout = CCNxStackTimeout_MicroSeconds (DEFAULT_TIMEOUT) ;2324 i f ( ccnxPorta l_Listen ( porta l , name , t t l , t imeout ) ) {25 CCNxMetaMessage ∗ msg ;26 msg = ccnxPortal_Receive ( porta l , t imeout ) ;2728 i f (msg != NULL) {29 i f ( ccnxMetaMessage_IsInterest (msg ) ) {30 CCNxInterest ∗ i n t e r e s t ;31 i n t e r e s t = ccnxMetaMessage_GetInterest (msg ) ;3233 i f ( i n t e r e s t != NULL) {34 hand le_inte re s t ( porta l , i n t e r e s t ) ;35 }36 }37 ccnxMetaMessage_Release(&msg ) ;38 }39 }4041 ccnxName_Release(&name ) ;42 ccnxPortal_Release(&po r t a l ) ;43 parc Ident i ty_Release (& i d en t i t y ) ;44 parcSecur i ty_Fin i ( ) ;4546 re turn 0 ;47 }

Figure 5: An example application using the API of the Metis forwarder.

28

While the example application shown in the figure only receives a message, theMetis API portals can of course also be used similarly to send CCN messages.Note that in order to use the Metis API an application must first provide aPARCIdentity, a generic cryptographic identity that is assigned to the applica-tion. This identity can be created through the utilities of the library mentionedin Section 6.1. In the example the application informs Metis that it listens tothe CCN name ccnx:/fragX. This causes the Metis forwarder to forward anyreceived messages that match that name to the application. The function callto receive a message from the portal API is a blocking operation, meaning theapplication cannot proceed until either a response is received or the operationtimes out. The timeout is specified as a parameter to the function call, as seenin Figure 5. As the matching is done according to longest prefix matching namessuch as ccnx:/fragX/contentA or ccnx:/fragX/contentA/versionB would both inthis case be matches.

The Metis forwarder itself was in this thesis used as it was originally provided,with one singular enhancement being the only exception. In order for the imag-ined solution application to function properly, as described in more detail inSection 6.2, bidirectional communication must be possible between any CT andthe nodes of its fragment. Note that the assumptions specified in Section 5.2only cover the direction going from any of the nodes toward the CT, as thecorresponding FIB entries are assumed to exist. Such FIB entries are of thestructure ccnx:/fragX where X is the fragment ID of the fragment in question.The CT of the fragment with the fragment ID X will then listen to this nameand thus be able to respond to any node communicating with it. This means anode can immediately send messages, for example Interests, to its CT by usingthis prefix.

Communication in the remaining direction, from the CT toward any of the nodesin the fragment, must be enabled in some other way. The made enhancementwas then to, in an ad hoc fashion, create this path in this initially non existentdirection. The enhancement triggers when a node sends a certain type of Inter-est, initiating a so called Revision Update operation of the solution application.This operation is, just like the rest of the solution application, described in moredetail in Section 6.2. The name of this Interest contains the necessary informa-tion to create a path toward the node that sent the Interest. More specificallyit has the structure ccnx:/fragX/nodeY where X is the fragment ID and Y isnode ID. Additional information is required to complete the operation but thatis instead stored in the payload of the Interest, as CCNx enables both Interestand Content Object messages to contain payloads. At the conclusion of the op-eration the CT sends a corresponding Content Object, which then of course hasthe same name, as an acknowledgement. As this Content Object travels alongthe reverse request path from the CT toward the node Metis will recognise thestructure of the name and extract the node ID. Then it creates an FIB entryfor that node, with the same interface as the one mapped to by the PIT entrymatching the Content Object. In that manner FIB entries are created leadingtoward the node along the entire path, starting from the CT. Afterwards a nodecan be reached by a CT by it sending messages with the prefix ccnx:/nodeY,where Y again is the node ID. As mentioned before, in Metis a FIB entry isreferred to as a route and adding one is as simple as a function call in the Metissource code, as illustrated in Figure 6.

29

1 void add_route ( unsigned next_hop , MetisMessageProcessor ∗ p)2 {3 MetisForwarder ∗ fo rwarder = p−>metis ;45 MetisConnectionTable ∗ t ab l e ;6 const MetisConnection ∗ conn ;78 tab l e = metisForwarder_GetConnectionTable ( forwarder ) ;9 conn = metisConnectionTable_FindById ( tab le , next_hop ) ;

1011 i f ( ! met isConnect ion_IsLocal ( conn ) ) {12 // route s to l o c a l a pp l i c a t i o n s a l r eady added1314 CCNxName ∗ name ;15 CPINameRouteProtocolType protoco l_t ;16 CPINameRouteType route_t ;17 s t r u c t t imeva l l i f e t im e ;18 unsigned co s t ;1920 name = ccnxName_CreateFromCString ( "ccnx : / nodeY" ) ;21 protoco l_t = cpiNameRouteProtocolType_STATIC ;22 route_t = cpiNameRouteType_LONGEST_MATCH;23 l i f e t im e = { 60 ∗ 60 , 0 } ; // seconds24 co s t = 1 ;2526 CPIRouteEntry ∗ route ;27 route = cpiRouteEntry_Create (name , next_hop , NULL,28 protocol_t , route_t , &l i f e t im e , co s t ) ;29 metisMessageProcessor_AddOrUpdateRoute (p , route ) ;3031 ccnxName_Release(&name ) ;32 cpiRouteEntry_Destroy(&route ) ;33 }34 }

Figure 6: How a route can be added directly in the Metis source code.

In this example a route is added for the name ccnx:/nodeY, that maps towardthe interface represented internally in Metis by the next_hop parameter.

Any names matching the general structure ccnx:/fragX/nodeY, ccnx:/fragX orccnx:/nodeY are reserved because of this enhancement, as made possible bythe delimitation specified in Section 5.2. The reasoning behind the reservationbeing that this added functionality in the Metis forwarder could fail or notfunction as expected if a name matching the general structure of these namesdid not also contain the identifiers expected by Metis. Likewise names withthese prefixes are exempt from the built in caching of the Metis forwarder.Metis will normally store any forwarded Content Object in its cache but doingthat would in this case cause the name to no longer lead all the way to the enddestination of the corresponding path, which would in turn disrupt the intendedfunctionality of the solution application as it requires the end destination to beactually reachable.

30

6.2 The solution application

The solution application is in essence a program running indefinitely, reminis-cent of a daemon, on every node in the network topology. The primary algo-rithm followed by the solution is captured by the high level psuedocode seen inFigure 7.

counter ← 1while true doif is a CT and counter % m1 = t1 then

execute CT specific actionselse if is a node and counter % m2 = t2 thenexecute node specific actions

end ifif counter ≥ limit thencounter ← 0

end ifsatisfy received Interestscounter ← counter + 1

end while

Figure 7: The basic algorithmic flow of the solution application

In this algorithm m1, t1, m2 and t2 are simply numerical constants used tocontrol the frequency of the more complex operations done by the solution ap-plication. Properly specifying the values of these variables is an exercise inexperimentation. If they are not set appropriately the solution application willeither cause a superfluous amount of traffic that rarely results in new knowl-edge regarding the state of content in the topology or it will cause the solutionsapplications to communicate too infrequently and thus make it slow to respondto content changes and therefore unreliable. The computations actually donein the implementation of this psuedocode has a negligible impact on how muchtime is required for each iteration. At the end of each iteration the solutionapplication attempts to satisfy any received Interests. The first step in thisprocess is to request any new Interests to the application from Metis. Howeverif there are no new Interests then the request will eventually timeout before thesolution application can proceed to the next iteration. The timeout used in theimplementation of the solution application was six seconds, which thus in prac-tice became the upper limit for the amount of time an iteration could require.At the same time the limit used was 16, meaning that there were 16 iterationsbefore the solution algorithm repeated. The specific actions taken by the solu-tion application, once for every such 16 iterations as in Figure 7, for nodes andCTs are described in Section 6.2.2 and Section 6.2.3 respectively.

As specified in the assumptions of Section 5.2 nodes and CTs require accessto certain results of the earlier unimplemented steps of the complete solutionalgorithm. Both nodes and CTs require access to the node ID, the fragment IDand whether or not the node has been elected to serve as a CT. AdditionallyCTs must have access to a list of its neighbouring CTs. These four results arerepresented by the four C functions seen in Figure 8.

31

1 int get_node_id ();2 int get_fragment_id ();3 bool is_ct ();4 PARCArrayList * get_neighbour_cts ();

Figure 8: The four functions mocking the unimplemented results.

PARCArrayList is one of the classes supplied in the utility and data structurelibrary mentioned in Section 6.1. As the name implies it is inspired by theArrayList class of Java and is thus a random access list. In this case each ele-ment in the list corresponds to one neighbour. These functions are mocked andsimply reads the appropriate values from a configuration file, called the solutionconfiguration file, and returns those values. One such solution configurationfile thus had to be manually created for every node in the network topology,including the CTs, and together they define how the topology is divided intofragments and how those fragments are connected.

While the primary purpose of the solution application is to replicate availablecontent across fragments, in order for any content at all to be available it mustfirst be published. This thus becomes an additional responsibility of the solutionapplication. In CCN a network node publishing content means that it announcesto the network that it can satisfy Interests with the name corresponding tothat particular content, as it has that content stored locally. How the solutionapplication publishes content is described in Section 6.2.1.

6.2.1 Publishing content

Network nodes running the solution application, both nodes and CTs, can pub-lish content in the form of files on the file system. The behaviour is similar to aweb server, where all files in a specified directory is considered to be published.In this case that directory is /published, located in the home directory. Thesolution application maintains a history over the published content by storing arevision number and the names of the files associated with that revision numberin a log file. The revision history is thus persistent. The format of this file issimple, every line represents either a new revision number, a file addition or afile removal. The solution application continuously checks the publishing direc-tory for any files being added or removed. Any time such a change is detectedthe revision log file is updated by increasing the revision number and notingwhat files were added and what files were removed, if any.

Both nodes and CTs can receive Interests for files in this directory of publishedfiles. This is done by the application informing the Metis forwarder that it islistening to a specified CCN name through the Metis API, which causes Metis toforward messages with that name to the application. This name is ccnx:/fragXfor the CT of the fragment with the fragment ID X and ccnx:/nodeY for a nodewith the node ID Y respectively.

The solution application can thus be said to use a namespace on a networknode level, rather than on an object level as per standard CCN. Since CCN

32

uses longest prefix matching on names this means CTs can receive an Interestswith names such as ccnx:/fragX/fileA.txt while nodes can receive an Interestwith a name such as ccnx:/nodeY/fileA.txt. These can be seen as a query, sentto the CT of the fragment with the fragment ID X or to the node with thenode ID Y, for the file fileA.txt respectively. This is exactly how publishingworks in the solution application. When a node with the node ID Y receivesan Interest for ccnx:/nodeY/fileA.txt it will look for a file called fileA.txt inthe publishing directory. If the file exists then it is put into the payload of aContent Object that is then sent as a response. Note that according to one ofthe delimitations made in Section 5.2 the file will always fit into the ContentObject. The behaviour of a CT is identical except that the name prefix usedis instead ccnx:/fragX, if the CT is in the fragment with fragment ID X. If thefile does not exist however then the taken action differs for CTs and ordinarynodes. A CT will check in its content map if any node in its fragment has therequested file. If that is the case then the CT will send an Interest for the fileto that node. When the file is received the CT will then forward the file to theoriginal requester and thus act as a proxy between the original requester andthe node publishing the file. For the sake of increased redundancy the CT alsostores the file locally in its own publishing directory, increasing the number ofnodes in the network publishing that specific file. A node on the other handwill simply drop any Interest for non local files as it is only responsible for localcontent. It is instead the responsibility of the sender of the Interest to insteadredirect it to either the CT of that fragment or possibly directly to a publishingnode, if any is known.

6.2.2 On a node

In addition to publishing local content a node is also responsible for notifyingits CT of any changes in that published content, which again in practice meanschanges in the publishing directory. Beyond requesting published files Interestsare also used to execute the operations of the solution algorithm. When a nodedetects a change in what content it is currently publishing it will increase itsrevision number, but also send an Interest to its CT triggering a Revision Updateoperation. The Interest used then has names of the structure ccnx:/fragX, whereX is the fragment ID, which as mentioned previously is the prefix listened to bythe CT. The Interest payload contains a key identifying the operation the latestrevision number in a JSON object. The ultimate effect of this operation is thatthe CT is informed of the latest revision of the sending node.

Additionally CTs can also trigger a Revision Request operation on a node. TheInterest used then by the CT has the structure ccnx:/nodeY, where Y is the nodeID of the target node, which as mentioned previously is the prefix listened to bynodes. The payload of the Interest is a JSON object containing a key identifyingthe operation. A Revision Request operation is used by CTs to request the listof currently published content from a node. The node responds with a ContentObject, containing the names of all of the nodes’ currently published file in aJSON object in the payload.

33

6.2.3 On a Content Tracker

As stated previously the CT is responsible for maintaining an overview of whatcontent is available in its fragment as a whole as well as replicating that contentacross fragments. The first step is to create a content map for storing contentand where it is located in the fragment. Initially the content map contains onlycontent local to to the CT itself. Anytime the CT detects a change in what con-tent it itself is currently publishing, i.e. what files are located in the publishingdirectory, it will directly update its content map to reflect this change.

For CTs Interests used to execute the operations of the solution algorithm havenames beginning with the prefix ccnx:/fragX, which again is the prefix thatCTs listen to. The payload of the Interest is a JSON object that containsa key identifying the operation to execute. For CTs two such operations aredefined:

• Revision Update. When a node detects a change in its publishing directoryit will send an Interest of this operation. The JSON object in the payloadof the Interest contains the node ID of the sending node and its latestrevision number. In addition to its content map a CT also maintainsa secondary structure, called a revision map, which maps node IDs towhich revision number associated with that node is currently representedin the content map. If the revision map does not have an entry for thesending node, or if the entry has a lower revision number than the onein the JSON object, then firstly a revision map entry is either createdor updated respectively according to the latest revision. Afterwards theCT sends an Interest of the operation Revision Request to the node. Thenode response is then to send its list of currently published files which areused to update the content map, making it actual once again. The nameof this particular Interest is on the format ccnx:/fragX/nodeY where Xis the fragment and Y is the sending node, as described in Section 6.1 sothat Metis can build the path from the CT toward the node.

• Neighbour Synchronise Request. These Interests are used between neigh-bouring CTs in order to request content maps. Such requests are periodi-cally sent by a CT to its neighbours. If a CT receives such an Interest itwill respond with a Content Object containing a JSON object with a listof all the unique content in its content map, as represented by the contentnames. Once a CT has received the content map of one of its neighbours itwill compare it to its own content map. For each file it is currently missingit will send an Interest to the neighbouring CT requesting it. When thefile is received it is stored locally and the local content map is updated toreflect the addition of this newly received file. The name of this Interest isof the structure ccnx:/fragX where X is the fragment ID of the fragment.

An example illustrating the complete message flow of how a CT responds to anode initiating a Revision Update operation with a Revision Request operationcan be seen in Figure 9.

34

Figure 9: An example message flow between a node and its CT.

In this particular example the node has detected changes in its publishing direc-tory. It therefore notifies its CT that there is now a new revision available witha Revision Update operation. The CT acknowledges this operation and then,as the newly received revision number is an update compared to what it hasstored already, uses a Revision Request operation to request this latest revisionfrom the node.

6.2.4 Retransmissions

When sending messages over a network there are many sources of possible errors.For some reason the initial Interest or the responding Content Object might belost or corrupted. As the solution application is not threaded, a delimitationspecified in Section 5.2, it is also possible for it to be unable to satisfy anInterest simply because it was busy with some other task. Such a task could bedetermining whether or not there had been any file changes in the publishingdirectory or for CTs it could be synchronising with its neighbours. In order tomanage these problems the solution application uses retransmissions.

Whenever an Interest is not satisfied the application will wait a short amount oftime before trying to send it again, in a process which is repeated several timesuntil either a response is received or an upper limit on the number of retrans-missions is reached. The Revision Update and the Revision Request operationare considered to be especially important when retransmitting Interests as eachnode will only try to inform its CT of the new revision once for each revision.For this reason Interests for these operations have a significantly higher limiton the number of alloted retransmissions when compared to other Interests, in-creasing the likelihood that they will be successfully delivered and a responsereceived. Note however that in an actual disaster scenario it is also fully possiblefor failures to be caused by either the requesting or responding node no longer

35

being connected to the network due to link disruptions or the responding nodehaving gone down entirely.

36

Chapter 7

Evaluation

This chapter describes the results for the developed solution application, present-ing the considered scenario and quantitatively evaluating the performance of thesolution application when applied to that scenario.

In order to evaluate the developed solution a network topology was createdthrough the VM development environment Vagrant. Vagrant enables the cre-ation of an entire environment of VMs and further it can be specified exactlyhow those VMs should be connected in their virtual network topology. The con-nections defined in the Vagrant environment are on the network layer, meaningthat that the network defined uses the classical IP, and control for which pairsof VMs direct communication is possible. In essence, if two VMs are specifiedas connected in the vagrant environment, they are on the same IP network andthus they can, for example, ping each other. A significant advantage of creatingthe topology through Vagrant was that the system clocks became synchronisedwithout the need to use the Network Time Protocol or similar. The solutionapplication was then installed on all of the VMs, together with a correspond-ing solution configuration file as described in Section 6.2. Likewise the Metisforwarder was also installed on all of the VMs, together with a correspondingconfiguration file as described in Section 6.1.

7.1 The scenario

The network used in the evaluation scenario consisted of 16 VMs, each emulatinga physical Ubuntu machine, that were connected to each other in a virtualwired network topology. The CCN topology is presented in the graph shown inFigure 10. This CCN topology was defined through the connections specifiedin the Metis configuration files, as such it is located above the network layerdefined during the Vagrant configuration.

37

Figure 10: The CCN topology used in the evaluation.

Each vertex in the graph represents a VM, a network node in the topology.The edges represent node connections and the nodes elected to serve as CTs aremarked as such. In this topology the 16 nodes were distributed over a total offive fragments, as illustrated in the figure by the dotted lines. Note that thetopology was not identical on the CCN layer and the underlying network layerspecified in the Vagrant environment. On the network layer the graph had to bemore complete, i.e. more nodes are connected, due to practical limitations onhow many IP networks a VM could be connected to. However this has no visibleconsequence on the scenario as the Metis forwarders are responsible for thenetwork communication and they operate according to the CCN topology. TheMetis configuration file also specified the routes corresponding to the FIB entriesfor the paths from every node to its CT and the paths between neighbouringCTs. These paths were a necessity for the solution to function properly asspecified in the assumptions of Section 5.2.

One limitation of this scenario was that it incorporated no traffic other than theone generated from the solution applications present in the network. Traffic fromregular users or similar was dismissed because it would not affect the solutionapplication anyway, except through indirectly competing with it over networkbandwidth. As managing congestion was not a primary objective of the solutionapplication, such traffic was therefore not considered. Likewise the networkwas entirely wired with no mobile devices as that would require significantlymore configuration of the Vagrant environment. From the perspective of thesolution application it is not important exactly how the connections are achievedphysically, or in this case virtually. Rather it is sufficient to simply know thatthere is a connection, without such additional details, and therefore the entirevirtual topology in Vagrant was wired.

After the configuration of the entire topology was completed a relatively simplescenario was considered that would enable the solution to demonstrate if it

38

could achieve the desired information retention. The scenario began with eachVM having a single unique file placed in its publishing directory before thesolution application was started on every VM. Immediately after the solutionapplications had been started a script for creating ten additional unique filesand placing each one in the publishing directory of a randomly chosen VM wasstarted. In the script there was a ten second pause after the placing of eachfile. This means that shortly after 90 seconds, or one and half minutes, of thescenario had passed there was a total of 26 unique files in the topology, the 16original ones and the ten random ones. This creates a lower bound for whenit was possible to for the solution application to converge by replicating all 26files to all 5 fragments.

7.2 Results

The evaluation itself consisted of measuring, according to several metrics, howwell the solution application then managed to replicate all 26 files present inthe scenario across the five fragments. The measurements were extracted fromextensive log files produced by the solution application. The complete resultsof 16 runs of this scenario can be seen in Table 1.

Run Replications (#) Convergence (s) Interests (#) Retransmissions (#)

1 26 557 191 1602 26 506 192 1583 26 489 191 1264 26 523 185 985 26 502 187 996 26 686 206 2057 26 521 193 1388 26 571 201 1709 26 430 183 92

10 26 471 184 8911 26 690 209 20912 26 553 206 17313 26 489 203 20014 26 479 187 9115 26 483 191 16316 26 450 184 100

Average 26 525 193.3 141.9

Table 1: The evaluation results.

The second column, Replications, show how many files were successfully repli-cated to all five fragments. The third column, Convergence, show how muchtime was required before all of the replicated files were present in all five frag-ments. The fourth column, Interests, show how many Interests were sent intotal by all solution applications in the topology throughout the scenario. Thefifth column, Retransmissions, show how many retransmissions had to be sent intotal by all solution applications throughout the scenario. The entire table thusshows that over 16 runs the average result was that all 26 files were replicated toall five fragments and the elapsed time at the point when that was achieved was525 seconds, or 8 minutes and 45 seconds. This was done at an average cost of

39

the solution applications together sending a total of 193.3 Interests that requireda total of 141.9 retransmissions, which corresponds to around 1.5 Interests andaround 1.1 retransmissions per fragment and file respectively.

These results from these 16 runs were then taken as samples from the entirepopulation of possible experimentation results and used as the basis for a smallstatistical analysis. The sample mean x of n samples from a population withvalues x1, x2 . . . xn is defined as in Equation (1) [51].

x =1

n

n∑i=1

xi (1)

If the underlying distribution of the population has as true values a mean of µand a variance of σ2, where σ is the standard deviation, then x can be used asan approximation for µ [51]. Further a confidence interval (CI) can be estab-lished around x that defines the range of values that have a given probabilityof including µ. Such a confidence interval has a lower bound c1 and an upperbound c2 and is defined so that the probability of µ being within these boundsequals (1− α), where α is called the significance level and (1− α) is called theconfidence level.

First, the sample standard deviation s is defined as in Equation (2) [51].

s =

√∑ni=1(xi − x)2

n− 1(2)

When the number of samples n is relatively small, where the limit for small isconventionally set to less than 30, then it is not necessarily true that the samplevariance s2 is a good estimate of the population variance σ2 [51]. In this casethe Student’s t distribution with n − 1 degrees of freedom [51] can be used tofind the lower bound c1 and upper bound c2 for the confidence interval of µ, asin Equation (3) and Equation (4) respectively [51].

c1 = x− t1−α/2;n−1s√n

(3)

c2 = x+ t1−α/2;n−1s√n

(4)

In these equations the value t1−α/2;n−1 is defined such that a random variableT , following the Student’s t distribution with n−1 degrees of freedom, will obeythe relation for the probability shown in Equation (5) [51].

Pr[T ≤ t1−α/2;n−1] = 1− α/2 (5)

The actual value t1−α/2;n−1 can be found in precomputed tables [51].

In this manner such confidence intervals can be found for the convergence time,the number of sent Interests and the number of required retransmissions shown

40

in the results of Table 1. These confidence intervals were calculated with a con-fidence level of 90%. This means that there is a 90% probability that the truedistribution mean µ of the underlying population is within the confidence inter-val [51]. The remaining 10% is symmetrically allocated so that half is below thelower bound c1 of the confidence interval and the other half is above the upperbound c2 of the confidence interval. The corresponding value for t1−α/2;n−1,with 15 degrees of freedom, is 1.753 for such a confidence interval6.

The final confidence intervals for the population mean µ became:

• Convergence. The lower bound c1 was 492.6 and the upper bound c2 was557.4, with 525 being the value for the sample mean x.

• Interests. The lower bound c1 was 189.4 and the upper bound c2 was197.2, with 193.3 being the value for the sample mean x.

• Retransmissions. The lower bound c1 was 122.9 and the upper bound c2was 161.0, with 141.9 being the value for the sample mean x.

6https://www.medcalc.org/manual/t-distribution.php

41

Chapter 8

Discussion

This chapter qualitatively investigates the developed solution application and thecorresponding evaluation, analysing and motivating its strengths and weaknesseswith a special focus on how well it matches its requirements.

The solution application was consistently successful in replicating all uniquefiles across all fragments during the evaluation. This was always the primarypurpose of the not only the solution application but also the entire solutionsystem. The solution application is separated from the solution system by itsdelimitations and the made assumptions. However all of the assumptions madeby the solution application are related to the unimplemented functionality ofthe solution system and could realistically be implemented in the future. Assuch these initial results for the solution application show promise. Beyond thisprimary purpose there were also several requirements defined for the solutionapplication in Section 5.3. The most apparent way to qualitatively evaluate thesolution application is to compare its results to these requirements.

As specified in the requirements, the solution does indeed operate on a best effortbasis, as it provides no guarantees for the number of replicated files. While itnever occurred in in the evaluation there is still a theoretical possibility that afile is not replicated. This can happen if either a Revision Update operation orthe following Revision Update operation fail, even though an increased amountsof retransmissions are enabled for those operations. What happens then is thatthe CT will never learn of the newly published file or files now available in thefragment. Though it is entirely possible that, if later another change happens inthe publishing directory of the same node, the next Revision Update operationand Revision Update operation succeed and cover the earlier failure. Nonethelessit is a reassuring sign that such a failure never occurred in the evaluation as thatimplies that the probability of it happening is quite low, which in turn meansthat the solution application is reliable.

Leveraging the content-centricity of ICN was primarily done through the nodelevel namespace. Having the namespace on this level enabled the solution ap-plication to not only learn what content was available, but also exactly wherethat content was available from. Because of this the CTs could replicate contentto other fragments even though there did not necessarily exist any FIB entries

42

for specific pieces of content. However a node level namespace also comes withthe significant disadvantage of interfering with the universal caching propertyof ICN. If the same piece of content is published on two separate nodes in thenetwork it will be represented by two separate names, for example nodeY/fileAand nodeY/fileA. As the caching of Metis is based on name only this meansthat a router that caches content with the first name will not be able to usethat cached content to satisfy requests for the second name, even though inreality both names correspond to the same exact piece of content. To managethis either the node level namespace can be abstracted into some form of loca-tor so that the names can be identical or Metis can be extensively modified tosomehow recognise that even though the names differ the associated content isthe same. Both of these approaches are at the very least feasible to implementmeaning that this problem could be solved, though not within the scope of thisparticular thesis.

The solution application does not rely on any extensive modifications to theMetis forwarder or the general CCN architecture. This matches the require-ments well and promotes applicability. If it can be avoided it is preferable tonot reserve any names in the namespace as doing so reduces applicability andemployability since it is very challenging to enforce globally. Likewise it is diffi-cult to ensure that all nodes in an actual topology run the solution architecture,which is required in order for it to achieve the best possible result. The scalabil-ity of the solution application is in general a question that cannot be properlyaddressed by the evaluation as it covered only a relatively small scenario. Bothrequiring the ability to reserve names in a global namespace and requiring thateach network node and fragment have been assigned globally unique identi-fiers raises further questions regarding scalability. The relatively low amountof traffic generated by the solution application does however indicate that atleast that aspect of the solution could scale, even if it was a relatively smallscenario. Scalability is a concern not only for this particular solution but alsofor the entire ICN field, with a common example being how to make an objectlevel namespace scale when it could potentially require an enormous amount ofFIB entries in routers. However employability and scalability were not primaryconcerns of this thesis. Rather the primary concern was to show the potentialfor a high degree of information retention, which the solution was able to do atthe cost of increased administrative overhead.

The last three requirements were more focused on the solution performing sat-isfactorily. It is of course difficult at this early stage to more precisely definewhat exactly is an unreasonable amount of file replication failures, number ofsent Interests or number of required retransmissions. However as shown by theevaluation it seems the probability for a replication failure is quite low. Addi-tionally the number of sent Interests and the number of required retransmissionsare also quite low in relation to the amount of files and fragments. While itwould be desirable to have more concrete performance milestone metrics theycannot be reasonably defined before more research has been made. Instead theresults for the metrics actually measured in the evaluation can be considered asreasonable, given that the objective was merely to investigate the potential ofusing ICN to achieve information retention.

An advantage of the solution is that it does not rely on any broadcasting in

43

the network, which quickly leads to large amounts of traffic, but rather directcommunication between network nodes. While the solution does not send anyunnecessary messages the format of the sent messages could perhaps be more ef-ficient. An obvious improvement would be for CTs to not request complete listsof unique content each time they synchronise with their neighbours. Insteadthey could just request for any eventual additions in available content. Howeveras this both does not affect the core functionality and also is quite inconsequen-tial when the amount of available content is as low as in the evaluation scenarioit was deemed an unnecessary complication. Still, it would decrease the size ofthose messages which would in turn reduce the amount of used bandwidth. Itis also a step toward being able to lift the assumption that any piece of contentwill fit into a single Content Object. The number of retransmissions could mostlikely be drastically reduced by making the solution application threaded so thatit could respond to Interests for published files while at the same time perform-ing other tasks such as a CT synchronising with its neighbours. However thisimprovement does also not affect the core functionality and is arguably outsidea scope limited to a PoC level application that does not completely implementthe entire solution system. For a more extensive study there are several addi-tional metrics to the ones used in the evaluation that could be considered whenevaluating an ICN, or as in this case CCN, solution. These include traffic met-rics such as download time, goodput, startup latency, throughput and packetdelay in addition to component metrics such as resolution time, request rate andcache hit ratio [52]. On a grander scale system metrics concerning reliabilityand delay or disruption tolerance can be considered.

While the solution application is appropriate for a disaster scenario in that itsuccessfully replicated content across all fragments, a primary concern is theenergy efficiency it had while doing so. The energy effieciency is not only criti-cal for the functionality of the solution application itself but it also reduces anyenvironmental impact. It depends primarily on how much time elapses betweeneach time network nodes need to communicate, as the communication is of arepeating pattern. Sending messages over the network requires hardware usage,which should make up the majority of the energy usage for the solution appli-cation. In the evaluation the number of sent messages were not unreasonablewhich is thus an indicator for a good level of energy efficiency. However frequentnode communication is beneficial for the actuality of the state of content in thetopology stored in the CTs. Where to balance the solution between energy effi-ciency on one hand and content state actuality on the other is not obvious. Thisis a question of prioritisation without a clear correct answer and in this initialsolution application implementation it was set at least somewhat arbitrarily.An evaluation including metrics for the energy efficiency could potentially cometo some quite interesting conclusions by experimenting with different prioritiesalong this balance.

Another primary concern for the solution system is the demarcation of the net-work topology into fragments, as the quality of the demarcation is essential toperformance. Ideally the demarcation should be adapted to each specific sce-nario, taking its unique conditions into account. If the size of the fragments istoo small, meaning every fragment contain too few network nodes, then therewill be a drastic amount of administrative overhead for each fragment relativeto its size. Further there will be significant amounts of traffic as the CTs com-

44

municate with each other, that will cause an exaggerated amount of contentreplication throughout the topology. On the other hand if the size of the frag-ments is too large, meaning every fragment contain too many network nodes,then there will not be very many content replications and the topology willremain at risk of losing content availability in the event of a disaster. Exactlywhat number corresponds to too few or too many nodes is difficult to say butregardless the solution system requires a demarcation that is neither. The frag-ments should be of a size that achieves a balance between the administrativeoverhead and drastic traffic amounts of too small fragments and the insufficientcontent replication of too large fragments. Where this balance is and how toachieve it are critical questions for the solution system and their answers can atthis point only be speculated. However for the solution application developedin this thesis the demarcation is assumed to be not only completed but also of asufficient quality. It is thus not within the scope of this thesis to investigate howto demarcate the topology into fragments. However by considering the networktopology as a graph the demarcation could possibly be done through communitydetection. Community detection is used to identify clusters in a graph, wherevertices of the same cluster are joined by many edges and vertices of differentclusters are joined by comparatively few edges [53]. A cluster is thus a fairlyindependent compartment of a graph [53], very reminiscent of a fragment in thesolution system.

45

Chapter 9

Conclusion

This chapter concludes the thesis by presenting the primary findings before look-ing ahead to what work remains to be done in the future.

While the solution application achieved its primary goal it is important to notdraw too grand conclusions from such a relatively simple implementation andevaluation. However if it was worth the increased cost in energy usage and ad-ministrative overhead is not similarly apparent. Additionally while the solutionapplication performs satisfactorily it is important to remember that it is stillonly one part of a greater solution system and that the the remaining parts arecurrently covered by made assumptions. When and if those assumptions areremoved and the solution system is implemented in its entirety it remains to beseen if the conclusions drawn here will be corroborated or contradicted. Whilethat is an open question, one of several for the young field that is ICN researchefforts, it can for now be said that in the evaluation scenario the solution applica-tion successfully mitigated the decreased content availability caused by networkfragmentation. In the process it did demonstrate that there is potential in us-ing CCN for information retention in fragmented networks. In the evaluationscenario the decreased content availability was limited to a very high degree butif the result would be the same for a complete solution system implementationin a more realistic scenario is yet another open question.

However the answering of these open questions must be left as future work. Theforemost open question is of course to investigate a complete solution systemimplementation, as described in Chapter 5. This investigation would preferablyalso include an evaluation scenario of not only much vaster scope, but also onewhere the topology behaves and changes more like how it realistically should ina disaster scenario by for example having links being disabled as the scenarioelapses. From a grander perspective there is also work left to be done on theICN and CCN level regarding implementing a truly complete and functionalarchitecture. The CCN software used in this thesis is a step in that directionbut still some functionality were left unimplemented, perhaps most notably thelack of non trivial forwarding or routing protocols. Such a complete architecturewill be required before it can be definitely and objectively decided whether ornot ICN should be used for the Internet architecture of the future.

46

Bibliography

[1] B. M. Leiner, V. G. Cerf, D. D. Clark, R. E. Kahn, L. Kleinrock, D. C.Lynch, J. Postel, L. G. Roberts, and S. Wolff, “A brief history of the inter-net,” SIGCOMM Comput. Commun. Rev., vol. 39, pp. 22–31, Oct. 2009.

[2] G. Xylomenos, C. N. Ververidis, V. A. Siris, N. Fotiou, C. Tsilopoulos,X. Vasilakos, K. V. Katsaros, and G. C. Polyzos, “A survey of information-centric networking research,” IEEE Communications Surveys Tutorials,vol. 16, pp. 1024–1049, Second 2014.

[3] B. Ahlgren, C. Dannewitz, C. Imbrenda, D. Kutscher, and B. Ohlman, “Asurvey of information-centric networking,” IEEE Communications Maga-zine, vol. 50, pp. 26–36, July 2012.

[4] K. Pentikousis, B. Ohlman, D. Corujo, G. Boggia, G. Tyson, E. B. Davies,A. Molinaro, and S. Eum, “Information-Centric Networking: Baseline Sce-narios.” RFC 7476, Mar. 2015.

[5] G. Tyson, E. Bodanese, J. Bigham, and A. Mauthe, “Beyond content deliv-ery: can icns help emergency scenarios?,” IEEE Network, vol. 28, pp. 44–49,May 2014.

[6] J. Seedorf, A. Tagami, M. Arumaithurai, Y. Koizumi, N. B. Melazzi,D. Kutscher, K. Sugiyama, T. Hasegawa, T. Asami, K. K. Ramakrishnan,T. Yagyu, and I. Psaras, “The benefit of information centric networking forenabling communications in disaster scenarios,” in 2015 IEEE GlobecomWorkshops (GC Wkshps), pp. 1–7, Dec 2015.

[7] K. Cho, C. Pelsser, R. Bush, and Y. Won, “The japan earthquake: Theimpact on traffic and routing observed by a local isp,” in Proceedings of theSpecial Workshop on Internet and Disasters, SWID ’11, (New York, NY,USA), pp. 2:1–2:8, ACM, 2011.

[8] B. Manoj and A. H. Baker, “Communication challenges in emergency re-sponse,” Commun. ACM, vol. 50, pp. 51–53, Mar. 2007.

[9] D. Guha-Sapir, P. Hoyois, and R. Below, “Annual disaster statistical review2015: The numbers and trends,” tech. rep., Centre for Research on theEpidemiology of Disasters at the Université catholique de Louvain, 2015.

[10] M. Arumaithurai, A. Tagami, K. Ramakrishnan, N. Blefari-Melazzi, andJ. Seedorf, “Using ICN in disaster scenarios,” Internet-Draft draft-irtf-

47

icnrg-disaster-01, Internet Engineering Task Force, Mar. 2017. Work inProgress.

[11] D. R. Cheriton and M. Gritter, “Triad: A scalable deployable nat-basedinternet architecture,” tech. rep., Stanford University, 2000.

[12] A. Ghodsi, S. Shenker, T. Koponen, A. Singla, B. Raghavan, and J. Wilcox,“Information-centric networking: Seeing the forest for the trees,” in Proceed-ings of the 10th ACM Workshop on Hot Topics in Networks, HotNets-X,(New York, NY, USA), pp. 1:1–1:6, ACM, 2011.

[13] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs,and R. L. Braynard, “Networking named content,” in Proceedings of the5th International Conference on Emerging Networking Experiments andTechnologies, CoNEXT ’09, (New York, NY, USA), pp. 1–12, ACM, 2009.

[14] D. Kutscher, S. Eum, K. Pentikousis, I. Psaras, D. Corujo, D. Saucez,T. C. Schmidt, and M. Wählisch, “Information-Centric Networking (ICN)Research Challenges.” RFC 7927, July 2016.

[15] D. Trossen, M. J. Reed, J. Riihijärvi, M. Georgiades, N. Fotiou, and G. Xy-lomenos, “Ip over icn - the better ip?,” in 2015 European Conference onNetworks and Communications (EuCNC), pp. 413–417, June 2015.

[16] L. Zhang, A. Afanasyev, J. Burke, V. Jacobson, k. claffy, P. Crowley, C. Pa-padopoulos, L. Wang, and B. Zhang, “Named data networking,” SIGCOMMComput. Commun. Rev., vol. 44, pp. 66–73, July 2014.

[17] H. Jeon, B. Lee, and H. Song, “On-path caching in information-centricnetworking,” in 2013 15th International Conference on Advanced Commu-nications Technology (ICACT), pp. 264–267, Jan 2013.

[18] G. Tyson, N. Sastry, I. Rimac, R. Cuevas, and A. Mauthe, “A survey of mo-bility in information-centric networks: Challenges and research directions,”in Proceedings of the 1st ACM Workshop on Emerging Name-Oriented Mo-bile Networking Design - Architecture, Algorithms, and Applications, NoM’12, (New York, NY, USA), pp. 1–6, ACM, 2012.

[19] Y. Luo, J. Eymann, and A. Timm-Giel, “Mobility support for content cen-tric networking,” Telecommunication Systems, vol. 59, no. 2, pp. 271–288,2015.

[20] P. Mahadevan, E. Uzun, S. Sevilla, and J. Garcia-Luna-Aceves, “Ccn-krs:A key resolution service for ccn,” in Proceedings of the 1st ACM Conferenceon Information-Centric Networking, ACM-ICN ’14, (New York, NY, USA),pp. 97–106, ACM, 2014.

[21] A. Meissner, T. Luckenbach, T. Risse, T. Kirste, and H. Kirchner, “De-sign challenges for an integrated disaster management communication andinformation system,” in DIREN 2002 - 1st IEEE Workshop on DisasterRecovery Networks; New York, 2002, 2002.

[22] J. S. Huang and Y. N. Lien, “Challenges of emergency communication net-work for disaster response,” in 2012 IEEE International Conference onCommunication Systems (ICCS), pp. 528–532, Nov 2012.

48

[23] P. Rawat, M. Haddad, and E. Altman, “Towards efficient disaster manage-ment: 5g and device to device communication,” in 2015 2nd InternationalConference on Information and Communication Technologies for DisasterManagement (ICT-DM), pp. 79–87, Nov 2015.

[24] U. Lee, I. Rimac, and V. Hilt, “Greening the internet with content-centricnetworking,” in Proceedings of the 1st International Conference on Energy-Efficient Computing and Networking, e-Energy ’10, (New York, NY, USA),pp. 179–182, ACM, 2010.

[25] X. Liu, Z. Li, P. Yang, and Y. Dong, “Information-centric mobile ad hocnetworks and content routing: A survey,” Ad Hoc Networks, vol. 58, pp. 255– 268, 2017. Hybrid Wireless Ad Hoc Networks.

[26] J. Seedorf, D. Kutscher, and F. Schneider, “Decentralised binding of self-certifying names to real-world identities for assessment of third-party mes-sages in fragmented mobile networks,” in 2014 IEEE Conference on Com-puter Communications Workshops (INFOCOM WKSHPS), pp. 416–421,April 2014.

[27] L. Torgerson, S. C. Burleigh, H. Weiss, A. J. Hooke, K. Fall, D. V. G. Cerf,K. Scott, and R. C. Durst, “Delay-Tolerant Networking Architecture.” RFC4838, Apr. 2007.

[28] D. Camara, C. Bonnet, and F. Filali, “Propagation of public safety warningmessages: A delay tolerant network approach,” in 2010 IEEE WirelessCommunication and Networking Conference, pp. 1–6, April 2010.

[29] G. Tyson, J. Bigham, and E. Bodanese, “Towards an information-centricdelay-tolerant network,” in 2013 IEEE Conference on Computer Commu-nications Workshops (INFOCOM WKSHPS), pp. 387–392, April 2013.

[30] S. Y. Oh, D. Lau, and M. Gerla, “Content centric networking in tacticaland emergency manets,” in 2010 IFIP Wireless Days, pp. 1–5, Oct 2010.

[31] J. Chen, M. Arumaithurai, L. Jiao, X. Fu, and K. K. Ramakrishnan,“Copss: An efficient content oriented publish/subscribe system,” in 2011ACM/IEEE Seventh Symposium on Architectures for Networking andCommunications Systems, pp. 99–110, Oct 2011.

[32] S. Kim, Y. Urata, Y. Koizumi, and T. Hasegawa, “Power-saving ndn-basedmessage delivery based on collaborative communication in disasters,” inThe 21st IEEE International Workshop on Local and Metropolitan AreaNetworks, pp. 1–6, April 2015.

[33] T. Yagyu, K. Nakamura, T. Asami, K. Sugiyama, A. Tagami, T. Hasegawa,and M. Arumaithurai, “Demo: Content-based push/pull message dissemi-nation for disaster message board,” in Proceedings of the 2Nd ACM Confer-ence on Information-Centric Networking, ACM-ICN ’15, (New York, NY,USA), pp. 205–206, ACM, 2015.

[34] K. Sugiyama, A. Tagami, T. Yagyu, T. Hasegawa, M. Arumaithurai, andK. K. Ramakrishnan, “Multipath support for name-based information dis-semination in fragmented networks,” in Proceedings of the 2Nd ACM Con-

49

ference on Information-Centric Networking, ACM-ICN ’15, (New York,NY, USA), pp. 201–202, ACM, 2015.

[35] J. Seedorf, D. Kutscher, and B. S. Gill, “Decentralised interest counter ag-gregation for icn in disaster scenarios,” in 2016 IEEE Globecom Workshops(GC Wkshps), pp. 1–6, Dec 2016.

[36] T. Hossmann, P. Carta, D. Schatzmann, F. Legendre, P. Gunningberg, andC. Rohner, “Twitter in disaster mode: Security architecture,” in Proceedingsof the Special Workshop on Internet and Disasters, SWID ’11, (New York,NY, USA), pp. 7:1–7:8, ACM, 2011.

[37] T. Ogawara, Y. Kawahara, and T. Asami, “Information dissemination per-formance of a disaster-tolerant ndn-based distributed application in dis-rupted cellular networks,” in IEEE P2P 2013 Proceedings, pp. 1–5, Sept2013.

[38] E. Nordström, C. Rohner, and P. Gunningberg, “Haggle: Opportunisticmobile content sharing using search,” Computer Communications, vol. 48,pp. 121 – 132, 2014. Opportunistic networks.

[39] J. Chen, M. Arumaithurai, X. Fu, and K. K. Ramakrishnan, “Cns: Content-oriented notification service for managing disasters,” in Proceedings of the3rd ACM Conference on Information-Centric Networking, ACM-ICN ’16,(New York, NY, USA), pp. 122–131, ACM, 2016.

[40] I. Psaras, L. Saino, M. Arumaithurai, K. K. Ramakrishnan, and G. Pavlou,“Name-based replication priorities in disaster cases,” in 2014 IEEE Con-ference on Computer Communications Workshops (INFOCOM WKSHPS),pp. 434–439, April 2014.

[41] E. Monticelli, B. M. Schubert, M. Arumaithurai, X. Fu, and K. K. Ramakr-ishnan, “An information centric approach for communications in disastersituations,” in 2014 IEEE 20th International Workshop on Local Metropoli-tan Area Networks (LANMAN), pp. 1–6, May 2014.

[42] T. Yagyu and S. Maeda, “Demo overview: Reliable contents retrieval infragmented icns for disaster scenario,” in Proceedings of the 1st ACM Con-ference on Information-Centric Networking, ACM-ICN ’14, (New York,NY, USA), pp. 193–194, ACM, 2014.

[43] V. Sourlas, L. Tassiulas, I. Psaras, and G. Pavlou, “Information resiliencethrough user-assisted caching in disruptive content-centric networks,” in2015 IFIP Networking Conference (IFIP Networking), pp. 1–9, May 2015.

[44] M. Amadeo, C. Campolo, and A. Molinaro, “Multi-source data retrieval iniot via named data networking,” in Proceedings of the 1st ACM Conferenceon Information-Centric Networking, ACM-ICN ’14, (New York, NY, USA),pp. 67–76, ACM, 2014.

[45] C. Anastasiades, T. Schmid, J. Weber, and T. Braun, “Information-centriccontent retrieval for delay-tolerant networks,” Computer Networks, vol. 107,Part 2, pp. 194 – 207, 2016. Mobile Wireless Networks.

50

[46] M. Lee, J. Song, K. Cho, S. Pack, T. T. Kwon, J. Kangasharju, and Y. Choi,“Content discovery for information-centric networking,” Comput. Netw.,vol. 83, pp. 1–14, June 2015.

[47] L. Wang, S. Bayhan, J. Ott, J. Kangasharju, A. Sathiaseelan, andJ. Crowcroft, “Pro-diluvian: Understanding scoped-flooding for content dis-covery in information-centric networking,” in Proceedings of the 2Nd ACMConference on Information-Centric Networking, ACM-ICN ’15, (New York,NY, USA), pp. 9–18, ACM, 2015.

[48] O. Ascigil, V. Sourlas, I. Psaras, and G. Pavlou, “Opportunistic off-pathcontent discovery in information-centric networks,” in 2016 IEEE Interna-tional Symposium on Local and Metropolitan Area Networks (LANMAN),pp. 1–7, June 2016.

[49] C. Anastasiades, A. Sittampalam, and T. Braun, “Content discovery inwireless information-centric networks,” in 2015 IEEE 40th Conference onLocal Computer Networks (LCN), pp. 28–36, Oct 2015.

[50] K. Peffers, T. Tuunanen, M. A. Rothenberger, and S. Chatterjee, “A designscience research methodology for information systems research,” Journal ofManagement Information Systems, vol. 24, no. 3, pp. 45–77, 2007.

[51] A. Georges, D. Buytaert, and L. Eeckhout, “Statistically rigorous java per-formance evaluation,” SIGPLAN Not., vol. 42, pp. 57–76, Oct. 2007.

[52] K. Pentikousis, B. Ohlman, E. B. Davies, G. Boggia, and S. Spirou,“Information-Centric Networking: Evaluation and Security Considera-tions.” RFC 7945, Sept. 2016.

[53] S. Fortunato, “Community detection in graphs,” Physics Reports, vol. 486,no. 3–5, pp. 75 – 174, 2010.

51

www.kth.se