VIRTUAL ROUTING NETWORK EMULATION

FRAMEWORK
A
Project Report
Submitted in Partial Fulfilment of the
Requirements for the Award of the Degree of

Bachelor of Technology
of
National Institute of Technology Calicut
By

J.Vinod (Y2317)
Rahul Jain (Y2202)

DEPARTMENT OF COMPUTER ENGINEERING

NATIONAL INSTITUTE OF TECHNOLOGY CALICUT

Kozhikode- 673601 , Kerala ,India
April 2006
 Certificate

This is to certify that the project report entitled “VIRTUAL ROUTER EMULATOR”
is a bonafide record of the project presented by J.VINOD (Y2317) and RAHUL JAIN
(Y2202) under our supervision and guidance. The project report has been submitted to
the Department of Computer Engineering of National Institute of Technology, Calicut
in partial fulfillment of the award of the Degree of Bachelor of Technology in
Computer Science and Engineering.

Dr. M. P. Sebastian Mr K.A.Abdul Nazeer

Professor and Head Project Guide
CSED Senior Lecturer
NIT Calicut CSED
NIT Calicut

2
 Acknowledgement

We thank Mr.K.A.Abdul Nazeer, Senior Lecturer, Department of Computer

Science and Engineering NIT Calicut for his guidance and co-operation. We also
acknowledge the advice and help given to us by our friends. We would like to extend
our gratitude to the entire faculty and staff of the CSED NITC, who stood by us in all
pits and falls we had to face during the development phase of this project.

3
 Abstract

The aim of this project is to develop a Virtual Routing Network Emulation

Framework for testing Routing protocols and algorithms. The core of this framework
will be virtual routers running in user space and the component realising their virtual
interconnection. This framework will be based around a network topology emulation
notion.
This report contains details on the motivation, design and implementation behind the
provision of a Virtual Routing Framework.

Key Words:
• Routing
• Routing protocols
• Routing Algorithms
• Virtual Network
• Network Topology
• Network Emulation

4
 Contents
1 INTRODUCTION .................................................................................................7
1.1 Project Overview ...........................................................................................7
1.2 Issues to be addressed ....................................................................................7
1.2.1 Heterogeneity and Scale ........................................................................7
1.2.2 Routing...................................................................................................8
1.3 Motivation for Project....................................................................................9
1.4 Project Objectives ..........................................................................................9
1.5 Additional Considerations ...........................................................................10
1.6 Report Overview..........................................................................................10
1.7 Chapter Summary ........................................................................................11
2 BACKGROUND .................................................................................................12
2.1 Background Research ..................................................................................12
2.1.1 Routing Protocols Overview................................................................12
2.1.2 Path Determination ..............................................................................13
2.1.3 Distance Vector Approach...................................................................14
2.1.4 Link State Approach ............................................................................15
2.2 Related Work ...............................................................................................17
2.3 Platform and Software Choice for the project. ............................................17
2.3.1 Hardware Choice .................................................................................18
2.4 Chapter Summary ........................................................................................18
3 DESIGN...............................................................................................................19
3.1 Brainstorming ..............................................................................................20
3.1.1 Basic Flow Model ................................................................................20
3.2 Major Design Decisions and Justification ...................................................22
3.2.1 Framework ...........................................................................................22
3.2.2 Read Topology information from user as a file. ..................................22
3.2.3 Communicate the desired topology information to the Routers ..........23
3.2.4 Validating the Router Objects..............................................................23
3.3 Change in the role of Routing and importance ............................................24
3.3.1 Virtual Routing implementation aims and importance........................24
3.3.2 Connection oriented / Connection-Less Oriented approach ................25
3.3.3 Node Daemon / Router Activation ......................................................25
3.4 Routing for topology Emulation ..................................................................27
4 IMPLEMENTATION..........................................................................................28
4.1 Key Concepts ...............................................................................................28
4.1.1 Prototyping Overview..........................................................................28
4.1.2 Decision for Running a Routing Protocol............................................29
4.1.3 Topology Management ........................................................................29
4.1.4 Network Organisation..........................................................................31
4.1.5 Router Discovery, Management and initialisation...............................31
4.1.6 Implementation of Distance Vector Routing Protocol.........................32
4.1.6.1 Add a Distance vector entry for itself upon initialisation. ...............32
4.1.6.2 Receive Neighbour Packets and extract required information. .......32
4.1.6.3 The periodic sending and receiving of Distance Vector Packets.....32
4.2 Final Solution overview and functionality discussions. ..............................35
4.3 Key Classes..................................................................................................37
4.3.1 Packet class ..........................................................................................37
4.3.2 TopologyServer....................................................................................37
4.3.3 Data Structures.....................................................................................38

5
 4.3.4 Router Class .........................................................................................39
4.4 Problems encountered..................................................................................39
5 SYSTEM IN OPERATION.................................................................................41
5.1 Topology to be set up...................................................................................41
5.2 RMIREGISTRY setup .................................................................................42
5.3 Setting up Node Daemon .............................................................................42
5.4 Setting up the Topology Server ...................................................................43
5.5 The Creation of Routers and registration.....................................................44
6 TESTING.............................................................................................................45
6.1 Testing Criteria/plan ....................................................................................45
6.2 Test Results..................................................................................................46
7 Conclusion ...........................................................................................................47
8 REFERENCES ....................................................................................................48

Table of Figures
Figure 1-1Network represented as a graph ....................................................................8
Figure 2-1 A Hardware Router ....................................................................................12
Figure 2-2 Three router inter-network .........................................................................13
Figure 2-3 Routing table of Router A ..........................................................................14
Figure 2-4 Link State Flooding technique ...................................................................16
Figure 3-1 A Basic model of flow control ...................................................................21
Figure 3-2 model showing the validation process of Router Objects..........................23
Figure 3-3 Node Daemon setup on client machines ....................................................26
Figure 3-4 Node Daemon creating Virtual Router Objects .........................................27
Figure 4-1 network model of topology file..................................................................30
Figure 4-2 Flow chart of Distance Vector Processes...................................................34
Figure 4-4 representation of Router Objects running. .................................................40
Figure 5-1 Network model of topology to be created..................................................41
Figure 5-2 rmiregistry setup.........................................................................................42
Figure 5-3 Node Daemon setup ...................................................................................43
Figure 5-4 Topology server setup window ..................................................................43
Figure 5-5 Routers initialised and running. .................................................................44
Figure 6-1 In-valid Router registration request ........... Error! Bookmark not defined.

6
 Chapter 1

INTRODUCTION
This Chapter outlines the aims of the project and motivation behind its
implementation.

1.1 Project Overview

Networks can be built using a number of different technologies and based on various
protocols. Main problem with this being that lots of people have built networks with
various technologies and they all want to be able to communicate with each other, not
just with the other users of a single network. This introduces the problem of
interconnecting different networks based on differing protocols. Thus signifying that
studying numerous varied technologies and protocols for students is sometimes
difficult.
The main aim of this project is to develop a framework, which allows Routing
algorithms and protocols to be modified, tested and developed as part of a learning
process with focus on offering a laboratory environment.

1.2 Issues to be addressed

This section looks in more depth of the problem introduced above.

1.2.1 Heterogeneity and Scale

