name resolution information distribution in...

KTH ROYAL INSTITUTE OF TECHNOLOGYINFORMATION AND COMMUNICATION TECHNOLOGY

Name Resolution Information Distribution in NetInf

Jiawei Zhang & Yongchao Wu

Master’s Degree ProjectStockholm, Sweden 2015-05

Name Resolution Information Distribution in NetInf

Jiawei [email protected]

Yongchao [email protected]

Examiner:

Peter SjödinKTH Royal Institute of Technology

Supervisor:

Anders ErikssonAdeel Mohammad MalikBörje OhlmanKarl-Åke PerssonEricsson AB

Abstract

Information-Centric Networking (ICN) is a different architecture from today’sInternet, which is host-centric. In ICN, content is requested by the names ofcontent objects instead of network or host addresses. This feature allows fora number of advantages, such as in-network caching and request aggregation.Network of Information (NetInf) is an ICN architecture. It is an overlay onTCP/IP, which translates content object names to locators or IP addresses.NetInf is designed to facilitate initial deployment and migration from today’snetworks to ICN.

In an ICN network, content can be cached at numerous locations giving a clientthe possibility to retrieve content from a number of available sources. In orderto retrieve a content object, a client does a lookup in a Name Resolution Ser-vice (NRS) to resolve the content name into a set of locators where the contentis stored. By distributing the location information of content objects from theNRS to NetInf nodes in the network the lookup time and overhead caused by thelookup messages can be reduced. Hence resulting in better end-user experienceand more efficient network utilization. In this thesis, two methods to distributelocation information of content objects in a NetInf network have been proposedand evaluated against a reference model where the location information is hostedcentrally in an NRS. The effectiveness of the proposed methods has been eval-uated by running simulations on a NetInf simulator (built on OMNeT++) thatwas built during the course of this project.

Evaluation results show that the proposed methods reduce the lookup/nameresolution latency of content objects. The results also compare the overheadcaused by each one of the proposed methods in terms of network utilization.We also show the results that the network topology has an impact on the ef-fectiveness of the proposed methods and therefore is a factor that needs dueconsideration in deciding which method is suitable when.

Acknowledgments

We would like to thank our manager Patrick Sellstedt for giving us the opportu-nity to perform our Master Thesis project in Evolved Packet Core team withinEricsson Research. It is our honor to work with such a great team. Thanks toPatrick, we could have the chance to be evolved in cutting edge technology andproject, and work with the most professional experts in ICN technology. It willbe our precious memory during our life.

Thanks to our supervisors in Ericsson Research. They are Anders Eriksson,Adeel Mohammad Malik, Borje Ohlman and Karl-Ake Persson. Thanks for allthe supports, discussions, and suggestions. We appreciate the freedom and trustwe had from beginning to the end of the project, from proposing our ideas tomaking decisions in all of the stages during the project. It is our pleasure towork with you for one year.

We would like to express our sincere gratitude to our examiner Peter Sjodin inKTH for giving us enough time to finish a lot of hard work in this project andinsightful comments on the thesis.

Thanks to my parents in China, who supported me throughout my wholeeducation years. They always show me unconditional loves and support whenI got stuck in some parts of the project. Thanks to my friends in Stockholm.Special thanks to Yao Lu for giving me a lot of useful technical support onMATLAB during the project.

Jiawei

I would like to thank my friend Jiawei. He helped me a lot during theproject, and shared lots of skills in programming and project management withme; therefore I have made a great progress during the project. Most importantly,I would like to thank my family. With their support, I could realize my dreamto study in such a wonderful country and a great university.

Yongchao

Contents

List of Figures iii

List of Tables iv

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4.1 Ethics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4.2 Sustainability . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.6 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.7 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Background 52.1 Information-Centric Networking . . . . . . . . . . . . . . . . . . . 52.2 Network of Information . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 Named Data Objects . . . . . . . . . . . . . . . . . . . . . 52.2.2 NetInf Protocol . . . . . . . . . . . . . . . . . . . . . . . . 62.2.3 Convergence Layer . . . . . . . . . . . . . . . . . . . . . . 72.2.4 Routing and Name Resolution . . . . . . . . . . . . . . . 72.2.5 On-Path and Off-Path Caching . . . . . . . . . . . . . . . 72.2.6 Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.1 Breadcrumbs . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.2 Cache ”Less for more” . . . . . . . . . . . . . . . . . . . . 9

3 Environment 103.1 OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.1 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1.2 Result Recording . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 MATLAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Design and Implementation 124.1 Method Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . 124.1.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . 12

i

4.1.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.1.4 Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . 134.1.5 Method 1 - Central . . . . . . . . . . . . . . . . . . . . . . 144.1.6 Method 2 - Active . . . . . . . . . . . . . . . . . . . . . . 154.1.7 Method 3 - Passive . . . . . . . . . . . . . . . . . . . . . . 164.1.8 Method 4 - Hybrid . . . . . . . . . . . . . . . . . . . . . . 164.1.9 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2.1 Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2.2 Routing Function . . . . . . . . . . . . . . . . . . . . . . . 184.2.3 Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 184.2.4 Request Aggregation . . . . . . . . . . . . . . . . . . . . . 194.2.5 Source Selection and Cost Model . . . . . . . . . . . . . . 214.2.6 Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2.7 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Evaluation 245.1 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.1.1 Network Topology . . . . . . . . . . . . . . . . . . . . . . 245.1.2 Content Objects . . . . . . . . . . . . . . . . . . . . . . . 255.1.3 Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.1.4 Packet Length . . . . . . . . . . . . . . . . . . . . . . . . 265.1.5 Compared Methods . . . . . . . . . . . . . . . . . . . . . 275.1.6 Warm-Up Period . . . . . . . . . . . . . . . . . . . . . . . 27

5.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2.1 NDO Retrieval Time . . . . . . . . . . . . . . . . . . . . . 285.2.2 Signaling Overhead . . . . . . . . . . . . . . . . . . . . . . 30

5.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6 Conclusion and Future Work 326.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.2.1 More Complicated Cost Model . . . . . . . . . . . . . . . 336.2.2 Dynamic Networks . . . . . . . . . . . . . . . . . . . . . . 336.2.3 NRS Information Update . . . . . . . . . . . . . . . . . . 336.2.4 Network Caches . . . . . . . . . . . . . . . . . . . . . . . 34

Bibliography 35

Appendix A. Terminology 38

Appendix B. Method Description 39

Appendix C. Packet Length Specification 47

ii

List of Figures

1.1 Mobile devices using cellular connection . . . . . . . . . . . . . . 2

2.1 NetInf Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.1 Neighbor Discovery Process . . . . . . . . . . . . . . . . . . . . . 134.2 Abstract Structure of a NetInf Message . . . . . . . . . . . . . . 184.3 Name Resolution Service Table (NRST) . . . . . . . . . . . . . . 194.4 Request Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 204.5 Request Aggregation List . . . . . . . . . . . . . . . . . . . . . . 204.6 Request Aggregation (Mode 1) . . . . . . . . . . . . . . . . . . . 214.7 Request Aggregation (Mode 2) . . . . . . . . . . . . . . . . . . . 214.8 Source Selection based on Weight . . . . . . . . . . . . . . . . . . 224.9 Node Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 234.10 Method Composition . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1 Tree Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.2 Mesh Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.3 NDO Retrieval Time . . . . . . . . . . . . . . . . . . . . . . . . . 275.4 NDO Retrieval Time (frequency) . . . . . . . . . . . . . . . . . . 285.5 NDO Retrieval Time (interval) . . . . . . . . . . . . . . . . . . . 295.6 Signaling Data Ratio (interval) . . . . . . . . . . . . . . . . . . . 31

iii

List of Tables

4.1 Message Kind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.1 Common Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 245.2 Parameters for Tree Topology . . . . . . . . . . . . . . . . . . . . 255.3 Parameters for Mesh Topology . . . . . . . . . . . . . . . . . . . 25

iv

Chapter 1

Introduction

Information-Centric Networking (ICN) [1] is a different architecture from to-day’s Internet, which is host-centric. ICN provides the service of locating con-tent. The clients request content using names or identifiers without having toworry about where the content locates. It is unlike the current host-centricInternet paradigm where end-hosts explicitly communicate with each other.

1.1 Background

Figure 1.1 shows the trend of increase of mobile devices using cellular connection,including Smartphones, mobile PCs, tablets, etc. By 2019, there will be morethan 6 billion cellular connections in the world, which will result in higherdemand for network capacity than ever before.

Large crowd events are also a problem in today’s mobile networks. When numer-ous users access the same content in the network simultaneously (for example,a popular football game), the server in the host-centric network will face un-usual pressure. Thus, the users may suffer from network congestion and largelatency, which results in a bad user experience. As one to many communicationscenarios generated most of the Internet traffic today, more efficient methods todeal with them are needed [2].

