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

, STOCKHOLM SWEDEN 2017

Information retentionfor disaster-stricken networksusing Content Centric Networking

ELIAS ANDERSSON

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF COMPUTER SCIENCE AND COMMUNICATION

Information retention for 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 at CSC was Johan Håstad.

Commissioner was Ericsson.Supervisor at Ericsson was Adeel Mohammad Malik.

2017-07-02.

Information retention for disaster-stricken networksusing Content Centric Networking

Abstract

The underlying architecture of the Internet has been mostly the samesince its 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 to thischange in usage, intended to be more prepared to handle the new require-ments of the Internet not only today but also in the future. The primaryconcern in ICN is the secure and efficient distribution of content. CurrentICN research often concerns applications on various disaster scenarios asit is believed that ICN has properties that match the requirements ofsuch scenarios. In this thesis that research is continued by developingan especially designed information retention solution, using the existingICN implementation of Content Centric Networking (CCN). The aim is tomaximisise and prolong the availability of as much content as possible indisaster-stricken networks by preemptively replicating content across thenetwork topology. The solution is then evaluated against a scenario set ina network topology consisting of virtual machines. The final result is thatthe solution performs satisfactorily and thus demonstrate the potential ofICN when applied to such scenarios.

Informationsbevarande för katastrofdrabbade nätverkgenom Content Centric Networking

Referat

Internets underliggande arkitektur har varit i stort sett oförändrad sedansin begynnelse på 1960-talet, och TCP/IP protokollstacken är fortsatt uni-versell. Dock så används Internet idag för betydligt bredare ändamål ände ursprungliga syftena, och nu används Internet främst för att distribue-ra olika former av innehåll. Information Centric Networking (ICN) är enalternativ arkitektur som svarar på denna förändring i använding, avseddatt vara mer förberedd att hantera de nya kraven på Internet inte baraidag men också i framtiden. Den största angelägenheten i ICN är att dis-tribuera innehåll på ett säkert och effektivt vis. Nuvarande forskning inomICN handlar ofta om tillämpningar på olika sorters katastrofscenarier dåtron är att ICN har egenskaper som motsvarar kraven hos sådana scena-rier. I den här uppsatsen fortsätts denna forskning genom att en specielltformgiven informationsbevaringslösning utvecklas, som nyttjar den existe-rande ICN-implementationen Content Centric Networking (CCN). Måletär att maximera och förlänga tillgängligheten av så mycket innehåll sommöjligt i katastrofdrabbade nätverk genom att i förebyggande syfte re-plikera innehåll genom nätverkstopologin. Lösningen evalueras sedan motett scenario som utspelas i en nätverkstopologi utav virtuella maskiner.Det slutgiltiga resultatet är att lösningen presterar tillfredsställande ochpå så vis demonstrerar potentialen hos ICN vid tillämpning på sådanascenarion.

Preface

This thesis constitutes the final project for my degrees in both Degree Pro-gramme in Computer Science and Engineering (Civilingenjörsutbildning i da-tateknik) and Master’s Programme in Computer Science at KTH. It has beena both educational end entertaining experience that I have very much appreci-ated.

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.

Börje Ohlman, for giving me the opportunity to perform my thesis project atEricsson.

Adeel Mohammad Malik, for being my supervisor at Ericsson and providingtechnical guidance.

The rest of the team at Ericsson, for the welcoming atmosphere and pleas-ant work environment.

Elias AnderssonStockholm, June 2017

Contents

Glossary 1

1 Introduction 51.1 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 Contribution and objective . . . . . . . . . . . . . . . . . . . . . 7

2 Background 92.1 Information Centric Networking . . . . . . . . . . . . . . . . . . . 92.2 Content Centric Networking . . . . . . . . . . . . . . . . . . . . . 102.3 Network requirements in a disaster . . . . . . . . . . . . . . . . . 132.4 ICN in disaster-stricken networks . . . . . . . . . . . . . . . . . . 15

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

4 Methodology 20

5 Design 225.1 The solution system . . . . . . . . . . . . . . . . . . . . . . . . . 225.2 Delimitations and assumptions . . . . . . . . . . . . . . . . . . . 245.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6 Implementation 276.1 The CCNx codebase . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.1.1 The Metis forwarder . . . . . . . . . . . . . . . . . . . . . 276.1.2 Addition to Metis . . . . . . . . . . . . . . . . . . . . . . 30

6.2 The solution application . . . . . . . . . . . . . . . . . . . . . . . 326.2.1 Publishing content . . . . . . . . . . . . . . . . . . . . . . 336.2.2 On a node . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.2.3 On a Content Tracker . . . . . . . . . . . . . . . . . . . . 356.2.4 Retransmissions . . . . . . . . . . . . . . . . . . . . . . . 36

7 Evaluation 387.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

8 Discussion 438.1 Comparison against requirements . . . . . . . . . . . . . . . . . . 438.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448.3 Energy efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . 458.4 Fragment demarcation . . . . . . . . . . . . . . . . . . . . . . . . 458.5 Possible improvements . . . . . . . . . . . . . . . . . . . . . . . . 46

9 Conclusion 48

Bibliography 50

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 incorporates both CCN and the CCNx codebase byPARC, after they were acquired by Cisco.

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. The Content Trackers then synchronisethis content with their neighbours, thereby replicating it.

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 witheach other, without the traffic passing through the core network.

1

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

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 in TCP/IP.

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 the faces leading to a next hop on the pathtoward a publisher.

Frag-mented

A network is fragmented if previously connected network sectionshas become disconnected through failures or disruptions on thelinks between them. Each such disconnected section is then re-ferred to as a fragment.

ICN Information Centric Networking. A paradigm for an alternativeInternet architecture currently being investigated in the researchcommunity. Its fundamental purpose is to enable efficient andsecure distribution of NDOs.

Interest One of the two primary packet types 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.

2

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

