Home

Welcome to your wiki!

This is the default page, edit it as you see fit. To add a page simply reference it within brackets, e.g.: [SamplePage].

The wiki uses Markdown syntax.

[Nikolaos Vastardis]

Introduction

In this page, the Information-Centric Network Simulator developed by the University of Essex, for the needs of the PAL, project is presented. The project is driven by a clear platform-oriented vision, in which user and system requirements specific to the area of lifestyle monitoring and assisted living are used to carefully extend capabilities of the underlying platform and prototyping novel concepts in a realistic setting. The platform work can be divided into information-centric environment and communication environment.

The information-centric environment deals with information gathering, processing, presentation and governance. A publish subscribe scheme has been created therefore, more specifically by extending the Blackadder information-centric networking environment. One of the most important additions and a vital part of the project was the link-aware Information-centric Topology Management. However, physical limitations arise while testing and validating the effectiveness of the proposed additions. Therefore the ICN Simulator was introduced. It is able to simulate a large number of nodes and publisher-subscriber pairs and produce a huge amount of information, providing an insight on the new techniques introduced in the topology management of the information-centric network.

Installation

Before trying to install the ICN_Sim, you first have to have OMNET++ simulation environment and INET framework already up and running in your system. For more information on that you can check:
for OMNET++ --- http://www.omnetpp.org/documentation
for INET --- http://inet.omnetpp.org/index.php?n=Main.Download

After you have completed all the above steps, you can use download the compressed ICN_Sim. In order to import the simulator into OMNET++ you just have to follow a simple procedure. First you go to File->Import and choose General->Existing Projects intro Workspace. After that, select the archive file and find the downloaded ICN_Sim tar file. Press finish and you have made it! The only thing left it to build the download project. To do this, you need to go to Run->RunConfiguration... and create a new configuration by double clicking on the OMNET++ Simulation element on the left side list. Change the name of the configuration that you will see and choose the following as your working directory:

/ICN_Sim/simulations

Afterwards, choose the General option in the "Config name" drop down menu and press run. That should be it.

The ICN_Sim

After you have successfully downloaded and built the simulator, there are many thing that you can play with. The simplest thing is to change the configuration parameters. In case more specific changes have to be made, the code defining the modules, or their functionality can be also altered. In this section a quick introduction in these module and their basic parameters is given. Beforehand, a introduction on the Information Items is given in order to provide a better insight on what Publish Subscribe actually means, More information are provided inside the documentation located in the ''doc'' folder of the simulator. Moreover it is suggested that you read the simulator report, also provided in the repository.

The Information Items