To handle the problem, Information-Centric Networking has been proposed bythe research community. In recent year, many information-centric approacheshave emerged: Content Centric Networking (CCN) [3], Data Oriented Net-work Architecture (DONA) [4], Publish/Subscribe Internet Routing Paradigm(PSIRP) [5], Networking of Information (NetInf) [6, 7], etc. Different ap-proaches have different models and components; however, they all share thesame principle: focusing on the content itself rather than the location of thecontent in the network. This could have a better fit than host-centric architec-tures to the current Internet traffic trends [8].

1

Figure 1.1: Mobile devices using cellular connection

1.2 Problem

In NetInf, content providers publish the locations of content objects into NameResolution Service (NRS) [9]. NRS is a service that provides the functionality ofresolving the names of content objects into locators or IP addresses in NetInf. Inorder to retrieve a content object, a client does a lookup in a Name ResolutionService (NRS) to resolve the content name into a set of locators where thecontent is stored. Due to the mechanism that all requests should be forwardedto the NRS, the clients may suffer from a large latency, and the NRS servermight be overloaded if the traffic is very large. Thus, the Name Resolutionmechanism needs to be improved to reduce the latency, the workload of theNRS and save the bandwidth.

In this thesis, we are focusing on the design of methods to reduce the latency(content retrieval time) and network overhead. The problem in this thesis isdefined by the following question:

How should the method for distributing Name Resolution Information be de-signed in order to reduce the latency of content retrieval and network overhead?

The effectiveness of the proposed methods has been evaluated by running sim-ulations on a NetInf simulator (built on OMNeT++) that was built during thecourse of this project.

2

1.3 Purpose

The thesis presents the work of designing and evaluating experimental solutionsfor improving the Name Resolution mechanism in NetInf.

1.4 Goal

The goal of the work is to distribute the Name Resolution Information in Net-Inf to reduce the content retrieval time and network overhead. The result ofthe work leads to an increased understanding of how the latency and networkoverhead are affected by different experimental methods for distributing NameResolution Information and what method is suitable for which scenario. Theresult could benefit the further research on utilization of the Name ResolutionInformation in NetInf.

1.4.1 Ethics

There are some ethical issues in the ICN field. One of them is the cache onpath mechanism. If the content objects can be cached by any node in thenetwork, there might be some legal issues. The owner should have some accesscontrol over the content they published. Another issue is the confidentiality.The requests sent by the clients are forwarded by the nodes in the network sothat the nodes may inspect the content of the request and its response. Theprivacy of the clients might be violated. To ensure the privacy of the clients,the content might be encrypted.

1.4.2 Sustainability

The method proposed in this thesis brings the information about content loca-tions closer to the clients, thus reducing the traffic for name resolution process.The caches in the network also decrease the distance from clients to the sourcenode. It also reduces the traffic in the network. These features of the NetInfcan be used to build an energy-efficient network that is good for sustainabledevelopment.

1.5 Methodology

The project consists of four main phases: literature study, method design, im-plementation, evaluation, and documentation.

During the literature study, several scientific papers related to ICN are reviewedto understand the background, differences from the host-centric network and theNetInf architecture. During the methods design phase, the scope of the thesis is

3

defined, and initial solutions are proposed. During the implementation phase, aNetInf simulator is implemented step by step and the methods are implementedand deployed within the simulator. The quantitative method is applied to theevaluation and documentation phase. Also, since numerical data is collected inexperiments, experimental research method, and deductive approach would bethe best approach to be employed. In this phase, experiments are conductedon two different scenarios with the simulator. MATLAB is used to processand visualize the data generated during the simulation runs. According to themetrics, conclusions are made and documented.

1.6 Contribution

The three major contributions from the thesis project are:

• (1) Two experimental methods (Active and Passive methods) for distribut-ing Name Resolution Information were designed to reduce the contentretrieval time and network overhead in NetInf;

• (2) The methods proposed in the thesis were evaluated together with theconventional method in NetInf to show the pro and con of the differentmethods;

• (3) For the research community, the result of the evaluation can leadto a better understanding how to take advantage of Name ResolutionInformation to improve the performance of the network.

1.7 Outline

Chapter 1 gives a brief introduction to the thesis work. Chapter 2 describesthe Information-Centric Networking (ICN) and Network of Information (Net-Inf). Chapter 3 gives a general introduction to the technical environment forevaluations. Chapter 4 describes the design and implementation of the NetInfsimulator and the proposed methods in detail. Chapter 5 presents the scenariosused for evaluation and the results generated from the data collected. Chapter6 surmises the work and presents the conclusion and future work.

4

Chapter 2

Background

2.1 Information-Centric Networking

Information Centric-Networking (ICN) is a different architecture from today’sInternet, which is host-centric. The core idea of ICN is to focus on the contentobjects rather than devices and networks. It means the focus is on the contentobjects to be retrieved (not where the content is stored) in ICN. ICN is anew research field, and there are currently many different approaches beingdeveloped [3, 4, 5, 6, 7]. Some attempts have been made to define ICN at amechanism-independent service level [9].

2.2 Network of Information

Network of Information (NetInf) is an ICN approach. It was first developedin FP7 4Ward Project [10, 11], then got continued development In FP7 SAILProject [12, 13].

2.2.1 Named Data Objects

NetInf is an approach that provides service to access Named Data Objects(NDOs) in the network. NDOs can be web pages, videos, pictures, etc. EachNDO in the NetInf has a unique name. A flat URI based naming scheme isemployed in NetInf:

ni://[Authority]/[Digest Algo];[Digest Value]?[Query Params]

The Authority field is used to help applications to access content objects.Both name-based routing and name resolution can make use of it. The DigestAlgo field is used to specify which hash function is employed to calculate theDigest Value field. Digest Value field is used to represent the content.

5

With these two fields, NetInf can provide name-data integrity validation, whichis the basic security service in NetInf. The validation can be performed withoutinfrastructure support like a Public Key Infrastructure (PKI). It is implementedby adding the output of employing hash function of the NDO to its name [14].Query Params is an optional field, it can be used to provide some extraparameters for different purposes [15].

2.2.2 NetInf Protocol

Figure 2.1 shows the stack of NetInf Protocol [6]. In real world, networks canbe very different. Different employment may base on different link layers andunderlays. NetInf solves this problem by introducing Convergence Layers (CLs)that converts the conceptual protocol to the specific messages for concrete proto-col. For example, NetInf-over-IP requires a CL that encapsulate and fragmentsNetInf messages into IP packets and validates message integrity. Some spe-cific CLs can also provide transport functions, such as reliability, flow control,congestion control.

ApplicationsTransport

NetInfCL 1 CL 2

Lower Layer 1 Lower Layer 2Physical

Figure 2.1: NetInf Protocol Stack

In the NetInf Protocol, following message types are defined:

GET/GET-RESP A GET message is sent to request for an NDO in NetInfcapable network. A GET message contains the unique name of an NDO, which isfollowing NI URL scheme. The node that receives a GET request will generatea GET-RESP or forward it and wait for a reasonable time (timeout) beforesending the response.

PUBLISH/PUBLISH-RESP A PUBLISH message is sent to tell a NetInfnode (usually, it is NRS) the existence and basic information of an NDO inthe network. The PUBLISH message should contain the name of an NDO andlocators showing where the NDO is stored in the network. A PUBLISH-RESPmessage is used to notify the publisher if the publication succeeds or not. Itcontains some status values showing the result of the operation.

SEARCH/SEARCH-RESP A SEARCH message is sent to look for a spe-cific NDO in NetInf network. The SEARCH request contains some rules (to-kens) describing what NDOs it looks for. A SEARCH-RESP may contain a listof NDO name that match the rules (tokens) in the request.

6

2.2.3 Convergence Layer

Convergence Layer (CL) provides services for NetInf nodes. It enables commu-nications between NetInf nodes. Currently, there are three CLs being workedon: HTTP CL, UDP CL [7] and Bluetooth CL [2]. The names of these CLsreflect the lower layer protocols they are built on.

2.2.4 Routing and Name Resolution

NetInf supports both name resolution and name-based routing. Name resolutionservice in the network maps NDO names to network locations. Name-basedrouting enables a NetInf node to find out the next hop of the request or responseonly by NDO names. More details will be discussed in the implementation part.The name-based routing could simply match the NDOs names with routing rulesby pattern matching. In this way, a request from a local network can reach anedge with external access, at which point name resolution service is provided.

NetInf nodes are responsible for forwarding request and response messages. Dif-ferent routing protocol will apply to different parts of networks, just like multiplerouting protocols for Internet Protocol (IP) today. For example, NetInf supportOpen Shortest Path First (OSPF) for local domains and Border Gateway Pro-tocol (BGP) for global level.