NDN Named Data Networking. A project following the ICN paradigm,originally forked from the CCN 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 for managing publickey encryption 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 travel the same path as the original In-terest packet but in the reverse direction, by consuming state leftbehind by the Interest in the PITs of intermediate routers. 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. A protocol in the Internet protocolsuite, located on the transport layer. It is connectionless and,while it does provide data integrity, there are no guarantees fordelivery, ordering or duplicate protection.

Quality ofService

Also known as QoS. The overall performance of a network, par-ticularly the performance seen by the users of the network.

3

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

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 contribution and objective of the thesis within that domain as wellas the underlying motivation.

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 considerably 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 many other forms of data [3]. On a more ab-stract level pieces of content can in this context be said to refer to any arbitraryinformation. 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). It is a paradigmfor a new Internet architecture and its primary objective is to enable efficientand secure distribution of content. This drastically differentiates it from theclassic TCP/IP architecture 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? ” asin TCP/IP. The ambition behind ICN is for it to 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 disaster

5

scenarios. Emergency support and disaster recovery is in fact one of the sce-narios suggested to be considered in performance evaluation studies of ICNapproaches [4]. In a disaster scenario the requirements put on a communica-tion network, such as the Internet, differ quite significantly from those duringnormal operations. It is believed that ICN, due to its content-centric nature,could be beneficial when responding to these requirements [5][6]. The severeconsequences of a disaster were illustrated by the earthquake and subsequenttsunami that in 2011 struck the Tohoku region on the northeast coast of Japan.Over 15,000 lives were lost and the affected coastal areas were devastated. Thedevastation included a nuclear crisis in Fukushima [6], multiple fires [6] and theloss of electricity for around 4.4 million households [7]. In addition to theseterrible 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 disaster.The number of such natural disasters has increased during the last decades [5].In 2015 the total number of people affected by natural disasters planetwide wasjust over 110 million with an estimation for the total economical cost beingapproximately US $70 billion [9]. In addition to natural disasters such as earth-quakes, tsunamis and hurricanes there are also human-generated disasters. Forthese there is a distinction between accidental, such as major industrial acci-dents, 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 originatingfrom one such fragment would no longer be available to hosts in the other frag-ments.

1.1 Problem statement

The need for a high performance communication network in disaster scenar-ios and the hope that ICN could make the Internet satisfactorily answer thatneed, creates the problem domain considered in this thesis. The overarchingpurpose of this thesis is captured by an ambition to investigate to what degreeICN can improve communications when applied to disaster-stricken networks.This is a wide ambition and the contribution made in this thesis is an approachfocusing on mitigating the negative effects of any network fragmentation. Theproblem statement devised from this is contained in the following research ques-tion:

6

“To what degree can ICN be used to mitigate the decreased contentavailability caused by network fragmentation in disaster-stricken net-works? ”

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 are featured so heavily inthe current 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 to thepublic. In this way applying ICN could potentially lead to benefits for society,from ethical and social perspectives. Furthermore, achieving good communi-cation performance in disaster scenarios would act as a demonstration of thepotential of ICN as a a paradigm and as a possible replacement for TCP/IP [4],as it is an important application for any candidate for the future Internet ar-chitecture.

1.3 Contribution and objective

This thesis was conducted with support from the Swedish communications tech-nology company Ericsson, which provided the working environment, technicalguidance on the ICN paradigm and the initial problem domain. Ericsson as acompany strives to maintain sustainability and corporate responsibility through-out its operations. One part of that is the Ericsson Response program1 which isa voluntary effort to help establish and maintain connectivity in areas affectedby a disaster. The belief is that an ICN solution could act as a complementto the already existing Ericsson response solutions, by preemptively and proac-tively mitigating the negative consequences caused by network fragmentation ina 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 as much information, inthe form of content availability, as possible for as long as possible in a disaster-stricken network. The system would achieve this by identifying, through demar-cation, how the network would most likely fragment in the event of a disaster,and then proactively replicate content across these potential fragments while thelinks are still functioning reliably. Storing the content in multiple fragments inthis fashion would mitigate the decreased content availability following any frag-mentation as each fragment would contain a separate copy of the content.

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

7

The aim for this thesis is for it to provide a contribution regarding the design,implementation and evaluation of such a system. Doing so would in the processalso constitute a contribution to the currently very active ICN research field.Further, the design should preferably leverage the content-centric property ofICN to a level which much of the previous work in the area has not yet done.As for the evaluation it should preferably serve as a demonstration of the valueof ICN as a paradigm by considering conditions that elucidate the system’scapabilities regarding information retention. A system with a purpose of thismagnitude unavoidably becomes quite ambitious in scope. Therefore the scopeof this thesis is limited to considering the content replication aspect, as describedin more detail in Section 5.2. The final, more concrete, objective of the thesiscan hence be summarised as designing, implementing and evaluating the contentreplication functionality of the designed information retention system.

The design of the developed system is described in depth in Chapter 5, whichalso includes detailed descriptions of the made delimitations and assumptions.Following that the implementation and evaluation of the resulting applicationare then described in Chapter 6 and Chapter 7 respectively.