An important notion that has to be introduced before a more detailed description of the simulator is given, is the Information Item. This defines every piece of information in every publish-subscribe network. It is the identification of every file or stream passing though the network. In real publish-subscribe networks, Information Items can be grouped into scopes and users can publish or subscribe to one or more. For example, a user can be interested in the Information Item defining the "news", while someone else might be interested in more refined objects, such as the "University of Essex news". In order to provide such a refinement, the Information Item definition contains two fields. The Information ID and the Scope ID. The length of the Information ID is standard (in the ICN Simulator's case is 8 bytes), while the scope ID has a variable length in order to refine scopes as much as desired. An example of the Information Item definition format is given below.

---------Scope--------/Item
DDDD/CCCC/BBBB/AAAA

One more field is included in the simulation Information Item class though, representing its popularity. Such a field is useless in real publish-subscribe environments since users express their own preferences, but in the simulation environment is very important. This way publishers and subscribers can show preference in more popular items than others less popular.

In Blackadder, Information Items form inter-connected trees with multiple root scopes, sub-scopes and leaves. However, for the needs of this simulation, none of these is necessary. It has already been mentioned that the primary target of this part of the project is to test and validate the novel Topology Management policies. Therefore, there is no interest in whether a piece of information sent through the network belongs to a certain scope or a unique Information Item. Consequently, only Information Items belonging to a random scope are considered to be requested and sent by the publishers and the subscribers. This assumption however, obviously does not affect at all the validity of the results.

Another assumption made, is that only data streams are generated as traffic in the examined information-centric network. File transfers have not been taken into consideration. This approach, on the one hand, is followed because Blackadder does not support file transfers as well. On the other have, such an attempt would complicate the publish subscribe operation significantly. For example, if two subscribers requested the same file from the same publisher, but with a time difference, then the publisher would have to request one FID per subscriber from the Topology Manager. This would happen because until the second subscriber subscribed in the published Information Item, the first subscriber would have already received the first packets of the file. Therefore, the publisher would later on have to send different pieces of the same file to the two destinations, requiring two FID from the Topology Manager, one for every destination.

Simulation Parameters

The main parameters than control the simulation can be viewed and accessed from the omnetpp.ini file. The most important ones are the following:

• numRouters: The number of routers involved in the simulation.

• numPubs: The number of Publishers involved in the simulation.

• numSubs: The number of Subscribers involved in the simulation.

• Datarate: The maximum datarate of the connections between the various modules.

• startTime: The time at which the publishing application will start.

• pubInterval: The interval at which the Publishers with changes their publication list.

• subInterval: The interval at which the Subscribers with changes their subscription list.

Note that these parameters are owned by different modules. However, they have a unique name so that they can be accessed individually, without naming the owner module first.

Modules

PSRouter

The PSRouter, is able to support a number of Ethernet interfaces, each for every link to another network module. Every link is characterized with a random Link ID (LID) of 64 bits. All the interfaces have an output queue and a module simulating the IEEE 802.3 MAC layer. Another extra module (Throughput Meter) is used for monitoring the link QoS statistics, in order to achieve link-awareness.

The details of every link are kept in the Interface Table of the Publish Subscribe Router, while the LIDs are kept in a different table, namely the Forwarding Table, which is represented by the module FwTable. The Forwarding Table also stores some quality statistics for each link, such as standard cost values. All the quality metrics mentioned so far, are gathered by the Link Monitoring sub-module and sent to the Topology Manager using messages of specific format. Messages of similar format are used in Blackadder for nodes to report their QoS statistics.

All the sub-modules mentioned above are mainly only tools used by the Forwarder module. This provides the basic functionality of the router, which is to choose the correct forwarding links. Consequently, the Forwarder receives the packets from the link layer and compares their Forwarding IDs with the existing LIDs of the router. Whenever there is a match, the Forwarder sends a copy of the received packets down that link. A problem exists with false positives matches, but choosing a proper random seed should fix the problem. Additionally a small fix in the Forwarder that prohibits messages to be forwarded to the link from where they came from, minimizes the changes of problematic situations and loops because of false positives.

PubHost

The Publisher is very simple module consisting only of a number of Ethernet interfaces and an application running on top of each interface. This structure has been followed because every link is considered to be different and so every application should be distinguished from the others. On the other hand, every application is able to create multiple publications. The publishers, as well as the subscribers, have been designed in this way, in order to provided the maximum scalability and expandability in the simulation environment as possible.

Each link of a Publisher is connected with only one Publish Subscribe Router. The LID of the link from the router to the Publisher is generated from the router. On the contrary, the LID of the link leading from the Publisher to the router should be assigned by the Publisher itself. However, the Publishers do not have such an ability. Therefore, in the Topology Manager, these links are represented by the same non-random LID. This does not affect the forwarding though, as there is no forwarder module present previous to these link and packets generated by the applications are automatically send down. The same applies for the Subscribers, but this is an even simpler case, since they don't generate any packets.

The Publishing Application, named pub, creates publications according the the normal Gaussian distribution, defining the most probable time of publishing. The mean of this distribution is given as in input parameter in the "omnetpp.ini" file. This publications are also deleted according again to a Gaussian distribution. The mean value of that distribution is arbitrarily chosen to be equal to double the value of the mean used for the publication generation process. This whole process is periodically repeated. The implemented traffic model aims at generating spikes of traffic congestion in the network, in order to determine the effectiveness of the Topology Manager policy.

Every time a new publication is set to be made, the Publishing Application has to determine whether to publish a new Information Item or to provide a publication on an existing Information Item. This choice is made randomly. In case an existing Information Item is chosen, one of the Information Items from the global Information Items Table is chosen according to it's popularity. Afterwards, whether new or not, the Information Item Table is informed of the new publication made. This is done by calling a public C++ function of the Information Item Table. The same procedure takes place when a Publishing Application deletes a publication made in the past.

SubHost

The Subscriber module is very similar to the Publisher one, with the difference that it does not generate any traffic. However the subscription generation process is exactly the same as the publication one and also follow a Gaussian distribution, with parameters stated in the "omnetpp.ini" file. The module is also constituted by a number of Ethernet interfaces, the same as those of the Publisher module and a number of subscribing applications, one for each interface. Each application is able to subscribe to multiple Information Items.

After a subscription in made, the Subscriber waits until it receives a data stream from the network. It has no information whether the subscription can be met by a set of Publishers or not. After beginning to receive a stream, the subscriber application called sub acts as a sink. The only additional functionality of the subscriber application is to record the received stream packet statistics, such as the end-to-end delay.

IITable

The Information Item Table performs the operation which in Blackadder is embedded inside the Rendezvous node. In simple terms, it performs the job of an accountant. It maintains the record of all publish and subscribe requests made in the network. However, unlike the way Blackadder operates, in the Information-Centric Network Simulator there is no categorization of the Information Items in scopes, therefore, the Information Item Table is just a registry of the items the publishers and subscribers generate, along with their affiliations.

Although the Information Item Table does not have any ports and is not supposed to receive messages, it has the ability to send messages of specific format to the Topology Manager. This is how it informs the manager of new matches between publications and subscriptions (including cases where nodes delete their publications or subscriptions).

SubModules

PEtherApp:
This publisher application needed in every publisher node in a publish subscribe network. It works just over the MAC layer, and this is why it is necessary to implement MAC encapsulation. It is able only to publish new or existing Information Items, kept in an Information item table.

SEtherApp:
This subscriber application is similar to the PEtherApp. It works just over the MAC layer, and this is why it is necessary to implement MAC encapsulation. It is able only to subscribe to new or existing Information Items, kept in an Information item table.

Forwarder:
The Forwarder has is no interaction with higher layers. Everything for the Forwarded is quite flat. All the links, even for higher layer protocols are identified by an LID. If the received message's FID matches this LID, then the message will be forwarded through that link.

FWTable:
This is where the forwarding table of every router is stored.

LinkMon:
The Link Status Monitoring module. It can access almost every other submodule of a PSRouter router and records any stats in which it is interested. It has also the capability of reporting these findings to the Topology Manager, through a LSMPacket.

The Topology Manager

The Topology Manager, represented by module tm, is the main interest of this simulation. All the other modules are kept quite simplistic and their functionality has been implemented so that it "fits" the Topology Manager operation. One of the goals of this simulations is the Topology Manager implementation to be as similar as possible with the Topology Manager implementation of Blackadder. This would constitute the code itself very flexible, as it could be transferred easily between the Blackadder test-bed and the simulation environment.

The Topology Manager, as mentioned previously, receives two types of input. The first one comes from the Information Item Table, as a special message containing the publishers and subscribers of a specific Information Item, where a path should be found between them. The second one comes from every Publish Subscribe Router, informing the Topology Manager on the QoS metrics for each link. This link status information is also sent using a specific type of message. Thus, the Topology Manager is able to calculate the forwarding path according to link-aware information. Both types of special messages have been created to match the message formats used in Blackadder.

After the Topology Manager has computed a forwarding path, unlike the Blackadder Topology Manager, it directly informs the Forwarding Table of the required Publishers. Since the module is not connected to the network module, the is no reason the introduce alien packets in the network. This is accomplished by the use of a public C++ function in the Publisher Application definition. However, this procedure is hidden from the Topology Manager by the use of an interface on which an type of manager should be based.

Creating a Topology Manager

In order to provide a more user-friendly method for creating new topology management policies, a module interface is provided from the ICN Simulator. This interface is defined by the interface module TMInterface. It has no graph libraries introduced and it's main use it to provide the programmer with the basic operations that any topology manager should be able to perform. It also provides the basic C++ structs necessary for a smooth operation. These structs are inherited to all sub-classes and provide a common background to all future topology manager implementations. This interface has been declared as the default topology manager of the simulator and in order to switch between different topology managers, the user just has to input the name of the preferred module in the ''TopManager'' variable in the "omnetpp.ini" file. For the time being there is a limited number of topology managers implemented, as shown in the list below.

• TMBoost: This topology manager is based on the Boost library and performs the path calculations according to the Dijkstra's shortest path algorithm.

• TMBoostLAS: This topology manager is based on the Boost library and performs the path calculations according to the link aware information provided by the network modules. The 'S' in the end of the name of the module stands for simple, as this topology manager is able only to assign one publisher to all subscribers of an Information Item.

• TMBoostLA: This more complex topology manager is also based on the Boost library and performs the path calculations according to the link aware information provided by the network modules. It is able to distribute different publishers to the each subscriber of an Information Item and therefore performs a bit more time consuming calculations than the previously mentioned ones.