There are two important problems that must be addressed when connecting networks:
heterogeneity and scale. Simply stated, the problem of heterogeneity is that users on
one type of network want to able to communicate with users on other types of
networks. To further complicate matters, establishing connectivity between hosts on
two different networks may require traversing several other networks in between,
each of which may be of yet another type. These different networks may be Ethernets,
token rings, point-to-point links, or switched networks of various kinds, and each of
them is likely to have its own addressing scheme, media access protocols, service
model and so on. The challenge of heterogeneity is to provide a useful and fairly
predictable host-to-host service over this hodgepodge of different networks. To
understand the problem of scaling, it is worth considering the growth of the Internet,
which has roughly doubled in size each year for 20 years. This sort of growth forces
us to face a number of challenges. One of these is routing. How can you find an
efficient path through a network with millions, or perhaps billions, of nodes? A
central aspect of building large heterogeneous internetworks is the problem of finding
efficient, loop-free paths through the constituent networks. This introduces the
important principles of routing and the scaling issues associated with routing
protocols.

7
1.2.2 Routing

Routing is, in essence, a problem of graph theory.

B F
6
A 3
1
3
2
D
C
2
Figure 0-1Network represented as a graph

The edges of the graph correspond to the network links. Each of the edge has an
associated cost, which gives some indication of the desirability of send traffic over
that link. The basic problem of routing is to find the lowest-cost path between any two
nodes, where the cost of a path equals the sum of the costs of all the edges that make
up the path. For a simple network such as Figure 1, one could just calculate all the
shortest paths and load them into some non-volatile storage on each node. Such a
static approach has several shortcomings:

• It does not deal with node or link failures.

• It does not consider the addition of new nodes or links.
• It implies that edge costs cannot change, even though we might reasonably
wish to temporarily assign a high cost to a link that is heavily loaded.

For these reasons, routing is achieved in most practical networks by running routing
protocols among the nodes. These protocols provide a distributed, dynamic way to
solve the problem of finding the lowest-cost path in the presence of link and node
failures and changing edge costs.

The distributed nature of routing algorithms is one of the main reasons why this has
been such a rich field of research and development as there are numerous challenges
in making distributed algorithms work well. Examples of two well known routing
algorithms are distance vector and link state.

Issues explored so far constitute to the fact that networking, more specifically routing
protocols and algorithms is a very technical and problematical area of computing to
grasp.

8
1.3 Motivation for Project

In context to the issues discussed thus far, the deliverable (framework and virtual
routers) of this project will aid in making routing algorithms and protocols easier to
study and understand as they can be broken down and studied in high level languages
such as Java and C#. This will be possible as the framework allows student generated
routing algorithms and protocols to be run, examined and tested. Additionally, the
proposed framework will offer a cheap laboratory environment to carry out routing
investigations, as no real hardware is required at all due to all the components written
in high-level languages in user space.

With high-level code running in user space, a virtually created laboratory environment
can be very dynamic through router components. This is due to virtual routers being
easily modified without prior knowledge of the intricacies of the operating system
running these components. This allows students to concentrate on the
routing/networking concepts they are studying rather than being concerned with the
hardware intricacies. Additionally, the framework will allow students to create their
own network topologies to assist in their learning process and aid future related
research. A major benefit of such a framework would be cost as there would be no
need for real devices such as Hardware Routes.

1.4 Project Objectives

The major objectives of this project are as follows:

• Production of a framework allowing students to generate, modify and test and

emulate real networks. In addition, the development of this framework will
allow users to study the different Routing algorithms and protocols.
¾ The framework will be platform independent and easily transportable
to other networks.
¾ The framework will be proficient enough so that when provided with a
topology specification from the user, the framework can act upon that
specification and create the desired topology.
¾ The topology generation will be aided with virtual routers.

• Generation of Virtual Routers.

¾ Routers running in user space will emulate routers running in kernel
space.
¾ Initially the routers will be running statically. I.e. there will be no
dynamism in terms of the protocols they are running and all the
information (e.g. neighbour locations, network topology/map etc) will
be provided or hardwired.
¾ Previously stated aim is a root requirement, however, once this
objective is achieved (virtual routers function satisfactorily with static
implementation), we will develop the virtual routers with dynamic
functionality. This will consist of the modelling real life routing
algorithm and protocols.

9
1.5 Additional Considerations

At the time of project proposal, an additional component of the framework was

discussed which looked at the user GUI (graphical user interface). As this project is
not concerned with developing this, as this is the work of a following year student, it
is also important to bear in mind that the framework and routers should be developed
with the intention of being extended and components added.

1.6 Report Overview

The remaining sections of this report focus on the various stages of research, design,
implementation, and testing of the project ,as given below.

Chapter 2 BACKGROUND:-
Summarises the research taken into the disciplines related to this project.
Additionally, related systems and tools are also looked at.

Chapter 3 DESIGN:-
This chapter contains the detail of the approach taken to design the systems and
components. Details regarding the important choices made in context to
implementation are also discussed.

Chapter 4 FURTHER DESIGN AND IMPLEMENTATION:-

During this chapter, the implementation of the software is discussed in line with any
other design issues that have not been looked at in the previous chapter or issues that
have arose. Choices made and problems encountered also discussed.

Chapter 5 SYSTEM IN OPERATION:-

This chapter takes the reader through the system and shows the key components in
use. This is done by screen shots and explanations.

Chapter 6 – TESTING:-
This section will document the testing performed on the entire Framework. In
addition to this, there is also an evaluation of all the work carried out and also
documentation of further work that can be carried out is also in this chapter.

Chapter 7– CONCLUSION:-
Final words on the successful completion of the project .

10
1.7 Chapter Summary

This chapter has given an introduction to the final year project problem, as well as the
motivation behind it with aims and expectations of the final solution. The contents of
the whole documents have also been introduced. The next chapter includes research
undertake and problems encountered during the early stages of the development.

11
 Chapter 2

BACKGROUND
The background section of this project looks at areas considered during the
development phase of the framework. This includes research conducted, assessing
similar domains and past related solutions. This section will also consider tools and
development environments needed for the implementation of the final solution.
In addition, the Background section will also assess the benefits and downfalls of high
a number of high-level languages to be used for the implementation.

1.8 Background Research

With this project’s main focus being in the areas of Routing, interconnecting virtual
routers, and the emulation of real routers in user space, the Background section will
firstly look at how routers in real network operate. This study will consider
established distributed algorithms and protocols and their relative benefits and
downfalls. This will give readers of the project and project author an insight into how
real router operate before attempting to emulate routers in user space.

Figure 0-1 A Hardware Router

1.8.1 Routing Protocols Overview

Routing protocols facilitate the exchange of routing information between networks,

allowing routers to build routing tables dynamically. Traditional IP routing stays
simple because it uses next-hop routing where the router only needs to consider where
it sends the packet, and does not need to consider the subsequent path of the packet on
the remaining hops.
All dynamic routing protocols are built around an algorithm. Generally, an algorithm
is a step-by-step procedure for solving a problem. A routing algorithm must, at a
minimum, specify the following:

A procedure for passing reach ability information about networks to other routers.
A procedure for receiving reach ability information from other routers.
A procedure for determining optimal routes based on the reach ability information it
has and for recording this information in a route table.
A procedure for reacting to, compensating for and advertise topology changes in an
inter-network.

12
1.8.2 Path Determination

All networks within an internetwork must be connected to a router, and wherever a

router has an interface on a network, that interface must have an address on the
network. This address is the originating point for reach ability information. This can
be exemplified with figure 2-2.

Figure 0-2Three router inter-network

Figure 3.0 represents that Router A knows about networks 192.168.1.0, 192.168.2.0,
and 192.168.3.0 because it has interfaces on those networks with corresponding
addresses. Likewise, router B knows about 192.168.3.0, 192.168.4.0, 192.168.5.0, and
so on. Thus each router knows about its directly connected networks from its assigned
addresses. The storage of this information is conducted in a routing table. The process
of building a routing table is illustrated below with reference to the topology
demonstrated in figure 3.0.

1. Router A looks at its own IP addresses and associated masks; figures it is