8

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 [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 its source, creating so called NamedData Objects (NDOs) [3]. An NDO is simply a piece of content with anassociated name, which then uniquely identifies that content in the globalscope. As the name of a piece of content remains the same no matterwhere it is actually located NDOs are thus completely independent fromthe location, or locations, where they are hosted or stored in the network.This is in contrast with TCP/IP where the addressing primitives are thehosts in the network.

• 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 with TCP/IP [13]. In TCP/IP security is the responsibility ofthe communicating end points and content security is achieved throughsecuring the channel that the content is transmitted over. In ICN on theother hand, every piece of content is intrinsically and permanently boundwith security features from its publisher, but exactly what those security

9

features entail differs among the different ICN projects. This means thatin ICN secure content can be transmitted over insecure or untrusted net-work sections without any issues. Further it does not matter which devicein the network that answers a content request. As long as the device hasthe requested content it can reply, regardless of its relationship with theoriginal publisher. Finally the consumer verifies the content when it isreceived. Trust in content is thus based on trust in the original publisher,rather than which specific host the content was delivered from.

• Universal caching. Due to the significantly diminished cost and subsequentincreased availability of memory and computing power it is today feasibleto have content caches at every node in the network. In the 1960s or 1970sthis was practically impossible since both memory and computing powerwere much scarcer resources. In ICN any node can store any contentfrom any source in its cache and subsequently respond to requests for thatcontent. This enables fast content access reminiscent of today’s CDNs orP2P networks, but as an intrinsic part of the network architecture availablefor 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 benefits inTCP/IP in order to improve the 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

As mentioned earlier Content Centric Networking (CCN) in one project thatfollows the ICN paradigm. It was originally started at the Palo Alto ResearchCenter (PARC), a research and development company based out of the US stateof California that is perhaps otherwise mostly known for its early work on theEthernet, GUIs and other IT developments. Currently the CCN approach is be-ing continued by for example the Named Data Networking (NDN) project [3][16]and the Community Information Centric Networking (CICN) project at Cisco.In CCN communication is driven by the consumers of data, with publishersmaking that data available for access in the form of content. In CCN there aretwo primary packet types: Interest and Data. Consumers first use an Interestpacket in order to request some content and the publisher then delivers thatcontent, in the form of a Content Object, in a Data packet [13]. Content Objectis the CCN specific term for the generic ICN NDO.

10

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 projectswhich 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). It is the forwarding table. In CCNthe FIB operates similarly to the FIB of a TCP/IP router, hence theidentical name. It maps Content Objects, represented by their names,to network interfaces. A selected network interface leads to a next hoptoward one publishing location for the content matching that particularname. In CCN terminology interfaces are simply referred to as faces [3].The primary difference when compared to the FIB of TCP/IP is the factthat CCN supports multi-sourcing. In CCN each FIB entry can mapa single Content Object to multiple faces, as the same content can bepublished at multiple network locations. How to populate the FIB is animportant problem and a common suggestion is to use a routing protocol,much like how it is done in TCP/IP. When there are multiple alternativefaces to choose from for a Content Object a forwarding strategy determinesto which face, or faces, the Content Object should be forwarded.

• Pending Interest Table (PIT). The PIT stores state about forwarded In-terests in the form of a map, which maps Content Objects to faces fromwhich Interests for that Content Object has been received. Similarly tothe FIB, the Content Objects are once again represented by their names.Content Objects are not routed from the publisher to the consumer, theyinstead travel the same path as the initial Interest, but in the reverse di-rection, by consuming the state left behind by the initial Interest in thePIT at each passed hop. This is called the reverse request path. The statestored in the PIT thus serves as a breadcrumb for the Content Object tofollow as it travels toward the consumer.

• 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 intermediate 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 routers

11

doing request aggregation. If a CCN router receives a second Interest for aspecific Content Object before the first Interest has been satisfied there willalready be an entry in the PIT for that name. The only actions required arethen to add the face that the second Interest was delivered on to the mappingof the PIT entry (if it is not there already) and then finally to drop the Interest.Because of this routing CCN is not concerned with preventing loops which arevery troublesome 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 adifferent section and continue operating as if nothing changed. For publishersit is not so simple because changing the network location requires updating theFIB entries of affected network routers so that they refer toward the new lo-cation. This problem is however mitigated somewhat by the support in CCNfor multi-sourcing [18][19]. By using a routing protocol it can take significantamount of time for the FIBs to reconverge to address network topology changes.This has lead to alternative proposals for managing this mobility issue, includ-ing introducing temporary names and proactively updating FIB entries [19].Since hosts are not used in the routing process it is also difficult to disrupt aservice provided by any specific device or devices by using a Denial-of-Service(DoS) attack. However devices could instead be vulnerable against Interestflooding.

In CCN content security is 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 specifically for this purpose,providing yet another alternative.

As is evident 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

12

Figure 1: An overview of the relationships 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 net-work to become fragmented [6]. The fragments are then forced to rely on datamules physically carrying traffic to the outside for communication, most likelydisconnecting network devices from any centralised services. A data mule canfor example be an ambulance, a drone or even a moving person carrying a hand-held device. In a fragmented network establishing end-to-end communication isunreliable at best and unfeasible at worst. The potential dependency on datamules means delay tolerance becomes a key property [6], as significant amountsof time can pass between contest requests and contest replies. The networkfragmentation also makes it preferable for any security solution to be as decen-tralised as possible. Additionally, while security is always a primary concern forany network operating under any conditions, it is potentially even more essen-tial in a disaster scenario where erroneous or malicious content can make thedifference in life or death situations.

13

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 two are applicable for end users and the remaining five areapplicable for operators.

End user requirements:

• 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.

Operator requirements:

• 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 acquire.

• Capacity. There is a significant amount 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.

14

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 certainhosts 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. Due to ICN being content-centricit is straightforward to use data mules for communication between networkfragments [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 or simi-lar. If this mapping is done by a DNS style system then that raises concerns assuch a solution is quite centralised. The problem of the routing plane having toreconverge every time the network topology changes also remains in ICN. Ad-ditionally communication is in most ICN projects by default pull-based, whereusers request desired content. This is useful in the sense that it gives users con-trol over how and when communication is done and thus by extension over theenergy usage [5]. It is also, however, limiting as in a disaster scenario importantcommunication, like warnings or instructions from authorities, is often push-based. While ICN having security on individual content makes decentralisedsolutions feasible [10], the security of content is still a concern. This is becausemany of the established solutions, such as centralised authentication entitiesand Web of Trust (WoT) keyservers, are highly centralised [26].

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 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 themassive 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). In general, the twoprinciples complement each other as ICN fundamentally provides informationresilience while DTN fundamentally provides connectivity resilience [4].

16

3.2 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 not consideredaspects. In general the ICN paradigm and its associated research efforts are bothrelatively young, which is illustrated by this general lack of complete solutions.For example there are papers in a disaster scenario context concerning securityas in [26], communication schemes as in [30][31][32][33][34][35] and applicationsdesigned specifically to take advantage of the ICN principles and propertiesas in [36][37][38][39]. What these papers share with this thesis is primarilythe disaster scenario angle, making them tangentially relevant. However thereare further works in the disaster scenario area that are highly relevant whenconsidered from the perspective of trying to achieve information retention fordisaster-stricken networks.

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 does 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 anassigned 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: establishing theroute 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 retrieval