2.2.5 On-Path and Off-Path Caching

NetInf supports on-path (request/data path) and off-path caching. When aGET-RESP with NDO data traverses the NetInf node which does on-pathcaching (cache on path), the NDO might be cached on the node according to theconfigurations of the node. On-path caching brings content closer to consumers;hence the bandwidth consumption and content retrieval time can be reduced[6]. Off-path caching is an alternative mechanism; it can avoid the duplicationsand increase the overall hit rate. It tries to cache the popular content to optimallocations [16].

2.2.6 Message Flow

Figure 2.2 shows an example of name-based routing, name resolution and thehybrid in NetInf. Steps A1-A6 shows how name-based routing works. First, theclient sends out a GET message (step A1) to Router 1. Then, the NDO namein the GET message is checked by the Router 1 to decide which is the next hop(step A2). Router 2 also checks the NDO name to decide the next hop, in thiscase, it is the Source node (step A3). Finally, the NDO will be sent back to theclient (A4-A5-A6). In name-based routing, the GET request is forwarded byname-based routing hop by hop until a copy of the NDO is found. If the routerdoes not have enough information about where to forward the request in stepA2, a name resolution step can be performed (step A1.1-A1.2) before step A2.

7

NRS ServerNRS Server

Router 1

Router 2

Source Source

GET

Locators

GET

DATA

GET

GET

GET

GET

Routing hints

DATA

DATA DATA

A1A2

A3 A4

A5 A6

A1.1A1.2

B1

B2

B3

B4

Figure 2.2: Message Flow

It is the hybrid approach, which is a combination of name-based routing andname resolution.

Steps B1-B4 shows how name resolution works. First, a client sends a GETrequest to the NRS Server (step B1). Then, the NRS translate the NDO nameinto source locations and send them to the client (step B2). After receiving theresolved locations, the client sends another GET request to the source locationfrom its perspective (step B3). Finally, the source node sends the NDO back tothe client (step B4). In name resolution, A GET message sent to NRS will beresolved with locators, then the locators are used to retrieve the object via theunderlying network, for example, IPv4 network [6].

2.3 Related Works

2.3.1 Breadcrumbs

Breadcrumbs [17] is an architecture for caching guidance information in thenetwork. It is a simple content caching, location and routing system. In BCsnetwork, each router has a local log file that logs the content objects passingthrough it. When the content object is downloaded, the routers on the downloadpath generate minimal information to route request. When a request for contentencounters this guidance information on its way to the source node, the requestis routed to the nodes that may have the content. It enables clients to make useof the content downloaded previously by other nodes in the network. Recently, ademo on Contents Sharing among Mobile Users in Breadcrumbs-enabled Cache

8

Network has been published, it proposed several extensions to overcome thedrawbacks of original Breadcrumbs, such as ABC (Active Bread- crumbs) [18],HBC (Hop-aware Breadcrumbs) [19], BC+ [20] and MSCR (Mapping Serverwith Cache Resolution) [21].

Breadcrumbs is similar to the Passive method developed in this thesis project,but they are different. Both Breadcrumbs and the Passive method store guid-ance information in the network, but the guidance information and the routingmethod are different. In Breadcrumbs the guidance information contains theID of node from which the file arrived and the ID of node to which the file wasforwarded [17], while in the Passive method, the guidance information containsthe location of the source node that really has the content. In short words,Breadcrumb can be used to improve the name-based routing in NetInf whilethe Passive method in this thesis is designed to improve the name resolution.Since we are focusing on the distribution of name resolution information in thisthesis, there is no need to include Breadcrumbs in the analysis.

2.3.2 Cache ”Less for more”

In-network caching is one of the outstanding features of Information-CentricNetworking (ICN). The Cache ”Less for more” approach [22] is proposed toreplace the universal caching strategy, in which the nodes always cache all thecontent. The goal is to reduce the cache replacement rate while still cachingcontent that is more probable to be hit in the cache. The mean idea of the workis only to cache the popular content using popularity factor.

In this thesis, the methods developed shares the concept ”less for more” in adifferent way. In ”Less for more” approach, it caches the most popular contentin the network while in our methods only the name resolution information iscached rather than the content itself. A least recently used (LRU) cache evictionpolicy from ”Less for more” can also be used to update the name resolutioninformation stored in the network.

9

Chapter 3

Environment

This chapter gives a brief introduction to the simulation framework appliedduring the implementation of NetInf simulator and the analysis tools duringthe evaluation process.

3.1 OMNeT++

OMNeT++ is an extensible, modular, component-based C++ simulation li-brary for building network simulators [23]. It is a discrete event simulationenvironment. It provides an eclipse-based IDE, a graphical runtime environ-ment, and many other supporting frameworks. OMNeT++ 4.5 is used in thethesis to build a NetInf simulator, implement methods and record results.

3.1.1 Modeling

NED language is used in OMNeT++ to describe the structure of a simulation.NED stands for Network Description. Users can declare simple modules andconnections between modules. Compound modules can be assembled from sim-ple modules, which enable users to describe more complex networks. Simplemodules are active components of the model. Simple modules are defined byNED and implemented in C++ code. All of the handlers (that do the real work)are implemented in simple modules. Gates are the connection points of modules,which are the abstraction of the network interface in OMNeT++. Channels arethe links between gates. Users can set data rate, drop rate and loss rate of thechannels.

3.1.2 Result Recording

OMNeT++ provides two methods for result recording. One is signal-basedstatistic, the other one is to use built-in C++ library. With built-in support

10

for recording simulation results, users can record anything that is useful to geta full picture of what happened in the model during the simulation run. Forthe thesis, signal-based statistic is chosen for result recording because it enablesusers to record the result in the form they need, without continuous tweakingof the simulation code.

3.2 MATLAB

MATLAB is used to process and visualize the data generated by the simulations.MATLAB is a high-level language and interactive environment for numericalcomputation, visualization and programming [24] . OMNeT++ also has a built-in analysis tool, but it is a little weak as well as some bugs when processinga large amount of data. That is the reason MATLAB is chosen instead ofOMNeT++ built in tools.

11

Chapter 4

Design and Implementation

Section 4.1 introduces the methods proposed and developed in this thesis project.Section 4.2 gives specifications of how these methods are implemented.

4.1 Method Design

In this section, details of the methods developed during the thesis are presented.

4.1.1 Motivations

The motivation of the methods proposed in the thesis is to distribute the NameResolution Information in the network in order to reduce NDO retrieval timeand network overhead.

4.1.2 Limitations

There are a lot of KPIs can be used to measure the performance of differentmethods. With the limitation of the scope of the thesis, only the latency ofcontent retrieval and signaling overhead are considered.

4.1.3 Overview

A Neighbor Discovery method is proposed and presented in Section 4.1.4. TheNeighbor Discovery method is the fundamental module of the Active method,in which the information about NetInf neighbors is used to populate the infor-mation about NDOs.

In the Active method, when a node caches a new NDO, it will send out a specialtype of message to its neighbors telling them what NDO it has. A NetInf node

12

takes this action actively, so the method is called Active method. In contraryto active, a Passive method is proposed.

In the Passive method, the Neighbor Discovery method is not needed. The in-formation about available NDOs in the network is populated (cached) passivelyon path (request/NRS).

The Central method is the conventional method in NetInf; the NRS server willalways resolve requests. In other words, the information about NDOs is onlycentralized in NRS server. That is why it is called Central methods in thisthesis.

The Hybrid method is a combination of Active and Passive methods, whichtakes the good features of both methods.

4.1.4 Neighbor Discovery

For the purpose of discovering neighbors in the NetInf network for a NetInfnode, some extensions are made to NetInf protocol. They are HELLO andHELLO-RESP messages. One thing to be noticed is that the neighbor in thethesis means the direct neighbor in NetInf network. A direct neighbor is anode’s neighbor within one hop in the overlay of NetInf.

When the Neighbor Discovery process starts, the node that needs to know itsneighbors will broadcast HELLO messages. A HELLO message contains thesender’s address and optionality the sender’s host name. These HELLO mes-sages cannot be forwarded by other nodes by limiting the NetInf TTL of themessage to 1. NetInf TTL means NetInf Time-To-Live, which controls howmany hops a NetInf message can be forwarded. It ensures only the direct neigh-bors have the possibility to receive and reply HELLO messages.

NITNeighbor

NetInf NetworkHELLO

HELLO-RESP

HELLO

HELLO-RESP

HELLO

HELLO-RESP

Router 1

Bob

AddressRouter 1 192.168.31.1

Bob 192.168.0.25

Alice

NITNeighbor Address

Alice 192.168.31.66

NITNeighbor Address

Alice 192.168.31.66

Figure 4.1: Neighbor Discovery Process