connected to networks 192.168.1.0, 192.186.2.0, and 192.168.3.0.
2. Router A puts these networks into its route table, along with some sort of
mechanism indicating that the networks are directly connected.
3. Router A places the information into a packet (My directly connected
networks are 192.168.1.0, 192.186.2.0, and 192.168.3.0.).
4. Router A sends copies of these route information packets to routers B and C.
5. Routers B and C, having performed the same steps, have sent updates with
their directly connected networks to A. Router A enters the received
information into its route table, along with the source address of the router that
sent the update packet. Router A now knows about all the networks, and it
knows the addresses of the routers to which they are attached.
6.
When there are multiple routes to the same destination (as is the case when attempting
to reach network 192.168.5.0, 192.168.6.0 and 192.168.7.0) a router must have a
mechanism for calculating the best path. A metric is a variable assigned to routes as a
means of ranking them from best to worst or from most preferred to least preferred.
An established metric, which is implemented commonly, is ‘hop count’. Hop count
refers to the number of legs traversed by a packet between its source and destination.
Obviously, the lower the hop count, the shorter the route for a packet. This concept

13
will be further looked at when considering distance vector and link state protocols in
more detail.

Network Next-Hop
Router
192.168.1.0 Directly
connected
192.168.2.0 Directly
connected
192.168.3.0 Directly
connected
192.168.4.0 B, C
192.168.5.0 B, C
192.168.6.0 B, C
192.168.7.0 B, C

Figure 0-3 Routing table of Router A

From research it is clear that routing algorithms use two basic technologies:

• Telling the world who your neighbours are: link-state routing protocols such
as OSPF (Open Shortest path first).
• Telling your neighbours what the world looks like: distance-vector routing
protocols such as RIP (Routing Information Protocol).

1.8.3 Distance Vector Approach

This type of routing protocol requires that each router simply inform its neighbours of
its routing table. For each network path, the receiving routers pick the neighbour
advertising the lowest cost, then add this entry into its routing table for re-
advertisement. Each node keeps a routing storage mechanism (routing table) with one
entry for every possible destination in the network. An implementation is likely to
need to keep the following information about each destination:

• Address: IP address of the host or network.

• Next Hop: first gateway along route to destination.
• Hop Count: a number, indicating the distance to the destination.
• Timer: time since the entry was last updated.

This important information is exchanged by connected nodes in periodic update

messages. Each node/router that is part of the network sends update messages to its
directly connected nodes describing its routing table as it currently exists. The
procedure that is carried out by every node/router that participates in the routing
protocol is exemplified next.

14
 • Maintain a routing table with an entry for every possible destination in the
network. The entry contains the distance D to the destination, and the next hop
G on the route to that network. There should be an entry for the node itself,
with hop count of 0 (main reason for this being that if the node receives a
packet destined for itself, it will then not forward that packet to another router
but instead act accordingly).
• Periodically, send routing updates to every neighbour. The update contains all
of the information from the routing table. It contains an entry for each
destination, with the distance shown to that destination.
• When routing update arrives from a neighbour G', add cost associated with the
network that is shared with G'. Call the resulting distance D'. Compare the
resulting distances with the current routing table entries. If the new distance D'
for destination N is smaller than the existing value D, adopt the new route. If
G' is the gateway from which the existing route came, i.e., G' = G, then use the
new metric even if it is larger than the old one.

Another consideration that must be addressed concerns what if the topology changes?
This will mean that the set of neighbours for each Router changing; so consequently,
next time the calculations are done, the change will be reflected. As only the best
route to any given destination is remembered, if the router involved in that route
should crash, or the network connection to it breaks, the calculation might never
reflect the change.
This problem is addressed with the implantation of “timing out routes”. The basis of
this is that every router sends an update message to all its neighbours once every 30
seconds. For example, the current route for network N uses Router X. If we don't hear
from X for 180 seconds, we can assume that either the router or the network
connecting to it has broken. Thus, we mark the route as unusable. Hearing from
another neighbour that has a route to X, the invalid route will be replaced.

1.8.4 Link State Approach

Link state routers have a complete overview of the network as compared to distance
vector routers, which only know only the next hop for a packet to its destination. The
difference can also be summarised by the fact that unlike the “routing-by-rumour”
approach of distance vector, link state routers have direct information from all the
network routers. Each router sends information about itself, its directly connected
links, and the state of those links. This information is passed around from router to
router, each router making a copy of it (this technique is referred to as “Flooding”).
The objective is that every router receives identical information about the network and
each router will independently calculate its own best paths. Link state protocols are
sometimes referred to as shortest path first or distributed database protocols. They
are built around a well-known algorithm from graph theory, E. W. Dijkstra's shortest
path algorithm. A commonly used protocol based on the Link state approach is OSPF
(Open Shortest Path First).

Reliable Flooding is the process of making sure that all the nodes participating in the
routing protocol get a copy of the link-state information from all other nodes. As the
term “flooding” suggests, the basic idea is for a node to send its link-state information
out on all of its directly connected links, with each node that receives this information

15
forwarding it out on its links. This process continues until the information is has
reached all the nodes in the network.
Each node creates an update packet – referred to as link-state packet containing the
following information:

• The ID of the node that created the LSP – required to enable route
calculations.
• Time to live for this packet – needed to make the process of flooding to all the
nodes reliable.
• List of directly connected neighbours of that node, with metrics to those
neighbours – required to enable route calculations.
• Sequence number – needed to make the process of flooding to all the nodes
reliable.

The following diagram shows an LSP being flooded:

1. 2.

X A X A

C B D C B D

3 4

X A X A

C B D C B D

Figure 0-4 Link State Flooding technique

1. LSP arrives at node X.

2. X floods LSP to A and C.
3. A and C flood LSP to B (but not X).
4. Flooding is completed.

Once a given node has a copy of the LSP from every other node, it is able to compute
a complete map for the topology of the network, and from this map it is able decide
the best route to each destination.

16
1.9 Related Work

Currently there are a number of tools available on the web that simulate routing and
visualise this process. Majority of these tools are concerned with simulation which is
not directly concerned with this project which is more towards the emulation of real
routers in user space.
Some of these tools were downloaded and installed; after ‘playing with then’ during
research we found that they are primarily concerned with just simulating a network
and there was no mechanisms such as sending a receiving virtual packets and
establishing links between different nodes.
However, on the internet there was a lot of material concerned with ‘virtual networks’
which was more in the area of this project. One particular project that was useful in
giving an insight into techniques that could be used in design and implementation can
be found at http://grasia.fdi.ucm.es/~luismi/virtualnet/interface.html

1.10 Platform and Software Choice for the project.

A major factor to be taken into consideration is that an object-oriented language

approach would be more suited for this project, as this will allow different
components to be represented independently. Additionally, as this project may be
developed upon in the future (the implementation of a graphical user interface). Java
provides an extensive API for graphical development. Furthermore Borland Java have
a number of developing environments that allow user to exploit graphical
development.
Also with the adaptation of a waterfall model software engineering approach, an
object-oriented approach will allow author to refer back to any stage of devolvement
and amend or alter framework design and also the implementation. An object-oriented
approach will make it easy for the author to add delete and modify components at any
stage.

The two contenders for the choice of programming languages to be used are C# and
Java:

C# is a fairly new object-oriented language from Microsoft that is based around the
.NET Framework. As an object-oriented language, C# supports inheritance,
polymorphism, class and custom attributes. In addition C# prevents programs from
accessing objects inappropriately and supports garbage collection and memory
management. Visual studio.NET is a complete set of development tools available for
application building that is available to me if I was to choose C#.