17

in 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.3 Information discovery and retrieval

In order to achieve information retention in fragmented networks it can be use-ful to have solutions for content discovery and content retrieval. These are twobroad terms concerning schemes for learning what content is available in thenetwork and how to retrieve it respectively. In the context of information reten-tion in disaster scenarios content discovery can be used to learn what content isavailable in each fragment while content retrieval can be used to replicate con-tent across the fragments. There have been papers written on content retrievalin ICN including [44][45] and the work by Yagyu and Maeda [42] mentionedearlier.

Likewise there are also papers on content discovery in ICN, as in [46][47][48].In one such paper relevant for this thesis Anastasiades, Sittampalam andBraun [49] investigate three different algorithms for supporting opportunisticcontent discovery based on broadcast requests in wireless networks with a brokenfixed infrastructure, specifically intended for disaster scenarios. The networktopology is represented as a graph and the three algorithms are based on BreadthFirst Search (BFS), Depth First Search (DFS) and a hybrid of the two. Thediscovered topology of content is then stored on the node that initiated thediscovery process. In the evaluation, which covers both flat and hierarchicalnamespaces, the hybrid algorithm achieves the best overall performance.

3.4 Research gap

The solutions designed for disaster scenarios that achieve some form om infor-mation retention primarily do so by using some form of routing [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 other events that results in

18

similarly high amounts of traffic. Therefore the aim is for the solution developedduring this thesis to move away from being heavily reliant on either routing orhigh amounts of traffic. Instead the idea is to more reliably achieve this func-tionality by leveraging the content-centricity of ICN to a higher degree and byoperating in a more ad hoc manner and consequently hopefully reach greaterlevels of performance. Likewise much of the previous works are set during orafter the disaster. This thesis instead focuses on preemptive efforts that willmitigate the negative consequences of a disaster if and when it occurs, allowingthe solution to utilise all networks links while they are still functioning reli-ably.

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 manyof the existing solutions make incompatible assumptions and delimitations andare therefore not directly applicable. Additionally, they are often quite ambi-tious in scope and approach problems deemed out of scope for this thesis, whichmeans that much of the functionality that they implement can be regarded assuperfluous for the considered problem. A further side effect of this is that theybecome increasingly complex, but when dealing with situations as unreliableand unpredictable as disaster scenarios it is often preferable to maintain sim-plicity and to be dependent on as few assumptions as possible. Much of theresearch is also still on a general ICN level rather than focusing specifically onany one specific ICN project, such as CCN, which is the one being consideredin 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 designing, implementing and evaluating certain functionality of sucha system.

19

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 is performed in a struc-tured and scientific manner, the used methodology is inspired primarily by theDesign Science Research Methodology (DSMR) presented by Peffers et al. intheir article A Design Science Research Methodology for Information SystemsResearch [50]. DSMR incorporates principles, practices and procedures requiredfor conducting research in information systems that attempts to create resultsserving human purposes. This is both appropriate and applicable given thatthe nature of the work conducted as a part of this thesis is highly developmentoriented, since the primary result produced is a solution artefact. DSMR coversthe entire process for developing the solution artefact, from beginning to end.It consists of a total of six steps in a nominally sequential order:

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.

20

The work process behind this thesis largely follows DSMR as it has been de-scribed here. Using such an established approach ensures a methodology ofsufficient scientific and academic standard.

The first step is to identify and motivate the considered problem, as presentedin Chapter 1. Secondly, the objectives for the desired solution system to thechosen problem are inspired by the requirements of a disaster-stricken network,as they were described in Section 2.3.

However the objectives inevitably had to be adapted toward the fact that dueto the ambitious scope of the considered problem a thesis could only reasonablyand feasibly approach part of the entire imagined solution system. For thesake of feasibility a delimitation is made that restricts the final solution artefactproduced in this thesis to a solution application, responsible only for the contentreplication aspects of the greater solution system. However, again for the sakeof feasibility, the designed solution application is also limited to a Proof ofConcept (PoC) level scope. The final objectives of the solution application aredescribed in Section 5.3. Following that, the solution application is implementedon top of an existing CCN codebase which provided the required underlyingnetwork functionality. Then the implementation of the solution application isboth demonstrated and evaluated, as described by the DSMR methodology, byrunning it on a network topology consisting of several virtual machines (VMs).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 bynetwork fragmentation 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 functionality of solutionsystem and is of a mostly practical implementation nature.

21

Chapter 5

Design

This chapter details the design of the system solution, describing its architectureand functionality. It also covers delimitations, assumptions and the resultingsolution application with its associated requirements.

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. The first step in the processis to investigate how the network will most likely fragment in the event of adisaster and thus identify the potential future network fragments. Afterwardscontent is proactively replicated across these fragments and stored at strategiclocations. If connectivity deteriorates to the point of fragmentation then theambition is that each fragment will already have separate copies of as muchcontent as possible. If that is the case, then an increased amount of contentremains accessible for the nodes in 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, which maps names of content to nodes inthe fragment that publishes that content. The CT and the other nodes inthe same fragment then communicate periodically in order to update thecontent map to reflect changes in available content

22

4. CTs periodically compare available content with neighbouring CTs so thatthe CT of every fragment can eventually learn what content is available inthe other fragments. Two CTs are considered to be neighbours if any nodein one of the fragments is connected to any node in the other fragment.During these comparisons, if a CT notices that one of its neighbours con-tains content it itself is missing, the CT will request such content from itsneighbour. In that way content is proactively replicated to more and morefragments and eventually it will propagate throughout the 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 communi-cating with other nodes in the network. This communication over the networkis achieved using an existing CCN codebase, namely the CCNx codebase ofCisco’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.

23

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 is that the solution application developed as partof this thesis is limited to a PoC level scope, as its purpose is not to provide aperfect implementation but more accurately to investigate the potential of thesolution system. The most significant delimitation made is 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 is no concern of any possiblefollower application with dependencies. Another significant delimitation is thatno expectation is placed on the solution application being able to handle inputand output simultaneously as such a feature would require threading, whichfor the sake of time is deemed to be outside of the focus area of this thesis.A further delimitation is that only pieces of content that can fit into a singleCCN Content Object, as supported by the existing CCNx codebase, are handled

24

for replication across fragments. The reasoning behind this is again that theproblem of splitting a single piece of content into several smaller pieces and thenreassembling them at the receiver is not within the focus of this thesis. Ratherit is judged to be 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 namespace, whichotherwise is global, for other users or services in 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 run 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 topology have been demarcated into potential fragments inan appropriate 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 have FIB entries leading toward the CTof that fragment. This means that nodes can send Interest messages totheir CT, which can then respond with Content Objects on the reverserequest path.

• 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. Additionally the requirement level wasadapted due to feasibility concerns, as the corresponding solution applicationwas intended to be on a PoC level. The result was a selection of requirementsdeemed appropriate for the imagined solution application while also maintain-ing feasibility within the scope of a master’s thesis. The primary aim was for

25

the requirements to enable both satisfactory performance and a sufficient eval-uation. The final list of requirements was thus concretised into the followingitems:

• The application should implement its assigned part of the solution system,as specified by the delimitations. Further it should operate on a best effortbasis while leveraging the content-centricity of ICN and CCN as much aspossible. Its primary purpose should be to achieve information retentionby replicating all available content to at least one network node in eachfragment.

• 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 fail to replicate an unreasonable amount ofcontent.

• The application should not need an unreasonable amount of time to dothe content replication.

• The application should not cause an unreasonable amount of network traf-fic.

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 still sufficient for concluding whether or not the solution application has anypotential in achieving information retention. In fact, any requirements includinga more specific performance milestone remain unfeasibly elusive as they wouldbe very scenario dependent. Additionally formulating them properly would re-quire knowledge of results such as those that are aimed to be achieved in thisvery thesis. This is because it is very challenging to reasonably set the bar forperformance before really knowing what is and what is not actually feasible.As such these five requirements together enable an investigation of feasibility,from which in turn the level of potential for information retention can be de-duced.

26

Chapter 6

Implementation

This chapter covers the development done as part of this thesis, describing boththe Metis forwarder and the solution application itself as well as how they in-teract.

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 Commu-nity Information Centric Networking (CICN) effort. Cisco has since then madeadditions to the codebase but much of the original code remains, including alibrary containing general utilities and data structure implementations for the Cprogramming language. Many of the data structures of this library are inspiredby classes of Java and provide similar functionality, for example analogues tothe String, ArrayList and HashMap classes.

6.1.1 The Metis forwarder

While this library is a convenient resource the most important part of the CCNxcodebase, in the context of this thesis, is the Metis CCN forwarder. Metishas the functionality of a CCN router, in the form of an independent daemonprocess. Through a provided API it enables applications to send messagesto each other over a network, exactly as described in Section 5.1. Metis canbe 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 message

27

is 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 Metisvia 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 that the local node is connected to. Nexttwo connections are specified, meaning that this particular node is connected totwo other 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 want

28

forwarded 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 CCNmessages 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 ) ;27 i f (msg != NULL) {28 i f ( ccnxMetaMessage_IsInterest (msg ) ) {29 CCNxInterest ∗ i n t e r e s t ;30 i n t e r e s t = ccnxMetaMessage_GetInterest (msg ) ;31 i f ( i n t e r e s t != NULL) {32 hand le_inte re s t ( porta l , i n t e r e s t ) ;33 }34 }35 ccnxMetaMessage_Release(&msg ) ;36 }37 }3839 ccnxName_Release(&name ) ;40 ccnxPortal_Release(&po r t a l ) ;41 parc Ident i ty_Release (& i d en t i t y ) ;42 parcSecur i ty_Fin i ( ) ;4344 re turn 0 ;45 }

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