The node that receives a HELLO message will update its Neighbor InformationTable (NIT) first, and then send back a HELLO-RESP message to the sender ofHELLO. NIT maintains the list of neighbors of a NetInf node. Figure 4.1 showsan example of Neighbor Discover process and NIT tables. Alice broadcasts

13

messages into networks, and then waits for replies. When NetInf Router 1 orBob receives the HELLO message, they will send back HELLO-RESP messagesand add the information about Alice into their NITs. Upon receiving a HELLO-RESP message, Alice adds the information of the sender into her NIT. Afterperforming the Neighbor Discovery process, the NITs should have the samestatus in 4.1.

4.1.5 Method 1 - Central

The Central method is the conventional method in NetInf. The reason it iscalled Central method in this thesis is that the information about where toretrieve an NDO centralizes in NRS server. When a client requests for an NDOin the network, it first sends out a GET message to NRS. Then the NRS willresolve the NDO name to locators and send these locators back to the client by aGET-RESP message. After receiving the GET-RESP from NRS, the client doesSource Selection locally, and then sends another GET request to the selectedsource. Finally, the NDO will be sent to the client by the source via a GET-RESP message.

Upon receiving a GET message, a NetInf node will check the conditions andperform one of following operations in order. Only the first matching operationwill be performed.

• (1) If the NDO requested is stored in the local cache, a GET-RESP mes-sage with NDO data will be generated and sent back to the requester;

• (2) If the node is NRS, it will resolve the NDO name into locators afterquerying the Name Resolution Service Table (NRST), then send a GET-RESP with locators to the requester;

• (3) If the node is the destination of the GET message and the requestedNDO is not in its local cache, a GET-RESP without NDO data will besent back to the requester, indicating the request is failed;

• (*) If no condition above is true, the node just forwards the message toits destination.

Upon receiving a GET-RESP message, a NetInf node will check the conditionsand perform one of following operations in order. Only the first matching op-eration will be performed.

• (1) If the GET-RESP message contains NDO data and the current nodedoes cache on path function, a copy of NDO will be stored into its localcache;

• (2) If the current node is the destination of the GET-RESP message withNDO data, the current node will empty the aggregation list and send outGET-RESP messages with NDO to the requesters aggregated;

• (3) If the current node is the destination of the GET-RESP message withlocators, the Source Selection process will be performed and another GET

14

message will be sent out to the best source location; (When Request Ag-gregation Mode = 1)

• (4) If the current node is the destination of the GET-RESP message withlocators, the node will send the GET-RESP to the requesters aggregatedand empty the aggregation list; (When Request Aggregation Mode = 2)

• (*) If no condition above is true, the current node only forwards the mes-sage to its destination.

The details about Request Aggregation are presented in Section 4.2.4.

4.1.6 Method 2 - Active

In the Active method, when a node caches a new NDO, it will send out NRSInformation Update (NIU). An NIU message contains the information aboutwhat NDOs are available at the sender host. It is an active way to populateName Resolution Information in the network, so it is called Active method.The Active method is designed to reduce the lookup time as well as take theadvantage of the NDOs that have already downloaded in the network to reducethe network load.

Upon receiving a GET message, a NetInf node will check the conditions andperform one of following operations in order. Only the first matching operationwill be performed.

• (1) (3) Same as Central method;

• (4) If the node can resolve the NDO name into locators using NRST, aSource Selection process will be performed and another GET message willbe sent out to the best source from the perspective of current node; (WhenRequest Aggregation Mode = 1)

• (5) if the node can resolve the NDO name into locators using NRST, aGET-RESP message with these locators will be sent back to the requester;(When Request Aggregation Mode = 2)



• (1) If the GET-RESP message contains NDO data and the current nodedoes cache on path function, a copy of NDO will be stored into its localcache and NIU messages will be sent to its neighbors in NIT;


• (5) If the current node is the destination of GET-RESP message withNDO data and it stores the NDO in its local cache, NIU messages will be

15

sent to neighbors in NIT;


Upon receiving a HELLO/HELLO-RESP message, a NetInf node will performthe following operation.

• (1) The node inserts the sender’s information of HELLO/HELLO-RESPinto its NIT after checking duplication. If the message type is HELLO,besides the updating of NIT, an HELLO-RESP with the information ofcurrent node will be sent back to the sender of HELLO.

Upon receiving an NIU message, a NetInf node will perform the following op-eration.

• (1) The TTL of NIU will be decreased by 1. The node will extract theName Resolution Information in NIU and add them into its NRST. If theTTL of the message is still greater than 1 after deduction, the node willsend the NIU to its neighbors in NIT.

4.1.7 Method 3 - Passive

In contrary to the Active method, a Passive method is proposed. The Passivemethod also populates Name Resolution Information in the network, but ina passive way. The passive method brings the information in NRS closer toclients. The Passive method is designed to make NDO names got resolved asearly as possible. Thus, the NDO retrieval time can be reduced.

Upon receiving a GET message, a NetInf node will check the same conditionsand perform the same operations in Active method.



• (5) If the GET-RESP contains locators and the node does cache NRSinfo on path, the node will extract Name Resolution Information from theGET-RESP and update its NRST.


4.1.8 Method 4 - Hybrid

The Hybrid method is a combination of Active and Passive method. It is pro-posed to find out if the combination of two methods turns out to be a betterperformance than one or two of them.

16

In Hybrid method, there are no new operations to be performed besides the Ac-tive and Passive method. Upon receiving a GET/HELLO/HELLO-RESP/NIUmessage, a NetInf node will perform the same operations in Active method.Upon receiving a GET-RESP message, a NetInf node will perform the sameoperations in Active method for messages with NDO data and Passive methodfor messages with locators.

4.1.9 Discussion

The Central method is not proposed in this thesis; it is the conventional methodin NetInf. It is used for comparison with other methods during the evaluations.

In the Active method, after finding the neighbors, an NIU is sent out once thenode gets a new cache. NIU is designed to carry one or more name resolutionentries. A name resolution entry is a name-locator binding. Thus, to reduce thesignaling overhead caused by NIU, NIU can be sent out periodically with morethan one name resolution entries.

The Passive method is inspired by Active method, but is designed to make thename resolved as early as possible without increasing the signaling overhead.

The Hybrid method takes both advantages in Active and Passive method inorder to achieve a better performance than any single one method.

4.2 Implementation

To evaluate a new or extension of a network protocol, it is straightforward touse a simulator, because the complexity and scale of the experiment are difficultto be deployed in the real world.

4.2.1 Message

NetInf is a message-based protocol; it provides functions such as forwardingrequests and responses, caching, and name resolution. The representations ofdifferent types of NetInf messages are also a fundamental part of the NetInfSimulator. Figure 4.2 shows the abstract structure of a NetInf message. Table4.1 shows different types of messages and their brief description.

The message with type value 5, 6 and 7 are not in the original NetInf protocol.They are proposed extensions to the protocol in order to help solve the problemaddressed in this thesis. PUBLISH and PUBLISH-RESP messages are onlyused to set up the initial state of the simulation during the warm-up period.

17

TYPENDO IDMETADATAKey: value...DATA(PAYLOAD)

Figure 4.2: Abstract Structure of a NetInf Message

Kind Type Short Description

1 GET Request to retrieve an NDO.

2 GET-RESP The response to GET. It should carry an NDO or a listof locators.

3 PUBLISH Publish an NDO to NRS.

4 PUBLISH-RESP The response to PUBLISH which contains the results ofthe operation.

5 HELLO Find the direct neighbor (within one NetInf hop).

6 HELLO-RESP Response to HELLO.

7 NIU Populate Name Resolution Information.

Table 4.1: Message Kind

4.2.2 Routing Function

To enable the NetInf routing function, the basic underlying routing functionneed to be implemented in the simulator. The lower layer routing functiondelivers a message to its destination according to the destination field of themessage via the shortest path.

NetInf supports both name-based routing and name resolution. Name-basedrouting is somehow pre-configured routing mechanism. For example, it canmatch the prefix of NDO’s name to decide which node it should be sent toor what is the next hop. In this thesis project, the name resolution service isimplemented for experiments. In the real world, these two routing mechanismscan be used simultaneously as a hybrid mechanism.

In the implementation, a NetInf node checks its local Name Resolution Informa-tion upon receiving a request. If it has the Name Resolution Information, it willsend the resolved information (source locators or routing hints) to the requesteror does Request Aggregation, according to the specific settings. Details aboutRequest Aggregation will be discussed in section 4.2.4.

4.2.3 Name Resolution

Name Resolution maps NDO names to network or host identifiers in differentname spaces, which is called routing hints. Routing hints are the informationabout where to find copies of the object. In NetInf, different kinds of routinghints are supported, such as IP addresses of the source node and pointers to