Java is a portable and a high level language which compiles to byte code. Java also
supports inheritance, polymorphism, class and custom attributes as well as preventing
programs from accessing objects inappropriately along with its own garbage
collection. Java is also a platform providing a virtual machine upon which programs
can run with the API provided. To develop applications in Java, there are a number of
options available ranging from Borlands JBuilder (high end of the market) to Helios
Text pad (a text editor with code highlighting and auto syntaxting). JDK (Java
Development Kit) can be easily accessible from java.sun.com.

17
We choose to use the java programming language to implement my project because
my past experiences using the language lead me to believe that is was adequate for the
job. In addition, with a major aim of the Framework being platform independent and
portable, java provides an ideal solution to meet this aim.

1.10.1 Hardware Choice

A PC with Windows based operating system would be adequate for hardware required
to carry out the implementation. As all the components are represented in high level
languages rather than in kernel space, no expensive equipment is required. The
University LAN (Local Area Network) allows sharing of files, software and other
resources which makes it easy to do the work at home and in the labs.

1.11 Chapter Summary

This chapter has discussed in some detail the routing architecture and the distributed
algorithms and protocol approaches employed. In addition, software and hardware
choices were discussed and a decision on them where made to support the
implementation phase of the project. The next chapter discusses the design process
involved before the implementation of the project solution.

18
 2 Chapter 3

DESIGN
This chapter describes the design decisions made in order to meet the aims that were
specified in the introductory chapter. This chapter will also bring in some of the ideas
and research outlined in the previous chapter. The two parts of the solution are the
‘Virtual Routers’ to deal with the emulation of routers and the ‘Framework’ to deal
with the management of tasks such as topology generation, router management and
initialisation.

The basic flow model given in the next page describes initial ideas and requirements
that have emerged from the meeting with the project guide and as a result of
brainstorming of ideas/questions for the final solution.

19
 2.1 Brainstorming
An idea suggested as an option to be considered by
guide;
Daemon – “A process that runs in the background
and performs a specified operation at predefined
times or in response to certain events.”
Placed in context, this would mean a process How will
continuously running and when activation from the user
the framework is detected, a router process may be specify the
created or a router process continuously running topology
but dormant until activation. which is to
be
Initial Ideas and requirements (some of which
generated?
How will the Routers be have been already highlighted in the
initialised and managed? introductory chapter) that have emerged from
meetings with final year project guide and
brainstorm of ideas/questions for the final
solution.

Feedback
relevant • Through a topology file
information in There should be loaded into the
real time to user. some functionality framework?
E.g. regarding that allows user to
• Through command line?
network model link failure,
• Pre-set topologies?
topology as new addition of new
paths are added routers/paths
and taken down
and new routers Virtual Routers;
are discovered Virtual connection / link;
etc. Virtual connection
failure or virtual errors;
Virtual connection
establishment;
How will these Virtual router or path
concepts be addition;
modelled over a Virtual packets;
real network?

2.1.1 Basic Flow Model

With the initial ideas and thoughts taken into consideration along with the aims and
requirements of the solution a basic flow model can be created that summarises the
major tasks that must be implemented.

20
 Framework
responsible
for activation
of Routers,
their
connectivity
User and
validation
specifies checks. Etc.
As this process may be router
based on the supply of
many items of
topology
b ‘Interconnecting
information, e.g. IP
address and port Framework.’
numbers, it may be
best to provide this
information through a
file.

Represents the
Router information
being relayed in
Object appropriate
1. format from the
framework to
the routers, who
then know their
neighbours,
Router Router communication
Object Object methodology etc
based on the
N. 2. topology
Router
Object specified.
3.

Figure 0-1 A Basic model of flow control

21
2.2 Major Design Decisions and Justification

This section of the report outlines the main requirements of the proposed system that
must be met when implemented.

2.2.1 Framework

The major concern of the project is centred on the framework or the ‘virtual network
topology’. However, it is impossible to test any components of this framework at any
stage without any router object classes. Thus, it is also important to design a simple
router object class that can be used along side the implementation of the framework as
a test utility. However once the Framework is operating adequately, the Virtual
Routers will be developed to emulate real routing protocols.

The functions of the ‘virtual network topology generator’:

• Read Topology information from user as a file.
• Communicate the desired topology information to the Routers (This function
relies on the routers either being already set up prior to communication or the
virtual Routers must be created before this function is carried out by the
network topology generator).
• Validate the Router Objects and make sure the topology has been correctly
constructed. This is needed as virtual router running on machine x who is not
part of the topology, but is/has been created/running.
• Destroy Routers objects which have been constructed in error as they are not
needed. This function is linked into the above functionality.
• Register the correct alive routers so all Routers that are running can be
accounted for. This function is linked into the ‘Validate the Router Objects’
functionality.
(These core functions may not be carried out in the order stated – this flow of
control is an implementation issue).

Below is an in-depth look at the core functions.

2.2.2 Read Topology information from user as a file.

The Topology File must not be overloaded with information, as the generation on new
network topologies will be a regular process. As the user construct the topology file, if
it requires abundance of information this process may become extremely time
consuming and even error prone.

A suggested format below, which may be re-considered at implementation:

<IP address of Router>< : > <Router port>< = > <IP address of neighbour>< : > <neighbour port>
e.g. 10.38.66.185:6000=10.38.66.185:5000

• This one line with valid fields would represent a Router with a single
connected neighbour.

22
2.2.3 Communicate the desired topology information to the Routers

This function will be carried out with the use of packets. Once the topology file has
been read, understood by the topology server;
• An instance of a data structure will be created representing the exact topology
of each Router. This will be a list of directly connected neighbours for each
node. This is required not only for the validation stage but also by the Router
themselves.
• A packet will be sent to the Router informing it of its Topology (i.e. its
neighbours). The information that is needed to inform a Router of its new
Neighbour may roughly consist of the following:

9 Sender - an identification mechanism, e.g. neighbouring Router name.

9 Senders IP address – IP address if neighbouring Router.
9 Target IP address – IP address of Target Router.
9 Target Port – The Port the receiving Router is listening on.

With this information, each router will be able to build its own network topology
and will have all the required information to emulate a real life Router depending
on the Routing protocols employed. Once the transfer this information is complete
for each Router, this core function is completed.

2.2.4 Validating the Router Objects

As there may be a number of Routers created or are already running, it is important

that the topology does not include Routers that have not been specified in the
topology file. This can be avoided with validation. This validation process will require
each Router once alive to register with the ‘virtual network topology generator’. This
process can be shown as a model:

Time Line Router. Time Line - Server.

Router Registration takes place

Registration confirmed.
Decision.

Here the sending

Router’s registration
Router informed with required command is
information (its specific topology) processed. The
receiving process will
check against the
topology file and
stored information
whether to allow the
Router permission to
Figure 0-2 model showing the validation process of Router Objects stay alive and register
as part of the topology,
or whether to inform
the Router it is not part
of the
23topology and is
wrongfully alive.
The model makes an assumption that the registering router is valid and as part of the
topology. If this was not the case, at the decision stage, instead of sending a register
confirm command, a deactivation command would be sent instead that would
command the Router process to destroy itself.
The implementation of the registration functionality will also be based on a packet
approach.

The description above goes into detail regarding the core functionality of the
‘interconnecting’ paradigm of the entire framework. Next will be a look at the
Routing aspect of the system.

2.3 Change in the role of Routing and importance

Prior to carrying out the research it was thought that the Routers would not play an
integral part of the Framework but function solely as a Testing and Evaluation
mechanism. However, throughout research, analysis and design it came apparent that
the Virtual Router would have to function a more important role in final solution even
though the Framework is generally centred around their management and monitoring.

Additionally, another implementation issues that became important was when