29

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.

6.1.2 Addition to Metis

The Metis forwarder itself is in this thesis used as it was originally provided, withone single addition being the only exception. In order for the imagined solutionapplication to function properly, as described in more detail in Section 6.2,bidirectional communication must be possible between any CT and the nodesof its fragment. Note that the assumptions specified in Section 5.2 only cover thedirection going from any of the nodes toward the CT, as the corresponding FIBentries are assumed to exist. Such FIB entries are of the structure ccnx:/fragXwhere X is the fragment ID of the fragment in question. The CT of the fragmentwith the fragment ID X will then listen to this name and thus be able to respondto any node communicating with it. This means a node can immediately sendmessages, for example Interests, to its CT by using this prefix.

Communication in the remaining direction, from the CT toward any of thenodes in the fragment, must be enabled in some other way. The made additionwas then to, in an ad hoc fashion, create this path in this initially non-existentdirection. The addition triggers when a node sends a certain type of Interest,initiating a so called Revision Update operation of the solution application. Thisoperation is, just like the rest of the solution application, described in more detailin Section 6.2. The name of this Interest contains the necessary information tocreate a path toward the node that sent the Interest. More specifically it hasthe structure ccnx:/fragX/nodeY, where X is the fragment ID and Y is node ID.Additional information is required to complete the operation but that is insteadstored in the payload of the Interest, as CCNx enables both Interest and ContentObject messages to contain payloads. At the conclusion of the operation theCT sends a corresponding Content Object, which then of course has the samename, as an acknowledgement. As this Content Object travels along the reverserequest path from the CT toward the node Metis will recognise the structureof the name and extract the node ID. Then it creates an FIB entry for thatnode, with the same interface as the one mapped to by the PIT entry matchingthe Content Object. In that manner FIB entries are created leading toward thenode along the entire path, starting from the CT. Afterwards a node can bereached by a CT by it sending messages with the prefix ccnx:/nodeY, where Y

30