18

another node which has the information about the source nodes [6].

Figure 4.3 shows a simple example of the Name Resolution Service Table (NRST).It stores the name resolution information entires. Each entry in this table mapsan NDO name to a routing hint. For the thesis, routing hints stored in NRSTare the node addresses (which are integers) of the source nodes that have copiesof the NDO.

NDO ID

NI://EAB1400001

NI://EAB1400005

NI://KTH1400001

NI://KTH1400027

NI://KTH1400050

Publisher

Ericsson AB

Ericsson AB

KTH

KTH

KTH

Locator

5

5

6

6

6

Figure 4.3: Name Resolution Service Table (NRST)

The NRST is used not only by the Name Resolution Server (NRS), but alsonormal NetInf nodes. It means normal NetInf nodes can also have NRST toprovide services to other nodes for Name Resolution.

4.2.4 Request Aggregation

Request Aggregation is a very important feature in NetInf and other ICN ap-proaches, such as pending interest table in CCN [25]. Request Aggregation is amechanism to reduce network load. One case is a lot of users request the sameobject simultaneously. It might be a live streaming of a popular event. Withoutrequest aggregation, a large amount of traffic will be added to the infrastructureand the experience of users may be affected due to the high load.

For a NetInf node, all incoming requests for the same NDO are aggregated, anda single request for the NDO is sent outgoing. Figure 4.4 shows how RequestAggregation works. There are four clients requesting the same NDO at the sametime. The requests sent by Client 1 and Client 2 will be aggregated by NetInfrouter R1, and only one request will be forwarded to R0. The requests sent byClient 3 and Client 4 also follows the same pattern. In the end, NetInf routerR0 only sends one request to the source node S. To implement this function,the nodes that do request aggregation will create several aggregation lists foraggregating the requests for the same NDO. When the aggregation point receivesthe response, it will empty and delete the list after sending responses to all therequesters in the list. An aggregation list maintains the pending requests thathave been aggregated by a node for an NDO. It contains the information aboutwho is the requester and what object is requested. Figure 4.5 shows an example

19

1 2 3 4

Client Client Client Client

R1 R2

R0

S

Figure 4.4: Request Aggregation

of an aggregation list.

NDO ID

NI://EAB1400001

Requester

Node 1

Node 3

NDO ID

NI://EAB1400014

Requester

Node 4

Node 7

Node 2

Figure 4.5: Request Aggregation List

The destination of a request is rarely the source node in the network. Requestsare usually sent to NRS. Then, a response carrying routing hints (IP addressor locators) will be sent back by some node which can resolve the NDO namein the request message. In this case, the aggregation point has two choices.The first choice (Mode 1) is that the node does not empty the list; it sends outanother request using the routing hints. Source Selection may be performed inthis case if more than one routing hint is available. The second choice (Mode2) is that the node will empty the aggregation list and send routing hints backto the requesters aggregated. Figure 4.6 and 4.7 shows the sequence charts of

20

these two modes.

Client B Aggregation Point NRS Source

GET (to NRS)

GET (to NRS)

GET-RESP

GET (to SRC)

GET-RESP

GET-RESP

GET (to NRS)

Client A

GET-RESP

Figure 4.6: Request Aggregation (Mode 1)

Client B Aggregation Point NRS Source

GET (to NRS)

GET (to NRS)

GET-RESP

GET (to SRC)

GET-RESPGET-RESP

GET (to NRS)

Client A

GET-RESP

GET-RESP

GET-RESP

GET (to SRC)

GET (to SRC)

Figure 4.7: Request Aggregation (Mode 2)

Why are there two modes for Request Aggregation? Because there is no specificdefinition of Request Aggregation, it can be implemented in different ways.Some implementations may cause problems in NetInf network. In this project,Mode 2 is activated for all the methods.

4.2.5 Source Selection and Cost Model

In NetInf, there might be multiple copies of the same NDO stored in the network.When a client requests for an NDO, the client might receive a response that

21

contains many different source locations or routing hints. Then the client knowsthere are multiple copies (sources) available in the network. The client will dosome comparison among the source locations, and then it sends another requestto the best source location. The process of finding out the best source amongmany source locations is called Source Selection. When a client needs to doSource Selection, it should make the decision based on some knowledge. In theimplementation of the simulator, the Source Selection is done with the help ofpath cost. The path cost is computed from the link weights on the path. Figure4.8 shows how the Source Selection works.

NDO = “NI://KTH1400050”Locations = [3, 4]

3

1

210

3

4

+

Client

Source Source

1 3Weight from to = 3 + 10 = 13

1 4Weight from to = 3 + 7 = 10

∵ 10 < 13, ∴ is the best source.4

Figure 4.8: Source Selection based on Weight

4.2.6 Node

Figure 4.9 shows the basic architecture of a NetInf node. In the implementation,all nodes are sharing the same definition, but they can have different behaviorsgiven different initialization parameters.

4.2.7 Methods

There are four methods to be implemented in the simulator. Some components(handlers for messages) can be shared by more than one method. Figure 4.10show the composition of each method. ”GET (Central)” indicates the handlermethod for GET messages in Central method. More detail about how eachmethod is implemented in the simulator can be found in Appendix B.

22

Cache NRST NIT

Handler - GET

Handler - GET-RESP

Handler - PUBLISH

Handler - PUBLISH-RESP

Handler - HELLO

Handler – HELLO-RESP

Handler - NIU

Figure 4.9: Node Architecture

GET (Central)

GET-RESP with Data (Central)

GET-RESP with Locators (Central)

GET (Active)

GET-RESP with Data (Active)

GET-RESP with Locators (Central)

NIU (Active)

Neighbor Discovery

GET (Active)GET (Active)

GET-RESP with Locators (Passive)

GET-RESP with Data (Central)

GET (Active)

GET-RESP with Locators (Passive)

GET-RESP with Data (Active)

NIU (Active)

Neighbor Discovery

Central Active Passive Hybrid

Figure 4.10: Method Composition

23

Chapter 5

Evaluation

5.1 Scenarios

Simulations are conducted on two scenarios (tree scenario and mesh scenario)with Central, Active, Passive and Hybrid methods. The Central method is theconventional method in NetInf. Active and Passive are the methods developedin the thesis to distribute Name Resolution Information in the network. TheHybrid method combines the features of Active and Passive methods. Thescenarios are deployed in the NetInf simulator built in Chapter 4.

5.1.1 Network Topology

Two typical structures of topology are chosen for evaluation: tree and mesh.Tree topology is more like the network deployed in an organization and todaysInternet is more similar to mesh topology. Common parameters for both treeand mesh scenarios are shown in Table 5.1.

Parameter Value

# Nodes 26

# Clients 11

# Named Data Object (NDO) 500

Average Interval of request 100s

Simulation time per run 100000s

Simulation runs per method 100 times

Interval of log 1000s

Link bandwidth 1Mbps

Link propagation delay 100ms

Request Aggregation Mode 2

Table 5.1: Common Parameters

24

• Tree Topology

The structure of the tree topology is shown in Figure 5.1. Besides commonparameters, some specific parameters for tree topology are shown in Table 5.2.

5 96

0

16 24222115

NRS

SRC

25

2

10

3

7 8

13

4

1811 14 1712

SRC

19 20 23

SRC SRC SRC

1

Figure 5.1: Tree Topology

Node Type Value (Node index)

Router (Blue) 1, 2, 3, 4, 5, 6, 7, 8, 9

Client (White) 10, 11, 13, 14, 16, 18, 20, 21, 22, 24, 25

Source (Orange) 12, 15, 17, 19, 23

NRS Server (Green) 0

Table 5.2: Parameters for Tree Topology

• Mesh Topology

The structure of mesh topology is shown in Figure 5.2. Some specific parametersfor tree topology are shown in Table 5.3.

Node Type Value (Node index)

Router (Blue) 1, 2, 3, 4, 5, 6, 7, 8, 9

Client (White) 10, 11, 13, 14, 16, 17, 18, 20, 22, 23, 25

Source (Orange) 12, 15, 19, 21, 24

NRS Server (Green) 0

Table 5.3: Parameters for Mesh Topology

5.1.2 Content Objects

At the beginning of each simulation run, 100 distinct NDOs are generated ineach source node. Source nodes are represented by orange circles in Figure 5.1and Figure 5.2. All of the NDOs generated have the same size of 50,000 Bytes.For each NDO, a name is allocated. This name is selected from a set of 10000

25

5

3

8

0

22

14

16

1721

NRS

SRC13

9

25 1

7

4

23

2

20

1110

12

24

SRC

19 18

15 SRC

SRC

SRC

6

Figure 5.2: Mesh Topology