addressing the communication between Router Objects and Framework components.
It would be unrealistic and unfeasible to not implement the Router Objects in parallel
with the rest of the implementation, as compared to initial thought of the Router
objects being implemented at the end. This relates to the matter of integrating
different components of the architecture together. If all the components apart from the
Router Objects were implemented and integrated together, a number of
implementation issues may arise at latter stages as the process of integrating Router
Objects into the Architecture may require modification to other components, maybe
resulting in major architectural changes. This can be avoided by developing the
Virtual Routers in Parallel with the rest if the Framework and continuous integration
and testing.

2.3.1 Virtual Routing implementation aims and importance

The first priority of Virtual Routers being to run statically (i.e. with all required
information hardwired and not running a routing protocol). We believe this aim will
be uncomplicated and achieved straightforwardly mainly because as the Virtual
Routers will not be running a Routing Protocol and all the required information will
be provided first hand. This will mean that Routing Table will not be formed or
populated by the Virtual Routers but be supplied. With running Virtual Routers
statically, this will provide a simple but efficient means of a testing tool for other
components of the architecture.
We believe there will be enough time during the implementation phase to develop the
Virtual Routers further from the ‘static approach’ to running a Dynamic Routing
Protocol. This will show the emulation of kernel space routers. The tasks a Virtual
Router will perform when developed can summarised by the points drawn.

24
 • Find other Router neighbours.
• Run a routing algorithm that allows you, and your Neighbours, to maintain
routing tables.
• Forward received data packets toward their destination.
• Update neighbour list, and send keep-alive packets to neighbours (this
depends on the Routing Protocol in use).
• Responds to all kinds of incoming packets.

2.3.2 Connection oriented / Connection-Less Oriented approach

As the real Routers run at IP level, that is there is no TCP connection or UDP de-
multiplexing overhead of any kind in regards to the communication with other
Routers. They work on a ‘fire and forget’ approach when sending packets to other
Routers. This is an example of connection-less approach. With this in consideration,
we believe that a UDP (User Datagram Protocol) approach would be more appropriate
for the emulation of Routers than a TCP (Transmission Control Protocol). The main
reason for this being is that UDP is a connectionless protocol that, like TCP, runs on
top of IP networks. Unlike TCP/IP, UDP/IP provides very few error recovery
services, offering instead a direct way to send and receive datagram’s over an IP
network. This in effect will result in the re-emulation of IP level with the use of
UDP/IP protocol.
The Reason TCP protocol would not be appropriate is due to the fact that TCP
enables two hosts to establish a connection and exchange streams of data. TCP
guarantees delivery of data and also guarantees that packets will be delivered in the
same order in which they were sent. This is effect would add many validation and
correction mechanisms to the final solution which do not exist in context to real
Routers; which this project is trying to emulate. Therefore, UDP protocol would be
appropriate as it would be proficient to re-emulate the IP protocol which deals only
with packets.

2.3.3 Node Daemon / Router Activation

Another aspect that must be addressed refers to the setting up the topology. Thus far
concepts such as inter-communication between Virtual Routers have been addressed,
however there has been no discussion regarding how the Routers will be setup or
initialised. For the Framework components to pass packets/messages/information to
the Virtual Routers, the Virtual Routers themselves must be up and running prior to
this. This means that the Virtual Routers need initialisation manually at all the
locations they are running. There is no problem with this approach if only a small
number of Virtual Routes are needed to form the topology specified. On the other
hand, if the topology entails a large number of Virtual Routers interconnected over a
number of different locations, the previous approach seems totally unfeasible.
A technique or a mechanism introduced at the start the Design section could provide a
solution to the predicament. The Notion of running node Daemons would entail:

• A node daemon setup on desired terminals.

• Node Daemon runs continuously in the background, until it is activated by a
particular event.

25
 • When a Virtual Router needs to be initiated or created on a particular terminal,
the Daemon will create a Router Process on the terminal in accordance with
the topology file.

This Process can be explained with the aid of a model/diagram below.

1.

IP address IP address
10.38.66.185 10.38.66.186

Node
Daemon
set up on
terminal.

IP address
10.38.66.187 IP address
10.38.66.188
Figure 0-3 Node Daemon setup on client machines

2. Topology File specifies below the number of Routers running on specified

machines - the inter-connections of the Virtual Routers to one another are of little
concern:

3 Routers running on 10.38.66.185

1 Router running on 10.38.66.186
2 Routers running on 10.38.66.187
2 Routers Running on 10.38.66.188

This information will be received by the Node Daemon and trigger the creation of the
number of Routers depending on the Topology. This is show by the figure 3-4.

The Communication between the node Daemon and the network topology will be
implemented via java RMI (Remote Method Invocation). Java RMI is a mechanism
that allows one to invoke a method on an object that exists in another address space.
The other address space could be on the same machine or a different one. The RMI
mechanism is basically an object-oriented RPC (remote procedure call) mechanism.

26
Router
Object
10.38.66.185 10.38.66.186
Node
Manager Router
Router Object
Object

Router
Object

10.38.66.187

Router
Object

10.38.66.188
Router
Object

Represents
Router the forking
Object
of Router
Objects.
Router
Object

Figure 0-4 Node Daemon creating Virtual Router Objects

Once a Virtual Router is created, it will register with the Topology Server and follow
the commands specified earlier.

The condition and the activity of the Routers will be monitored and the information
will be relayed back to the user. The way this is done and what information is
displayed will be dealt with in the following chapter.

2.4 Routing for topology Emulation

Thus far, there have been a number of discussions on how Virtual Routers are to be
used in creating a network and the protocol that are to be used. However it is very
important that at this stage to remind myself that the role of Virtual Routers is that of
a component that emulates a network Topology. This is a very important point to take
into consideration and it is essential not over complicate their role.

27
 3 Chapter 4

IMPLEMENTATION
This chapter describes the development of the final project solution based upon the
decision in the Design chapter and ideas formed during this phase. This chapter also
goes onto link the previous design Chapter into the Implementation phase with
advanced design decisions take further. This includes the class definitions, models
and pseudo code representing noteworthy system functionality.

3.1 Key Concepts

This section will break down the key aspects of the final Solution and discuss their
importance, functionality and other implementation related issues. This is more an
overview with majority of the technical-oriented discussion and decagons making
process being carried outer later in the chapter.

The key aspects can be broken down into the following bullet points.

• Prototyping Overview.
• Running a Routing Protocol.
• Topology Management.
• Network Organisation.
• Router Discovery, Management and initialisation.
• Implementation of Distance Vector Routing Protocol.

3.1.1 Prototyping Overview

An approach we thought that would be beneficial was to implement some components

at an early stage of the implementation phase as a form of a prototype. This
particularly refers to the Virtual Routers, as having a statically run Virtual Router
would provide a basis and would be the first step in the emulation process. In
addition, the prototype can be used later in the implementation phase and developed
to run a Routing Protocol.
The term ‘statically run Virtual Routers’ refers to Virtual Routers running a largely
simplified Routing Protocol. This was one of the initial aims of the project to be
achieved.
The prototype implementation involved a Router class with a Vector (IP address of
Router, port number and Router Name) representing the directly connected
neighbours. This information was programmed in and not provided in real time. The
responsibility of the prototype Virtual Router was to communicate with the directly
connected neighbours and send a neighbour packet at a regular time interval to each
other. In addition, if a neighbour packet was not received for two minutes from one of
the neighbours, the link was assumed dead and its entry was removed from the vector.
These tasks were limited to this as any further development would mean more time
consuming and unnecessary as the purpose of the prototyping was gain knowledge of
the implementation issues involved and further development would take place in
conjunction with the implementation of other components.

28
3.1.2 Decision for Running a Routing Protocol