again is the node ID. As mentioned before, in Metis a FIB entry is referred toas a route and adding one is as simple as a function call in the Metis sourcecode, as illustrated in Figure 6.

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 added automat i ca l l y1314 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. First the route iscreated with the call to the cpiRouteEntry_Create function and then it is addedto Metis itself with the call to the metisMessageProcessor_AddOrUpdateRoutefunction. The route maps toward the connection represented internally in Metisby the next_hop parameter.

Any names matching the general structure ccnx:/fragX/nodeY, ccnx:/fragX orccnx:/nodeY are reserved because of this addition, as made possible by thedelimitation specified in Section 5.2. The reasoning behind the reservation beingthat this added functionality in the Metis forwarder could fail or not function asexpected if a name matching the general structure of these names did not also

31

contain the identifiers expected by Metis. Likewise names with these prefixesare exempt from the built in caching of the Metis forwarder. Metis will normallystore any forwarded Content Object in its cache but doing that would in thiscase cause the name to no longer lead all the way to the end destination ofthe corresponding path, which would in turn disrupt the intended functionalityof the solution application as it requires the end destination to be actuallyreachable.

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 solutionapplication. 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 knowledgeregarding 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 done in the implementation of this psuedocode hasa negligible impact on how much time is required for each iteration. At theend of each iteration the solution application attempts to satisfy any receivedInterests. The first step in this process is to request any new Interests to theapplication from Metis. However if there are no new Interests then the requestwill eventually timeout before the solution application can proceed to the nextiteration. The timeout used in the implementation of the solution applicationis six seconds, which thus in practice becomes the upper limit for the amount of

32

time an iteration could require. At the same time the limit used is 16, meaningthat there are 16 iterations before the solution algorithm repeats. The specificactions taken by the solution application, once for every such 16 iterations asin Figure 7, for nodes and CTs are described in Section 6.2.2 and Section 6.2.3respectively. These values were chosen to be rather large since for a moderatelysized network topology they should ideally not cause an extreme amount oftraffic.

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 aremocked by the four C functions seen in Figure 8.

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 elementin the list corresponds to one neighbour. As these functions are mocked theysimply read the appropriate values from a configuration file, called the solutionconfiguration file, and return 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 to thatparticular content, as it has that content stored locally. How exactly the solutionapplication publishes content is described in the next section.

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 storinga revision number and the names of the files associated with that revision num-ber in a log file. The revision history is thus persistent. The format of this

33

file is simple, every line represents either a new revision number, a file additionor a file removal. The solution application continuously checks the publishingdirectory for any files being added or removed. Any time that such a change isdetected the revision log file is updated by increasing the revision number andnoting what 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 CCNuses 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 queries, 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 itsown local content. It is instead the responsibility of the sender of the Interestto instead redirect it to either the CT of that fragment or possibly directly to apublishing node, 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 Inter-ests are also used to execute the operations of the solution algorithm. Whena node detects a change in what content it is currently publishing it will in-crease its revision number, but also send an Interest to its CT triggering aRevision Update operation. The Interest used then has names of the structureccnx:/fragX/nodeY, where X is the fragment ID and Y is the node ID of the

34

sending node. CTs as mentioned previously listen to the prefix ccnx:/fragX/,which due to longest prefix matching will be a match for this name as well. Theuse of this name is described in Section 6.1.2, in that it enables Metis to buildthe path of FIB entries from the CT toward the node. The Interest payloadcontains a key identifying the operation, the latest revision number in a JSONobject for that node and the node ID. The effect of this operation is that theCT is informed of the latest revision of the sending node, and the CT respondsby sending an acknowledgement for that.

Additionally CTs can also trigger a Revision Request operation on a node. TheInterest then used 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 files in aJSON object in the payload.

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 maintains asecondary structure, called a revision map, which maps node IDs to whichrevision number associated with that node is currently represented in thecontent map. After receiving such an Interest the CT will first send anacknowledgement back to the node. Then, if the revision map does nothave an entry for the sending node, or if the entry has a lower revisionnumber than the one in the JSON object, a revision map entry is eithercreated or updated respectively according to the newly received revisionnumber. This is because the increased revision number means that this isnew knowledge for this particular CT. Afterwards the CT sends an Interestof the operation Revision Request to the node. The node response is thento send its list of currently published files which are used to update thecontent map, making it actual once again. The name of this particular

35

Interest is, once again, on the format ccnx:/fragX/nodeY, where X is thefragment and Y is the sending 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.

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

36

be lost or corrupted or the receiver might even have disconnected from thenetwork. As the solution application is not threaded, a delimitation specified inSection 5.2, it is additionally possible for it to be unable to satisfy an Interestsimply because it is busy with some other task. Such a task could be determiningwhether or not there had been any file changes in the publishing directory orfor CTs it could be synchronising with its neighbours. In order to manage theseproblems 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 allotted retransmissions when compared to other Interests,increasing the likelihood that they will be successfully delivered and a responsereceived.

37

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 is that the system clocks becomes 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.1.

7.1 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.

38

Figure 10: The CCN topology used in the evaluation.

This CCN topology was defined through the connections specified in the Metisconfiguration files. As such it is located above the network layer defined dur-ing the Vagrant configuration. Each vertex in the graph represents a VM, anetwork node in the topology. The edges represent node connections and thenodes elected to serve as CTs are marked as such. In this topology the 16 nodeswere distributed over a total of five fragments, as illustrated in the figure by thedotted lines. Note that the topology was not identical on the CCN layer and theunderlying network layer specified in the Vagrant environment. On the networklayer the graph had to be more complete, i.e. more nodes are connected, dueto practical limitations on how many IP networks a VM could be connected to.However this has no visible consequence on the scenario as the Metis forwardersare responsible for the network communication and they operate according tothe CCN topology. The Metis configuration file also specifies the routes corre-sponding to the FIB entries for the paths from every node to its CT and thepaths between neighbouring CTs. These paths were a necessity for the solutionto function properly as specified in the assumptions of Section 5.2.

One limitation of this scenario is that it incorporates 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.

