Virtual Routing Network Emulation Frame Work

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 Professor and Head CSED NIT Calicut

Mr K.A.Abdul Nazeer Project Guide Senior Lecturer 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 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 1

5

5

6

7 8

4.3.4 Router Class .........................................................................................39 4.4 Problems encountered..................................................................................39 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 TESTING.............................................................................................................45 6.1 Testing Criteria/plan ....................................................................................45 6.2 Test Results..................................................................................................46 Conclusion ...........................................................................................................47 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.

1

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. E 4 B

F

6 3

A

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

1.8.3

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). 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 readvertisement. 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

C

B

D

3

Figure

1. 2. 3. 4.

X

A

C

B

X

A

C

B

D

4

X

A

C

B 0-4

D Link

State

Flooding

D technique

LSP arrives at node X. X floods LSP to A and C. A and C flood LSP to B (but not X). 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 continuously running and when activation from the framework is detected, a router process may be created or a router process continuously running but dormant until activation.

How will the Routers be initialised and managed?

How will the user specify the topology which is to be generated?

Initial Ideas and requirements (some of which have been already highlighted in the introductory chapter) that have emerged from meetings with final year project guide and brainstorm of ideas/questions for the final solution.

Feedback relevant information in real time to user. E.g. regarding network topology as new paths are added and taken down and new routers are discovered etc.

There should be some functionality that allows user to model link failure, addition of new routers/paths

How will these concepts be modelled over a real network?

• • •

Through a topology file loaded into the framework? Through command line? Pre-set topologies?

Virtual Routers; Virtual connection / link; Virtual connection failure or virtual errors; Virtual connection establishment; Virtual router or path addition; Virtual packets;

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

As this process may be based on the supply of many items of information, e.g. IP address and port numbers, it may be best to provide this information through a file.

User specifies router topology b

Framework responsible for activation of Routers, their connectivity and validation checks. Etc.

‘Interconnecting Framework.’

Router Object 1.

Router Object N.

Router Object 2.

Router Object 3.

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

Figure 0-1 A Basic model of flow control

21

Major Design Decisions and Justification

2.2

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: < : > < = > < : >

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

Sender - an identification mechanism, e.g. neighbouring Router name. Senders IP address – IP address if neighbouring Router. Target IP address – IP address of Target Router. 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.

Router informed with required information (its specific topology)

Figure 0-2 model showing the validation process of Router Objects

Decision. Here the sending Router’s registration command is processed. The receiving process will check against the topology file and stored information whether to allow the Router permission to 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 demultiplexing 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 10.38.66.185

IP address 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

Node Manager

10.38.66.186 Router Object

Router Object

Router Object 10.38.66.187 Router Object 10.38.66.188 Router Object

Represents the forking of Router Objects.

Router Object

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:5000

10.38.66.185:3000

10.38.66.185:9000

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 Serverside 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 Vector packet from Router N.

Is Router N in neighbour list?

NO

Add Router N to 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:

If present entry in Distance vector contains (D, h, *) and H+1 <= h then update that entry to (D, H+1, N).

YES

Entry present for destination D is in own distance vector?

NO

Add (D, H+1, N)

Finally, for any entry (d, *, N) in your vector, and N's vector has no entry for d, remove your entry.

Figure 0-2 Flow chart of Distance Vector Processes

34

EN

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: < : > < = > < : > e.g. 10.38.66.185:6000=10.38.66.185:5000 New Format: < : > < : > < = > < : > >< : > 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 that are created. Router Objects.

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