To show the emulation of real routers, we have decided to run a dynamic Routing
Protocol among the Virtual Routers. This is a development on the prototype static
Routers, running a very simplified protocol. As the prototype meets the initial aim of
running static routers, we can concentrate of forming more complex dynamic
distributed protocols. Taking background and research phases into consideration, the
protocols available for emulation are either a Link-State approach or a Distance
Vector approach.
The reason why Distance vector approach was choose for emulation are as follows,
Distance vector routing protocols are designed to run on small networks (usually
fewer than 100 routers).
Distance vector protocols are generally easier to configure
Distance vector approach demands less maintenance than link state protocols.
Distance vector routing protocols use a hop count to determine the best path through
an internetwork – this metric has been looked at during the research and background
sections.

A major point to take into consideration is that Distance vector routing protocols are
great for a small environment, but when it comes to enterprise networking, you must
deploy link state protocols. This point fits well into the final solution, as the
topologies generated will not be on a large scale and normally well under 100
Routers. The technical discussion and decisions on the emulation of a distance vector
protocol will be carried out later in this chapter.

3.1.3 Topology Management

Upon reading a topology file e.g.

10.38.66.185:6000=10.38.66.185:5000
10.38.66.185:5000=10.38.66.185:6000
10.38.66.185:3000=10.38.66.185:5000
10.38.66.185:5000=10.38.66.185:3000
10.38.66.185:9000=10.38.66.185:3000
10.38.66.185:3000=10.38.66.185:9000

This represents a topology of 4 Routers all running on a machine with IP address of

10.38.66.185, arranged in the following way:

10.38.66.185:6000 10.38.66.185:3000

10.38.66.185:9000
10.38.66.185:5000

29
Figure 0-1 network model of topology file

The Topology Management component of the framework must interpret the topology
file as a topology model above and be able to store this information locally. This
topology arrangement then must be communicated to the Virtual Routers who
emulate it. In addition, all validations of Routers will be done against this
representation.
The most proficient way of managing this information we found was to break down
the topology and look at it from the view of each Virtual Router. By this we mean
creating a data structure that represents the topology of each Router rather than
representing the topology as a whole. So taking the model above, the topology of
Router 10.38.66.185:5000 would be as follows:

List of Directly Connected Neighbours:

Router X (IP address = 10.38.66.185; Port number = 6000)

Router Y (IP address = 10.38.66.185; Port number = 3000)

Other Information that may be recorded here is that whether the Router has registered
with the Manager or not.

X and Y represent the identification mechanism that would be needed – Router Name.
This would be provided upon Router initialisation.
In addition the above data will be communicated to the specific Virtual Router, but
the storage of the information will be local on the Topology Manager as it will be
required for Router Validation.

The major advantages of representing data this way rather than having a more general
or a complete representation are,
• Each Router only needs to be aware of its directly connected neighbours and
not concerned with Routers multiple hops away in the topology as they will
be discovered via the Routing algorithm running on the Router.
• The information has been already broken down and organised at a very early
stage;
• When initialising the Virtual Routers, information regarding their directly
connected neighbours can be easily accessed and communicated as its
already available rather than having to access the complete topology
representation and again filtering the right information.

An implementation decisions from the above points and discussions derived that there
should be a dynamic way of representation the topology information. This resulted in
the implementation of two classes to hold the required values.

RouterInfo class – responsible for holding key information about each Router in the
topology, e.g. Router Name, IP address and Port address.

Router Topology class - responsible for holding topology information of each

Router. This will be in the form of a list implemented through either vector; arrays or
a hash table holding RouterInfo objects of directly connected neighbours.

30
The representation is exemplified:
E.g. for Router 10.38.66.185:5000 (topology modelled on previous page),
Information of directly connected neighbours

RouterInfo_X
Router X (IP address = 10.38.66.185; Port number = 6000)
RouterInfo_Y
Router Y (IP address = 10.38.66.185; Port number = 3000)
RouterTopology class (containing objects that represent information about directly
connected neighbours)
RouterInfo_X
RouterInfo_Y

Obviously, in these classes there will be ‘helper methods’ that aid access, storage and
debugging.

3.1.4 Network Organisation

The Basic Overall organisation of the network is a server client relationship. This is a
connection-less oriented relationship and the communication is mechanised via
packets. The Server-side deploys components that implement the processing of
topology files, topology representation and storage, validation of Routers and
Communication mechanism responsible for passing information to the Routers. The
Virtual Routers represent client-side of this framework.
Datagram Sockets are the core communication components that are used to
implement the sending and receiving of packets.
When the Server is initialised, it will require,
• Topology File.
• Port number it is running on.
• There is no need to pass in the IP address as getHostAddress() and
getHostName() will automatically obtain the required information. This is to
aid the user as passing this information at command line or upon
initialisation may be time consuming.

3.1.5 Router Discovery, Management and initialisation

The initialisation of the Router on a particular machine must be done after the
initialisation of the Server as the Server must be running to receive register packets
and do validation checks of the Routers. However with a node Daemon running, this
refers to the initialisation of the node Daemon rather than the Router itself.

The information the Routers need to setup is:

• IP address of the Server.
• Port of the Server Process.
• The Router name – to distinguish Routers apart if they are on the same
machine. Also provides a suitable key when addressing storage with has
tables.
• The port the Virtual Router will run on.

31
3.1.6 Implementation of Distance Vector Routing Protocol

After the prototyping, it was decided to emulate Distance Vector Protocol amongst
the Virtual Routers. Thus, the mechanisms of protocol are to be represented in Java.
One assumption this implementation relies on is that the Virtual Routers do not need
to locate their directly connected neighbours. The addresses of the directly connected
neighbours will be provided at initialisation and once communication is established
with the Server (Topology-Router validation).
The tasks that were implemented to emulate Distance Vector are:

3.1.6.1 Add a Distance vector entry for itself upon initialisation.

This point means that an entry must be made for the running Router in its own
Distance Vector Routing Table. This is need because if the Router receives a packet
destined for myself, it must not forward it but act upon it as the packet has arrived at
its destination.

// Initialize a Distance Vector entry for myself: (me, 0, me).

(me, 0, me) = For each destination, record its name D, the hops H (consider neighbours as
one hop away), and the name of the neighbour to which we forward packets.

Neighbour me = new Neighbour (name_, localIP.getAddress(), localPort);

Distance temp = new Distance(name_, 0, me);
distanceVector.addToVector(temp);

The snippet of code may exemplify the point being made.

3.1.6.2 Receive Neighbour Packets and extract required information.

The make the emulation seen as realistic as possible, the only information that will be
provided to the Virtual Routers by the Topology Management component in the
Server will be the information of directly connected neighbours. This is in line with
kernel space Routers, which have to be either configured when setup to recognise
directly connected Neighbours or auto-configuration utilities are run on the hardware
Router for it to discover directly connected Routers.
For this, Neighbour packets were used to inform a Virtual Routers of their directly
connected neighbours. This is done by the topology manager component at Server-
side as the Router has no information regarding the entire Topology but the Server
does through the topology file.

3.1.6.3 The periodic sending and receiving of Distance Vector Packets

The basis for inter-router communication is based around the periodic sending of
Distance-Vector packets. The major roles of these packets can be summarised,

Act as a ‘keep alive’ mechanism informing neighbours that the sending Router is still
up and running and the connection has not been broken.

32
 Notify Neighbours of other directly connected Neighbours.
Include a hop count measuring distance to other Virtual Routers in the Network.
Upon receipt of Distance Vector packets, store the time the packet was received. This
is needed as a distance Vector packet is expected at a regular time interval and act if
this time pattern is broken - if packets are sent and received ever 30 second and no
packet arrives for more than 2 minute, assume that Router is dead and the link failed,
thus update the Distance Vector). This is refers to the ‘keep alive’ mechanism in
point no. 1.

The model on the following page represents the flow of control and information upon
receiving a Distance Vector packet at a particular Virtual Router.