39

After the configuration of the entire topology was completed a relatively simplescenario was considered that would enable the solution to demonstrate if itcould 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 creation and placingof each file. This means that shortly after 90 seconds, or one and half minutes,of the scenario had passed there was a total of 26 unique files in the topology,the 16 original ones and the ten random ones. This creates a lower bound forwhen it was possible for the solution application to converge, by replicating all26 files 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 the number of files that were success-fully replicated to all five fragments. The third column, Convergence, show howmany seconds passed before before all of the replicated files were present in allfive fragments. The fourth column, Interests, show the number of Interests thatwere sent in total by all solution applications in the topology throughout thescenario. The fifth column, Retransmissions, show the number of retransmis-sions that had to be sent in total by all solution applications throughout thescenario. The number of Interests and retransmissions together give quite a

40

good indication of the amount of network traffic that was present in the topol-ogy throughout the scenario. This is because every Interest is matched by atmost one Content Object, due to the flow balance of CCN. The entire table thusshows that over 16 runs the average result was that all 26 files were replicatedto all five fragments and the elapsed time at the point when that was achievedwas 525 seconds, or 8 minutes and 45 seconds. This was done at an averagecost of the solution applications together sending a total of 193.3 Interests and141.9 retransmissions, which corresponds to around 1.5 Interests and around 1.1retransmissions 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 with values x1, x2 . . . xnis 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 smallis conventionally set to less than 30, then it is not necessarily true that thesample variance s2 is a good estimate of the population variance σ2 [51]. Thisis the case for this evaluation, as there are 16 samples. Then the Student’s tdistribution, with n−1 degrees of freedom, can be used to find the lower boundc1 and upper bound c2 for the confidence interval of µ, as in Equation (3) andEquation (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].

41

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 shownin 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

42

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 not only the solution application but also the entire solution sys-tem. The solution application is separated from the solution system by thedelimitations and assumptions. However the assumptions are related to theunimplemented functionality of the solution system and could realistically beimplemented in the future. As such these initial results for the solution appli-cation show promise.

8.1 Comparison against requirements

Beyond the primary purpose there were also several requirements defined forthe solution application in Section 5.3. The most apparent way to qualitativelyevaluate the solution 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 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 caused by a new file being publishedfail, even though an increased amount of retransmissions are enabled for thoseoperations. What happens then is that the CT will never learn of the newlypublished file or files that are now available in the fragment. Though it is entirelypossible that, if later another change happens in the publishing directory of thesame node, the next Revision Update operation and Revision Update operationsucceed and cover the earlier failure. Nonetheless it is a reassuring sign that sucha failure never occurred in the evaluation as that implies that the probability ofit happening is quite low, which in turn signifies that the solution applicationis reliable.

43

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 entriesfor 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, say fileA, is published on two separatenodes X and Y in the network it will be represented by two separate names:nodeX/fileA and nodeY/fileA. As the caching of Metis is based on name onlythis means that a router that caches content with the first name will not beable to use that cached content to satisfy requests for the second name, eventhough in reality both names correspond to the same exact piece of content.To manage this either the node level namespace can be abstracted into someform of locator so that the names can be identical or Metis can be extensivelymodified to somehow recognise that even though the names differ the associatedcontent is the same. Both of these approaches are at the very least feasible toimplement meaning that this problem could be solved, though not within thescope of this particular thesis.

The solution application does not rely on any extensive modifications to theMetis forwarder or the general CCN architecture since only a single relativelyminor addition was made to Metis, as described in Section 6.1.2. This matchesthe requirements well and promotes applicability.

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, being 1.49and 1.09 per file and fragment respectively. While it would be desirable to havemore concrete performance milestone metrics they cannot be reasonably definedbefore more research has been made. Instead the results for the metrics actu-ally measured in the evaluation can be considered as reasonable for now, giventhat they show that there is some potential in using ICN to achieve informationretention.

8.2 Scalability

The scalability of the solution application is in general a question that cannotbe properly addressed by the evaluation as it covered only a relatively smallscenario. In addition, both requiring the ability to reserve names in a globalnamespace and requiring that each network node and fragment have been as-signed globally unique identifiers raise further questions regarding scalability. Ifit can be avoided it is preferable to not reserve any names in the namespaceas doing so reduces applicability and employability since it is very challengingto enforce globally. Likewise it is difficult to enforce that all nodes in an ac-

44

tual topology run the solution architecture, which is required in order for it toachieve the best possible result. The relatively low amount of traffic generatedby the solution application during the evaluation does however indicate thatat least that aspect of the solution could scale, even if it was only shown in asmall scenario so far. A further advantage regarding network traffic is that thesolution application does not rely on any broadcasting in the network, whichquickly leads to large amounts of traffic, but rather direct communication be-tween network nodes.

Scalability is actually 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 applicability and scalability were not primaryconcerns of this thesis. Rather the primary concern was to achieve informationretention, which the solution was able to do though at the cost of increasedadministrative overhead.

8.3 Energy efficiency

While the solution application is appropriate for managing fragmentation inthat it successfully replicated content across all fragments, a primary concern isthe energy efficiency it had while doing so. Having energy efficiency is not onlycritical for prolonging the lifetime of any network node running the solutionapplication, it also reduces any environmental impact. It depends primarily onhow much time elapses between each time network nodes need to communicate,as the communication is of a repeating pattern. Sending messages over thenetwork requires hardware usage, which should make up the majority of theenergy usage for the solution application. In the evaluation the number of sentmessages was not unreasonably high which is thus an indicator for a decent levelof energy efficiency. However frequent node communication is beneficial for theactuality of the state of content in the topology stored in the CTs. Where tobalance the solution between energy efficiency on one hand and content stateactuality on the other is not obvious. This is a question of prioritisation withouta clear correct answer and in this initial solution application implementation itwas set at least somewhat arbitrarily. An evaluation including metrics for theenergy efficiency could potentially come to some quite interesting conclusionsby experimenting with different priorities along this balance.

8.4 Fragment demarcation