unique names. Thus, there might be some duplication of NDOs in the network.After the generation of NDOs on source nodes, the information of these NDOswill be published to NRS Server during the warm-up period of the simulation.It means these publish messages are not counted as signaling messages sincethey are used to set up the initial state of the simulation.

5.1.3 Requests

During the simulation, clients should send requests only for NDO names thatexist in the network. To ensure it happens, a list of names is generated duringthe warm-up period for objects that exist in the network. Each client determineswhich NDO to request at random following uniform distribution from availableNDO names in the network. Each client requests an NDO at an exponentiallydistributed random interval. The average interval is 100 seconds.

5.1.4 Packet Length

The length of each packet is computed dynamically according to what is con-tained in the packet. Appendix C shows the packet length specification forpackets. The propagation delays are same for all links, which is 100ms. Packetlength affects the transmission delay of the packet; thus the big packets willsuffer high network delay than small packets.

26

5.1.5 Compared Methods

Following four methods are compared: Central method, Active method, Passivemethod, Hybrid method. There is nothing technologically novel about the Cen-tral method. The Central method is only used as a reference for comparison toevaluate the effectiveness of the other methods in terms of overhead and latency.

5.1.6 Warm-Up Period

When the simulation is started, it first enters warm-up period. In order to buildup the initial state of the simulation, following actions are performed during thisperiod.

• Source nodes generate NDOs and publish them to NRS. All the NDOs inthe source nodes are published to NRS during this warm-up period.

• In Active method, the source nodes send NIU messages to neighbors aftergeneration all the NDOs. All the NIU messages sent during the warm-upperiod arrive their destination within the period.

After the warm-up period, the first GET request will be sent out by the clientin the network. The messages transmitted during this period are ignored in thesimulation results.

5.2 Results

After running the simulation for 100 times for every method on the tree andmesh scenarios with different random seeds, the data collected is utilized togenerate metrics. The random seeds are used to increase the randomizationfor each simulation runs. For each simulation run, a random seed is used togenerate NDOs and requests. The results are shown in Figure 5.4, 5.5 and 5.6.

Client NRS Source

GET (to NRS)

GET-RESP

GET (to SRC)

GET-RESP

NRT = t1 – t0

t0

t1

Figure 5.3: NDO Retrieval Time

27

NDO Retrieval Time (NRT) and Signaling overhead metrics are generated toshow the performance of each method in different scenarios. As shown in Figure5.3, NRT is the time cost to retrieve an NDO after sending out the initial GETrequest to NRS by a client.

5.2.1 NDO Retrieval Time

Figure 5.4 shows the frequency of NRT for all methods in tree and mesh sce-narios.

(a) Tree scenario (b) Mesh scenario

Figure 5.4: NDO Retrieval Time (frequency)

As can be seen in the Figure 5.4(a), there are some peaks in the graph. Forexample, the Central method (blue solid line) has three peaks. Two of themare near 2*105, and the last one is near 6.5*105 on the Y-axis. Thus, the higherpeak is nearly twice higher than the small peaks. It is reasonable in the treescenario. Since the requests are generated following the uniform distribution, itmeans each source node may have the same chance to receive a request. In thetree topology shown in Figure 5.1, if a client (for example, node 10) requestsfor an NDO, the NRT mainly depends on from which source node the NDO isretrieved. From the perspective of Node 10, Node 12 is two hops away. Node 15is four hops away, and Node 17, 19, 23 are all six hops away. Since the bandwidthis same for all the links in the simulation, the transmission time of the NDOmainly dominates the NRT. Therefore, in the graph there are two small peaksand one big peak. For other methods, they all have three peaks. The reason forthe peaks is same. One may notice the Active method is shifted left compared toCentral method. It means Active method has a better performance than Centralmethod from this graph. The Passive method is shifted left farther than Activemethod compared to Central method. It might have a better performance thanActive and Central method. The Hybrid method nearly covers the first twopeaks with Active method and third peak with passive. It is caused by thecombination of the feature of the Active method and Passive method to achievebetter performance than these two. In Figure 5.4(b) , Active, Passive andHybrid method all have a smaller NRT compared to Central method, but the

28

differences between each other are not very clear.

Figure 5.4 can be used to get a general overview of the performance of eachmethod in different scenarios. In order to know more what is happening duringthe simulation. Figure 5.5 is introduced.


Figure 5.5: NDO Retrieval Time (interval)

The simulation runs for 100,000 seconds (virtual time in the simulator), and thelogging operation is performed every 100 seconds. This results in 100000/1000=100intervals. In other words, the simulation can be divided into 100 equal lengthintervals in order to find out the interesting results in each interval. In Figure5.5 the X axis is the interval number of simulation, and the Y axis is the averageNRT during that interval.

Figure 5.5(a) shows the NRTs for each simulation interval in the tree topology.Since the information about NDOs in source nodes are already populated intothe network by Active method during the warm-up period, the Active methodhas a stable NRT time near 3.35 seconds from the beginning to the end ofthe simulation. For Central method, the NRT time is always near 3.7 secondsbecause there is no information about the NDO locations is exchanged or cachedas in Active or Passive method. At the beginning of the simulation, the NRT ofPassive method is nearly the same as Central method, but it decreases with theincrease of the interval number. During interval 60 to 100 it becomes stable.Since there is no memory limitation of caching Name Resolution Informationin nodes for the Passive method, all the information saved in NRS server willbe cached in the network eventually. That is the reason the Passive methodbecomes stable during interval 60 to 100. During interval 1 to 10, the Activemethod has a lower NRT than the Passive method. It is because during theseintervals, the Active method has already cached enough information about theNDO locations, while the Passive method just starts to cache Name ResolutionInformation. After interval 10, the Passive method has a lower NRT than Activemethod. It is because the Name Resolution Information exchanged by NIU inthe Active method can only cover parts of the tree topology, while the Passivemethod can bring Name Resolution Information to all the nodes eventually.For Hybrid method, it has the same start point as Active method and the

29

NRT decrease faster than Passive method. It is because before caching theName Resolution Information on path by Passive method feature, some NameResolution Information populated by the Active method already exist in thenetwork. All of the methods proposed obviously have lower NRT than Centralmethod, but which method has the best performance depends on many factors,such as the simulation length. If the simulation runs for only the first tenintervals, the Passive method will never perform better than Active method.Compare to Active and Passive methods, the Hybrid method always betterthan any of them, since it takes the advantage of each method.

Figure 5.5(b) shows the NTR for each simulation interval in mesh topology. ThePassive method follows the same trend as in the tree scenario. One thing tobe highlighted is the Active method nearly has the lowest NRT from beginningto the end of the simulation. The reason that it looks quite different from thegraph of tree topology is that the population of Name Resolution Informationby Active method may cover nearly all the nodes in the network in the meshtopology. The TTL of NIU used in the Active method is 3. In the mesh topology,most of the node can be reached within three hops. Thus, the initial state of thesimulation for Active method is quite different from the tree scenario. In treescenario, the population of Name Resolution Information during the warm-upperiod can only reach the subtree where the sender resides.

5.2.2 Signaling Overhead

Figure 5.6 shows the signaling overhead for all the methods in the tree and meshscenarios. The interval number has the same meaning as Figure 5.5 in Section5.2.1. The signaling data ratio is calculated by the following equation. Thesignaling data includes NRS look-up and response messages, Neighbor Discoverymessages and GET requests (to source).

Signaling Data Ratio =Signaling Data Transmitted in the Network

Total Data Transmitted in the Network

Both in tree and mesh scenarios, the Central method has a higher signalingoverhead compared to other methods. One thing to be noticed is in Activemethod no NIU messages are sent out by clients during the simulation sincethe clients do not save the NDO after retrieving it and no node caches NDOon path. For the Active and the Passive method, once the Name ResolutionInformation is cached in nodes in the network, the subsequent NRS look-uprequests would not have to traverse links all the way to the NRS. NRS look-upscan be resolved by nodes on path and hence reduce the signaling. The periodicalNeighbor Discovery process causes the small peaks in Active method curve. Inthe simulation, the interval between two Neighbor Discovery processes is set to300 seconds, in which nodes broadcast messages to the network to find theirneighbors.

In Figure 5.6(a), the signaling overhead of Passive method decreases betweeninterval 1 to 60, and become stable after interval 60. The trend in 5.6(a) is

30


Figure 5.6: Signaling Data Ratio (interval)

due to similar reasons for trend in Figure 5.5(a). The Passive method needssome time to populate the Name Resolution Information in the network. Infigure 5.6(b), the Hybrid method has the similar trend of the Active method.This is caused by the mesh topology. In mesh topology, the Name ResolutionInformation are populated to most nodes in the network during the warm-upperiod, therefore, the information will be used to resolve NDO names in thenetwork and only a small part of requests are sent to NRS and get resolved. Inthis case, that is the reason the Hybrid method curve is just slightly below theActive method and does not have a similar trend as the Passive method.