33
 Receive a Distance Is Router N
Vector packet from NO Add Router N to
in neighbour
Router N. list? Neighbour list.

Y
E
S

Set N's timestamp, in the neighbour

list, to the current time.

D/d = distance
H/h = Hops
N = sending
Router

Examine each entry (D, H) of

Router N’s distance vector:

Entry present for

If present YES destination D is in NO
entry in Add (D, H+1, N)
own distance
Distance vector?
vector
contains
(D, h, *)
and H+1
<= h then
update that
entry to (D, Finally, for any entry (d, *, N) in your vector, and N's vector has EN
H+1, N). no entry for d, remove your entry.

Figure 0-2 Flow chart of Distance Vector Processes

34
3.2 Final Solution overview and functionality discussions.

This section of the report looks at the final solution of the project and discusses any
problems encountered. In addition there is also discussion on noteworthy
functionality.
On the following page, the final solution (figure 4-4) is modelled in UML notation.
This includes all the components of the framework and the components needed and
used by the Virtual Routers.

35
Figure 0-3 UML model of final solution

36
3.3 Key Classes

This section of the Chapter loos at the key classes in the UML diagram and discusses
the ideas involved any noteworthy functionality involved.

3.3.1 Packet class

This is a super class which captures the common features of a Packet. From this class
other packet classes can be derived such as the ones used in the final solution as listed
below. In addition, this class can be used in further work as other packet types can be
derived from it.

• RegisterPacket
• RegisterConfirmPacket
• NeighbourPacket
• DistanceVectorPacket
• DataPacket

Furthermore, the Packet class has other several purposes in addition to capturing the
common features of a packet:

Provides a factory method to parse a packet out of a byte array.

Provide some utility methods –

1. As the max size of names in our packets is 8 chars,

public static final int NAMESIZE = 8;

encodeName() could be useful for manipulating names in packets, keeping in mind

that the name field always needs to have 8 chars. The way this is done is by using zero
chars to fill in any left over space in the char array. There is also decodeName() that
does the opposite.

Another utility function that was needed was bytes2InetAddress (byte addr[]).

The main purpose of this function is to convert an array of 4 bytes as returned by

InetAddress.getAddress() back to an InetAddress object. The emergence of this
method is discussed in the problems encountered section of the chapter.

3.3.2 TopologyServer

This class is important in terms of its responsibility and its role in the framework. As
it’s the ‘nucleus’ of the final solution because of all information passing through it
and its communication with the Virtual Routers.
One piece of functionality that is particularly important in this class is related to the
communication it carries out with the node daemons on client machines through RMI.