Another primary concern for the solution system is the demarcation of thenetwork topology into fragments, as the quality of the demarcation is essentialto performance. Ideally the demarcation should be adapted to each specificscenario, taking its unique conditions into account. If the size of the fragmentsis too small in general, meaning the majority of the fragments contain too fewnetwork nodes, then there will be a drastic amount of administrative overheadfor each fragment relative to its size. Further there will be significant amounts

45

of traffic as the CTs communicate with each other. Likewise there will alsobe an exaggerated amount of content replication throughout the topology asevery CT serves as a replication point. On the other hand if the size of thefragments is too large in general, meaning the majority fragment contain toomany network nodes, then there will not be very many content replications andthe topology will remain at risk of losing content availability in the event of adisaster. Exactly what number corresponds to too few or too many nodes isdifficult to say but regardless the solution system requires a demarcation that isneither. The fragments should be of a size that achieves a balance between theadministrative overhead and drastic traffic amounts of too small fragments andthe insufficient content replication of too large fragments. Where this balanceis and how to achieve it are critical questions for the solution system and theiranswers can at this point only be speculated.

However for the solution application developed in this thesis the demarcationis assumed to be not only completed but also of a sufficient quality. It is thusnot within the scope of this thesis to investigate how to demarcate the topologyinto fragments. However by considering the network topology as a graph thedemarcation could possibly be done through community detection. Communitydetection is used to identify clusters in a graph, where vertices of the samecluster are joined by many edges and vertices of different clusters are joined bycomparatively few edges [52]. A cluster is thus a fairly independent compart-ment of a graph [52], very reminiscent of a fragment in the solution system.A centralised community detection approach might not be applicable to thisparticular case as it is most likely unfeasible to expect that any one node willbe able to see the entire network topology graph, at least when the topologyis of a realistically large size. There are however decentralised approaches tocommunity detection, for example [53] and [54], that could perhaps work betterfor this purpose.

8.5 Possible improvements

While the solution does not send any unnecessary messages the format of thesent messages could perhaps be more efficient. An obvious improvement wouldbe for CTs to not request complete lists of unique content each time they syn-chronise with their neighbours. Instead they could just request for any eventualadditions in available content. However as this both does not affect the corefunctionality and also is quite inconsequential when the amount of availablecontent is as low as in the evaluation scenario it was deemed an unnecessarycomplication. Still, it would decrease the size of those messages which would inturn reduce the amount of used bandwidth. It is also a step toward being ableto lift the assumption that any piece of content will fit into a single ContentObject. Also, the number of retransmissions could most likely be drasticallyreduced by making the solution application threaded so that it can respond toInterests for published files while at the same time performing other tasks suchas a CT synchronising with its neighbours. However this improvement doesalso not affect the core functionality and is arguably outside a scope limited toa PoC level application that does not completely implement the entire solution

46

system. For a more extensive study there are several additional metrics to theones used in the evaluation that could be considered when evaluating an ICN,or as in this case CCN, solution. These include traffic metrics such as down-load time, goodput, startup latency, throughput and packet delay in addition tocomponent metrics such as resolution time, request rate and cache hit ratio [55].On a grander scale system metrics concerning reliability and delay or disruptiontolerance can be considered.

47

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.

The primary goal of the solution application was to achieve information reten-tion and this was indeed achieved, at least in the evaluation scenario. Still, it isimportant to remember that the solution application was on a PoC level, thatit was tested in a relatively small scenario and that it was supported by delim-itations and assumptions. Because of this it is important to exercise caution inorder to prevent drawing too grand conclusions.

If the achieved information retention was worth the increased energy usage, net-work traffic and administrative overhead is not similarly apparent. Additionallywhile the solution application performed satisfactorily by itself it is important toremember that it is still only one part of a greater solution system and that thethe remaining parts are currently covered by delimitations and assumptions.For now it can be said that in the evaluation scenario the solution applica-tion successfully mitigated the decreased content availability caused by networkfragmentation. The decreased content availability was actually limited to a veryhigh degree and likewise the created requirements were met. Through this thesolution application demonstrated that there is potential in using CCN for in-formation retention in fragmented networks in this manner. This serves as theanswer to the research question, which was: “To what degree can ICN be used tomitigate the decreased content availability caused by network fragmentation indisaster-stricken networks? ”. While this is a promising result it would of coursebe more ideal if it could also be compared directly against some alternative.Though as no such alternatives are readily available and accessible this analysiswill have to be sufficient on its own for now. When and if the delimitations andassumptions are removed and the solution system is implemented in its entiretyit remains to be seen if this conclusion will be corroborated or contradicted.This is an open question, one of several for the relatively young field of ICNresearch.

However the answering of such 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 which also includes the improvements

48

suggested in Section 8.5. This investigation would preferably also include anevaluation scenario with a much larger network topology, which would enablean investigation on scalability. It would also be beneficial to make the scenariomore dynamic by having the topology change over the course of time, as a realnetwork topology would most likely not be completely static. From a greaterperspective there is also work left to be done on the ICN and CCN level regardingimplementing a truly complete and functional architecture. The CCN softwareused in this thesis is a step in that direction but still some functionality wasleft unimplemented, perhaps most notably the lack of non-trivial forwarding orrouting protocols. Such a complete architecture will be required before it canbe definitely and objectively decided whether or not ICN truly is a good choicefor the Internet architecture of the future.

49

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-

50

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.

51

[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-

52

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.

53

[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] S. Fortunato, “Community detection in graphs,” Physics Reports, vol. 486,no. 3–5, pp. 75 – 174, 2010.

[53] P. Hu and W. C. Lau, “Localized algorithm of community detection onlarge-scale decentralized social networks,” CoRR, vol. abs/1212.6323, 2012.

[54] M. Canu, M. J. Lesot, and A. R. D’Allonnes, “Overlapping communitydetection by local decentralised vertex-centred process,” in 2016 IEEE 16thInternational Conference on Data Mining Workshops (ICDMW), pp. 77–84, Dec 2016.

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

54

www.kth.se