5.3 Discussion

In the simulation, the network is static, and the content object are always avail-able, which is quite different from the real world. In the real word, the networkis dynamic with nodes joining and leaving and content might be available onlyfor a short period. Thus, it is not possible to say which method is the best allthe time. It depends on the network situation and the structure of the network.For example, in Figure 5.5(a), if the churn of the network is very big, the NRTmay keep suffering from the same situation of interval 1 to 10. An algorithmmay work well in one topology but not in the other. For example, as shownin 5.5(a) and 5.5(b), the Active method performs better in the mesh topologythan tree topology.

31

Chapter 6

Conclusion and FutureWork

6.1 Conclusion

The goal of the research in this thesis is to investigate different possible methodsfor improve the performance of NetInf network by distributing Name ResolutionInformation to nodes in the network. The methods proposed are evaluated onthe tree and mesh topologies. The tree topology is more like the network in anorganization; the mesh topology is more like today’s Internet. The design andthe implementation of the methods are only used for experiments. If someonewant to deploy these methods in real-world networks, more factors need to beconsidered, for example, the expired information about NDO. Even though themethods proposed in the thesis is more experimental, the evaluations of thesemethods could lead to a better understanding of what can be done for improvingthe performance of NetInf networks.

The Active, Passive, and Hybrid methods enable clients to resolve the NDOnames in a more efficient way than the Central method. From the results pre-sented in Chapter 5, it is obvious all of the two proposed methods and theircombination have better performance than Central method on NDO RetrievalTime and signaling overhead. The performance of each method is also affectedby the topology it is deployed in. Some deduction may be made from the results.If the network is static (node rarely joins and leaves) and the running time isvery long, the Passive and Hybrid method might have better performance thanActive method in the tree topology; however, if the network is more dynamic(nodes join and leave very often), the Passive method might suffer from it andhave a worse performance than Active method. In mesh topology, if the scaleof the network is relatively small or the TTL of NIU in Active method is verylarge, the Active method tends to have better performance than Passive method,but the population of Name Resolution Information may increase the signalingoverhead of the network. The TTL value of NIU messages in Active methodshould be a trade-off between lower latency and higher signaling overhead.

32

To conclude, all of the two methods proposed and the combination can be usedto reduce the NRS lookup time and the network utilization, but the effectivenessof each method depends on the network topology and configurations. There isno best method for all the scenarios. Even though the Hybrid method seems tobe better than Active and Passive methods in both tree and mesh scenarios, itis not safe to say the Hybrid method is always the best one among them. Inthe evaluations conducted, some other factors that may affect the performanceare not considered, such as computation overhead. Because the node needsto maintain the Name Resolution Information, it will cost some computingresources. When the scale of the network becomes very large, the computationoverhead cannot be ignored. More experiments on different factors that affectthe performance can be done in the future.

6.2 Future Work

6.2.1 More Complicated Cost Model

In this thesis, the cost model is only related to the bandwidth of links. Theweights of links are the measurements of cost used in the cost model. Thus, theweights of links are only decided by the bandwidth. In future, CPU overload,storage, available bandwidth and payment cost can also be introduced into thecost model. Base on these factors, the node can calculate its weight value, whichwill be used by Source Selection process. It means one is easy to replace thecost model with another one without changing the other part of the simulator.In other words, the cost model is decoupled with the simulator and can beimproved according to the requirement.

6.2.2 Dynamic Networks

To reduce the complexity of the work, the topologies in the thesis are static forthe experiments. In the real world, the networks are mostly dynamic, whichmeans there are nodes joining and leaving the network. In addition, NDOscan also be created and destroyed dynamically in the network. As discussedin Chapter 5, if the network is very dynamic, the performance of the methodsmight be quite different. More experiments on topologies more similar to thereal world can be done in future work.

6.2.3 NRS Information Update

NRS Information Update (NIU) is an extension to NetInf Protocol used byActive method. It is used to populate Name Resolution Information to theneighbors of nodes in the network. In the experiments of the thesis, the TTL ofthe NIU message is 3. The TTL value affects how far away an NIU messages willbe spread in the network. Thus, if one increases the value of TTL, more NIUmessages will be transmitted over the network. If the TTL is too big, it may

33

flood the network. Setting the value of TTL is a trade-off between performanceand overhead. More experiments on different TTL values can be done in thefuture to find out what is the trade-off.

6.2.4 Network Caches

In the simulation, there are no nodes in the network that caches actual NDOobjects. The number and the location of network caches will impact on the per-formance and overhead. For Active (also Hybrid) method, more network cacheswould mean more signaling overhead as more NIU messages will be generated.But they would also mean lower latency.

34

Bibliography

[1] 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.

[2] L. Sunde, “NetInf Node for Bluetooth Enabled Android Devices,” 2013.

[3] 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.

[4] T. Koponen, M. Chawla, B.-G. Chun, A. Ermolinskiy, K. H. Kim,S. Shenker, and I. Stoica, “A Data-oriented (and Beyond) Network Ar-chitecture,” in Proceedings of the 2007 Conference on Applications, Tech-nologies, Architectures, and Protocols for Computer Communications, SIG-COMM ’07, (New York, NY, USA), pp. 181–192, ACM, 2007.

[5] S. Tarkoma, M. Ain, and K. Visala, “The Publish/Subscribe Internet Rout-ing Paradigm (PSIRP): Designing the Future Internet Architecture.,” inFuture Internet Assembly, pp. 102–111, 2009.

[6] Bengt Ahlgren, Matteo D. Ambrosio, Elwyn Davies, Anders E. Eriksson,Stephen Farrell, Hannu Flinck, Claudio Imbrenda, Bruno Kauffmann, Ger-ald Kunzmann, Dirk Kutscher, Anders Lindgren, Ian Marsh, Luca Mus-cariello, Hugo Negrette, Brje Ohlman, Karl-ke Persson, Petteri Pyhnen,Jarno Rajahalme, Mohammed Shehada, Miguel Sosa, Dirk Staehle, OveStrandberg, Janne Tuononen, and Vinicio Vercellone, “Final Netinf Archi-tecture,”

[7] D. Kutscher, S. Farrell, and E. Davies, “The NetInf Protocol.” http:

//tools.ietf.org/id/draft-kutscher-icnrg-netinf-proto-01.txt.Accessed: 2014-12-12.

[8] H. Negrette Otaola and M. Sosa, Using Multiple Transport Networks inNetInf Enabled Android Devices. 2012.

[9] A. Eriksson, B. Ohlman, and K.-A. Persson, “What are the services of aninformation-centric network, and who provides them?,” in AP2PS 2012,The Fourth International Conference on Advances in P2P Systems, pp. 11–17, 2012.

35

http://tools.ietf.org/id/draft-kutscher-icnrg-netinf-proto-01.txt

http://tools.ietf.org/id/draft-kutscher-icnrg-netinf-proto-01.txt

[10] “The FP7 4ward Project.” http://www.4ward-project.eu/. Accessed:2015-03-03.

[11] “4ward NetInf.” http://www.netinf.org/4ward-netinf/. Accessed:2015-03-03.

[12] “SAIL NetInf.” http://www.netinf.org/sail-netinf/. Accessed: 2015-03-03.

[13] “SAIL.” http://www.sail-project.eu/. Accessed: 2015-03-03.

[14] Stephen Farrell, Dirk Kutscher, Christian Dannewitz, Borje Ohlman, AriKeranen, and Phillip Hallam-Baker, “Naming Things with Hashes.”

[15] M. Ihlar, “Erlang NetInf Network Node,” 2014.

[16] X. N. Nguyen, D. Saucez, and T. Turletti, “Efficient caching in content-centric networks using OpenFlow,” in IEEE INFOCOM 2013 Workshop,pp. 1–2, 2013.

[17] E. Rosensweig and J. Kurose, “Breadcrumbs: Efficient, Best-Effort ContentLocation in Cache Networks,” in IEEE INFOCOM 2009, pp. 2631–2635,Apr. 2009.

[18] M. Kakida, Y. Tanigawa, and H. Tode, “Active breadcrumbs: Aggres-sive distribution method of in-network guidance information for content-oriented networks,” in 2012 IEEE 37th Conference on Local Computer Net-works (LCN), pp. 184–187, Oct. 2012.

[19] K. Hashimoto, Y. Takaki, C. Ohta, and H. Tamaki, “In-network Hop-aware Query Induction Scheme for Implicit Coordinated Content Caching,”pp. 69–73, Aug. 2011.

[20] M. Kakida, Y. Tanigawa, and H. Tode, “Breadcrumbs+: Some Extensionsof Naive Breadcrumbs for In-network Guidance in Content Centric Net-works,” in 2011 IEEE/IPSJ 11th International Symposium on Applicationsand the Internet (SAINT), pp. 376–381, July 2011.