37
 private void TalkToDaemon (RouterAssociation ra) {
System.out.println ("Begin Daemon Chat");
if (System.getSecurityManager() == null) {
System.setSecurityManager(new RMISecurityManager());
}
String name = "rmi://" + ra.RouterIP + "/Node";
Node node = (Node) Naming.lookup(name);
node.createRouter(RouterInfo.getIPAddress(ipAddr.getHostAddress()), this.port,
ra.RouterName, ra.RouterPort);

The Naming.lookup method obtains an object handle from the Object Registry
running on ra.RouterIP (which returns the IP address of the machine where this
Router is to be created) and listening to the default port. The result of Naming.lookup
must be cast to the type of the Remote interface.
The above is linked into the client Clint side via the NodeImpl class (node Daemon)
where the other side of this communication occurs,

public static void main (String[] args) {

if (System.getSecurityManager() == null) {
System.setSecurityManager(new RMISecurityManager());
}
String name = "Node";
try {
Node node = new NodeImpl();
Naming.rebind(name, node);
System.out.println("Node Daemon started and bound");

The rmiregistry Object Registry only accepts requests to bind and unbind objects
running on the same machine, so it is never necessary to specify the name of the
machine when one is registering an object.

3.3.3 Data Structures

One of the most important data Structure that is used in the implementation is the
Distance Vector. The Distance Vector contains the list of possible destinations, hop
counts to those destinations and the next hop Router entry.
There was a number of ways to represent this data – e.g. multidimensional arrays,
vectors etc. However the most effective and user oriented way of representing the
Distance Vector was via a hash table.
A hash table is a data structure that implements an associative array. Like any
associative array a hash table is used to store many key => value associations (this is a
many to one relationship as the hash table is almost universally smaller than the
number of keys).
Hash table data structure was chosen due to the fast lookup, insertion, and deletion of
(key, value) pairs in addition to number of user-oriented functionality it offers.
Additionally, the Neighbour List is also implemented as a hash table.

38
Other important data structures that are present in the solution are Distance (name D,
the hops H and the name of the neighbour to which we forward packets) – this is used
int the Neighbour list hash table at every node.

3.3.4 Router Class

This class is implemented as a thread and is invoked via the node Daemon. As a
Router process is created, a simple applet window is created which displays a frame
with text area printing the current state of the Router and its activity in real time.
The most noteworthy implementation in this class is the java implementation of the
Distance Vector protocol. The diagrammatic process flow of this protocol is discussed
in section 4.1.5.3.

A key method in this class is sendPackets(). This method is used for sending out all
kind of packets. This is quite a central method used throughout the class as all types of
packets have to be sent out e.g. distance vector, register, register confirm etc.

3.4 Problems encountered.

This section of the chapter is devoted to the discussion of difficulties faced while
carrying out the implementation of the final solution.

The first and most common problem that was encountered was in regards to the
InetAddress object as IP address was widely used, manipulated, and stored throughout
the components. The problem was that calling InetAddress.getAddress() meant having
to convert an array of 4 bytes as returned by InetAddress.getAddress() back to an
InetAddress object. The way this was tackled is listed below, as there seems to be no
cleaner or more efficient way to do it.

public static InetAddress bytes2InetAddress(byte addr[]) {

InetAddress answer = null;
String nets [] = new String[4];
for (int i = 0; i < 4; i++) {
nets[i] = uByte2String(addr[i]);
}
String ipString = nets[0] + "." + nets[1] + "." + nets[2] + "." + nets[3];
answer = InetAddress.getByName(ipString);
return answer;
}

Before the implementation of the node Daemons and the autonomous creation of
Router processes on client machines, each and every Virtual Routers had to be
initialised manually. This was fine, however after the implementation of the node
daemon a number of issues arose,

• With Virtual Routers initialised manually, all the required information was
passed on at command line. This included the Router name. However there is
no such field in the topology file as the Router Name was given at

39
 initialisation. With the node Daemon now initialising the Routers there is no
way of passing in the Router name as the user does not initialise the Routers
any more. This meant going back and changing the format of the topology
file so the Router name can be inserted.

Original Format:
<IP address of Router>< : > <Router port>< = > <IP address of neighbour>< : >
<neighbour port>

e.g. 10.38.66.185:6000=10.38.66.185:5000

New Format:
<IP address of Router>< : > <Router port>< : > <Router Name>< = > <IP
address of neighbour> < : > <neighbour port>>< : > <Router Name>

e.g. 10.38.66.185:6000:router6=10.38.66.185:5000:router5

In addition to this, when the routers were setup manually each Router process had its
own command window as no User Interface has been implemented. However when a
particular node Daemon forks out the Router processes, they are all displayed in the
same command window. This makes it very difficult to make out which command
and output belongs to which Router. This meant that there has to be way of
recognising and dealing with each and individual Router on each machine.

Shows how
the forked
router
processes
have been
separated
into their
individual
windows.

Figure 0-4 representation of Router Objects running.

40
 4 Chapter 5

SYSTEM IN OPERATION
The aim of this chapter is to walkthrough the system and draw attentions to the major
components of the system in operation.

The screenshots show the perspective of just one machine rather than all three. This is
because if screen shots of all three machines were shown then there would be a lot of
repetition and the point can just be easily be made with the representation from one
client.

4.1 Topology to be set up

Machine A IP = 10.0.0.1
Machine B IP = 10.0.0.2
Machine C IP = 10.0.0.3

Figure 0-1Network model of topology to be created

The topology file will look like this:

10.0.0.1:1000:A1=10.0.0.1:2000:A2
10.0.0.1:2000:A2=10.0.0.1:1000:A1
10.0.0.1:1000:A1=10.0.0.2:1000:B1
10.0.0.2:1000:B1=10.0.0.1:1000:A1
10.0.0.1:3000:A3=10.0.0.2:3000:B3
10.0.0.2:3000:B3=10.0.0.1:3000:A3
10.0.0.1:3000:A3=10.0.0.3:2000:C2
10.0.0.3:2000:C2=10.0.0.1:3000:A3
10.0.0.2:1000:B1=10.0.0.3:1000:C1
10.0.0.3:1000:C1=10.0.0.2:1000:B1
10.0.0.2:2000:B2=10.0.0.2:3000:B3
10.0.0.2:3000:B3=10.0.0.2:2000:B2

41
10.0.0.2:3000:B3=10.0.0.3:2000:C2
10.0.0.3:2000:C2=10.0.0.2:3000:B3
10.0.0.3:1000:C1=10.0.0.3:2000:C2
10.0.0.3:2000:C2=10.0.0.3:1000:C1

4.2 RMIREGISTRY setup

Figure 0-2 rmiregistry setup

The rmiregistry command starts a remote object registry on the specified port on the
current host. The rmiregistry command creates and starts a remote object registry on
the specified port on the current host. If port is omitted, the registry is started on port
1099 as it’s the case in the example above.
A remote object registry is a bootstrap naming service that is used by RMI servers on
the same host to bind remote objects to names. Clients on local and remote hosts can
then look up remote objects and make remote method invocations.

4.3 Setting up Node Daemon

42
Figure 0-3 Node Daemon setup
A node daemon is created on each of the client machine. This signifies the node
daemon started on one of the machines. It is waiting to receive a command from the
server to create the Virtual Routers.

4.4 Setting up the Topology Server

Figure 0-4Topology server setup window

The arguments specified in the above command window are Port of Server and
topology file. This shows when the server is activated, it starts to create a router
topology of each router and begin to relay the appropriate information to the specific
node daemon.

Once a topology for each Router is created, all the notification commands are sent, as
shown above informing routers of their directly connected neighbours.

43
4.5 The Creation of Routers and registration

Figure 0-5 Routers initialised and running.

This screenshot signifies the Routers running as created by the Node daemon. There is
real time feedback to the user of packet sending and receiving and distance vector
updating process to mention among others. The output commands may be clarified a
bit more to make them more understandable, this will be done.

The topology setup is just an example of what user can create. The network can be
extensive or as small as preferred.

44
 5 Chapter 6

TESTING
This section will begin by stating the testing criteria for the framework and then show
the results of the tests that are aimed to establish whether the system functions
correctly.

5.1 Testing Criteria/plan

The entire framework was designed to be made up of a host of components which

were implemented individually. As each of the following components relies upon
others it was necessary to thoroughly test each component incrementally. The failure
to discover and correct errors found in previous stages would have made the
successful implementation of the later components impossible. This strategy was
successful in creating a reliable and correct system.

Additionally, there was also some testing done of individual components of the
framework as summarised below. This table contains criteria (tests) that must be
fulfilled.

Component to be tested. Test

Node Daemon start up and Start up the Node Damon and see make sure it
binding. binds correctly.

Server starts up with reading Make sure server starts up correctly with
of topology file.
Topology File reading and Upon reading the correct topology file, the
correct topology generation topology manager component must create the
correct topologies of each Router adding
appropriate neighbours.
Node Daemon creates the Manually compare the correct number of Virtual
correct number of Virtual Routers in the Topology file against the number
Router Objects. that are created.

45
5.2 Test Results

Test 1: We tested this criterion by setting up the Node Daemon on a number of

machines whilst the RMIREGISTRY was running on the host machine (machine
where the server is running). The node Daemon starts up successfully with a
command display stating it has bound to the remote object registry (RMIREGISTRY).

Test 2: This criterion was successfully fulfilled as the topology file was read and the
necessary data extracted from it. This was a simple test and up to this point there has
been no error thrown regarding this process.

Test 3: This test was time consuming as a number of different network topologies
were emulated to make sure the correct topologies are being setup. This involved
designing a number of different combinations of topologies and manually checking
that each Virtual Router was connected to the correct neighbour. Once a connection
between two virtual routers has been setup, the routers receive a neighbour packet and
realise their inter-connection. The periodic update information can be checked to see
which particular virtual router is ending packets to another.

Test 4: This test case was successfully satisfied as in every case of creating a topology
the node daemons always created the correct number of Virtual Router Objects. If an
incorrect number of Virtual Routers were created and attempted to register, validation
procedures would detect this act accordingly. This is exemplified in the below test
case.

46
 6 Chapter 7
Conclusion

7.1 Summary of work

In conclusion, this project has been wholly successful in designing and implementing
a suitable framework that emulates a network topology with the use of Virtual
Routers. Although there is a lot future work to be carried out, the fundamental
underlying mechanisms have been implemented. Extremely useful end-user feedback
has been obtained to confirm that the generated solution will be extremely useful as a
tool for aiding learning of Routing protocols, algorithms and network emulation.

7.2 Future Work

The need of such a GUI was also highlighted in both evaluation cases with fellow
students. One particular area that was highlighted was the area of setting up the
topology. Currently a topology file must be generated to do this; however a
mechanism that allows user to maybe draw their topology on the screen, save
topologies and reload them would add great user-oriented benefits to the framework.
From a developer’s point of view, an area where graphical user interface would be
most beneficial is the area of monitoring the network emulation. Currently all the
Router Objects display the text in their text window and all communication is
displayed in text form. However if there was a mechanism of watching packets
travelling through different paths on the screen and seeing a model of the network that
is currently being emulated would add great deal of benefit to the project.

47
7 REFERENCES

1. Peterson Larry and Davie Bruce Computer Networks: A Systems Approach, 2002
3rd Edition.

2. Orfali Robert , Harkey Dan and Edwards Jeri , Client/Server Survival Guide,
1999, 3rd Edition.

3. Vikram Vijayaraghavan and Guido Appenzeller, The Stanford Virtual Router: a

teaching tool and network simulator, Proceedings of ACM SIGCOMM, Computer
Communications Review, Volume 32, Number 3, July 2002.
http://portal.acm.org/citation.cfm?id=571715&coll=GUIDE&dl=GUIDE&CFID=557
77591&CFTOKEN=98497188

4. Martin Casado, Nick McKeown, The virtual network system, Proceedings of the
36th SIGCSE technical symposium on Computer science education archive.
http://portal.acm.org/citation.cfm?id=571697.571715.

5. Michael J. Jipping, Agata Bugaj , Liliyana Mihalkova, Donald E. Porter, Using

Java to teach networking concepts with a programmable network sniffer: Proceedings
of the 34th SIGCSE technical symposium on computer science education, Reno
Nevada, USA.
http://portal.acm.org/citation.cfm?id=611948&dl=GUIDE&coll=GUIDE&CFID=557
77591&CFTOKEN=98497188,

6. Lewis Barnett, An Ethernet performance simulator for undergraduate networking:

Proceedings of the twenty-fourth SIGCSE technical symposium on Computer Science
Education, p.145-150, Feb1993, Indianapolis, Indiana, United States.

7. The network simulator - ns-2. http://www.isi.edu/nsnam/ns/

48