[21] H. Kawabata, K. Hashimoto, T. Inamoto, Y. Takaki, C. Ohta, andH. Tamaki, “Content/Location Mapping with Cache-Location Resolutionfor In-network Guidance,” pp. 1–6, Aug. 2012.

[22] W. K. Chai, D. He, I. Psaras, and G. Pavlou, “Cache Less for Morein Information-Centric Networks,” in NETWORKING 2012 (R. Bestak,L. Kencl, L. E. Li, J. Widmer, and H. Yin, eds.), no. 7289 in Lecture Notesin Computer Science, pp. 27–40, Springer Berlin Heidelberg, 2012.

[23] “OMNeT++ network simulation framework.” http://omnetpp.org/. Ac-cessed: 2014-12-12.

[24] “MATLAB - the language of technical computing.” http://se.

mathworks.com/products/matlab/. Accessed: 2014-12-11.

[25] H. Dai, B. Liu, Y. Chen, and Y. Wang, “On Pending Interest Table inNamed Data Networking,” in Proceedings of the Eighth ACM/IEEE Sympo-

36

http://www.4ward-project.eu/

http://www.netinf.org/4ward-netinf/

http://www.netinf.org/sail-netinf/

http://www.sail-project.eu/

http://omnetpp.org/

http://se.mathworks.com/products/matlab/

http://se.mathworks.com/products/matlab/

sium on Architectures for Networking and Communications Systems, ANCS’12, (New York, NY, USA), pp. 211–222, ACM, 2012.

37

Appendix A.

Terminology

ICN: Information-Centric NetworkingCCN: Content Centric NetworkingDONA: Data Oriented Network ArchitecturePSIRP: Publish/Subscribe Internet Routing ParadigmNetInf: Network of InformationCL: Convergence LayersNDO: Named Data ObjectGET: Request to fetch an NDOGET-RESP: Response to GETPUBILISH: Publish an NDO to NRSPUBLISH-RESP: Response to PUBLISHHELLO: Message used to discover NetInf neighborsHELLO-RESP: Response to HELLORA: Request AggregationNRS: Name Resolution ServiceNIU: NRS Information UpdateNRT: NDO Retrieval TimeNIT: Neighbor Information TableNRST: Name Resolution Service TableLRU: Least Recently UsedIETF: Internet Engineering Task ForceIP: Internet ProtocolKPI: Key Performance IndicatorOSPF: Open Shortest Path FirstBGP: Border Gateway ProtocolPKI: Public Key InfrastructureTCP: Transmission Control ProtocolUDP: User Datagram ProtocolURI: Uniform Resource IdentifierURL: Uniform Resource LocatorNED: Network Description

38

Appendix B.

Method Description

I - Central Method

upon r e c e i v e get ( message m)i f check ( cache , m. ndo id ) i s t rue then

send get−re sp ( data ) to m. s r c ;r e turn ;

i f m. dest i s s e l f thensend get−re sp ( ndo not found ) to m. s r c ;r e turn ;

i f check ( aggregation mode , m. tag ) i s t rue theni f check ( reqa , m. ndo id ) i s t rue then

add ( reqa , m. ndo id , m. s r c ) ;else

c r e a t e ( reqa , m. ndo id , m. s r c ) ;m. s r c := s e l f ;send m to m. dest ;

else send m to m. dest ;

upon r e c e i v e get−re sp ( message m)i f check ( cache on path , m. ndo data ) i s t rue then

add ( cache , m. ndo data ) ;i f m. dest i s s e l f then

i f check (m. data ) i s t rue theni f check ( reqa , m. ndo id ) i s t rue then

r ep ly ( reqa , m. data ) ;p roce s s (m. data ) ;

else i f check (m. n r s e n t r i e s ) i s t rue theni f aggregat ion mode i s 1 then

best := s e l e c t (m. n r s e n t r i e s ) ;send get (m. ndo id ) to best ;

else i f aggregat ion mode i s 2 thenr ep ly ( reqa , m. n r s e n t r i e s )


39

upon r e c e i v e pub l i sh ( message m)i f m. dest i s s e l f then

i f check ( nrst , m. ndo id , m. ndo l o ca t i on ) i s f a l s ethenadd ( nrst , m. ndo id , m. ndo l o ca t i on ) ;send publ i sh−re sp (m. ndo id , s t a t u s ) to m. s r c ;


upon r e c e i v e publ i sh−re sp ( message m)i f m. dest i s s e l f then

proce s s (m. s t a t u s ) ;else send m to m. dest ;

40

II - Active Method






c r e a t e ( reqa , m. ndo id , m. s r c ) ;i f check ( nrst , m. ndo id ) i s t rue then

n r s e n t r i e s := get ( nrst , m. ndo id ) ;i f aggregat ion mode i s 1 then

m. dest := s e l e c t ( n r s e n t r i e s ) ;m. s r c := s e l f ;send m to m. dest ;

else i f aggregat ion mode i s 2 thensend get−re sp ( n r s e n t r i e s ) to m. s r c ;

elsem. s r c := s e l f ;send m to m. dest ;

else i f check ( nrst , m. ndo id , m. tag ) i s t rue thenn r s e n t r i e s := get ( nrst , m. ndo id ) ;send get−re sp ( n r s e n t r i e s ) to m. s r c ;



add ( cache , m. ndo data ) ;send niu to ne ighbors in nr s t ;

i f m. dest i s s e l f theni f check (m. data ) i s t rue then

i f check ( reqa , m. ndo id ) i s t rue thenr ep ly ( reqa , m. data ) ;

p roce s s (m. data ) ;else i f check (m. n r s e n t r i e s ) i s t rue then

i f aggregat ion mode i s 1 thenbest := s e l e c t (m. n r s e n t r i e s ) ;send get (m. ndo id ) to best ;




41





upon r e c e i v e h e l l o ( message m)i f check ( nit , m. node address ) i s f a l s e then

add ( nit , m. node address ) ;send he l l o−re sp ( s e l f ) to m. s r c ;

upon r e c e i v e he l l o−re sp ( message m)i f check ( nit , m. node address ) i s f a l s e then

add ( nit , m. node address ) ;

upon r e c e i v e niu ( message m)i f check ( r e c e i v e n i u ) i s t rue then

i f check ( nrst , niu . n r s e n t r i e s ) i s f a l s e thenadd ( nrst , niu . n r s e n t r i e s ) ;

i f check ( forward niu , niu . t t l ) i s t rue thendec rea se ( niu . t t l ) ;s end to ne i ghbo r s ( niu , p o l i c y ) ;

42

III - Passive Method














add ( cache , m. ndo data ) ;i f check ( save nrs on path , m. n r s e n t r i e s ) i s t rue

thenadd ( nrst , m. n r s e n t r i e s ) ;







upon r e c e i v e pub l i sh ( message m)

43

i f m. dest i s s e l f theni f check ( nrst , m. ndo id , m. ndo l o ca t i on ) i s f a l s e

thenadd ( nrst , m. ndo id , m. ndo l o ca t i on ) ;send publ i sh−re sp (m. ndo id , s t a t u s ) to m. s r c ;




44

IV - Hybrid Method














add ( cache , m. ndo data ) ;send niu to ne ighbors in nr s t ;

i f check ( save nrs on path , m. n r s e n t r i e s ) i s t ruethenadd ( nrst , m. n r s e n t r i e s ) ;







45






upon r e c e i v e niu ( message m)i f check ( r e c e i v e n i u ) i s t rue then

i f check ( nrst , niu . n r s e n t r i e s ) i s f a l s e thenadd ( nrst , niu . n r s e n t r i e s ) ;

i f check ( forward niu , niu . t t l ) i s t rue thendec rea se ( niu . t t l ) ;s end to ne i ghbo r s ( niu , p o l i c y ) ;

46

Appendix C.

Packet Length Specification

Packet Field Length Total

NetInf

source 4 Bytes

16 Bytesdestination 4 Bytes

netinf ttl 4 Bytes

kind 4 Bytes

GETndo id 16 Bytes

36 Bytes

tag 4 Bytes

GET-RESP

ndo id 16 Bytes 32 Bytes

+ Sizeof(ndo sources)

+ Sizeof(data)

ndo sources Sizeof(ndo sources)

data Sizeof(data)

HELLO node name Sizeof(node name) 16 Bytes + Sizeof(node name)

HELLO-RESP node name Sizeof(node name) 16 Bytes + Sizeof(node name)

NIUndoIds[] Sizeof(ndoIds[])

20 Bytes + Sizeof(ndoIds[])

origin 4 Bytes

47

name resolution information distribution in...

Documents