In preparation for the implementation, there were a number of areas which I researched, and a number of decisions I made which affect the implementation of the project.
-\section{Research}
+\section{Learning}
-\subsection{Simulators}
+%\subsection{Data Link Layer}
-Some time was spent investigating the different network simulators available. The most common network simulators used in research are ns2 and ns3. ns2 is programmed in Tcl and C++, while ns3 is developed in C++ and Python.
+\subsection{Simulation}
-ns2 uses Tcl to setup simulations and run them. Tcl - Tool Command Language - is a scripting language specifically designed for customising and configuring the running of large projects by embedding a Tcl interpreter in the application.
+Due to the large number of hosts, switches and links I will be aiming to simulate to demonstrate the weaknesses of Ethernet, and how it compares to MOOSE, I will be using simulation instead of implementing the topology physically. While simulators pose an enormous advantage in terms of the time it takes to change the topology, implement new protocols and explore larger topologies, there are a number of disadvantages, namely that as it is a simulation, it takes time to program a simulator, and this may approach the difficulty in creating a real network, execution can be computationally expensive, and statistical analysis of the simulation in order to verify the results can be difficult.
-ns3 uses Python to do a similar job. However, with ns3, Python is desigined as a optional part of the interface to ns3, and it is perfectly possible to run large simulations written entirely in C++. By solely using C++, writing applications which link with libns3, the application can scale to far more hosts, and doesn't need a heavy binding which is required when using Python, or when using Tcl with ns2.
+As discussed in the introduction, there are a number of different type of simulators - the main distinction being a discrete event simulation or a continuous event simulation. The most suitable for performing network simulation of a packet based architecture is a discrete event simulator, as each movement of a packet may be viewed of as an event in the system.
-\subsection{ns3 and Ethernet}
+In order to ensure that the goals of the project are achievable, and the results are repeatable and useful to others, I will be building upon a existing network simulator. Some time was spent investigating the different network simulators available. A number of differnet simulators are used, though the most popular series is the ns - network simulator - which is available as ns2 and ns3.
-When I decided to settle on ns3, for the reasons outlined above, it was imperative to work out how much code existed in ns3, and how much I would need to write.
+\subsubsection{ns2}
-ns3 ships a CSMA implementation, without collision detection, along with a network bridge implementation, which doesn't conform to the standard \cite{ieee802-1d}. In particular it lacked a RSTP - Rapid Spanning Tree Protocol - implementation.
+ns2 is a discrete event network simulator written for research purposes, and began as a variant of the REAL network simulator in 1989. It has been supported by a number of different institutions since, and has evolved to become one of the most popular network simulators used in network research. ns2 is written in C++, with network scripts written in Tcl. Most of the work in ns is devoted to network layer and above protocols, with the data link layer protocol being largely simplified as a stochastic model underneath the network layer.
-As outlined in 1.4, MOOSE, the 802.11D specification, along with Ethernet implementation details, are entirely off the course which I had to research
+Tcl, Tool Command Language, is a scripting language specifically designed for customising and configuring the running of large projects by embedding a Tcl interpreter in the application. ns2 uses a extended, non standard, version of this OTcl which provides support for object orientated programming.
-\section{Changes to Proposal}
+\subsubsection{ns3}
-\subsection{Network Simulator}
+ns3 is a complete rewrite of the ns network simulator, again in C++, with Python bindings instead of Tcl. It began in 2006 as a new software development effort intended to focus on improving the software design, architecture, integration and modularity of the existing ns codebase. It was designed as a four year project to produce the next version of ns. It was based on the design of GTNets and is built using the Python based waf build program.
-While the original proposal indicated that the project would be written for ns2, after research into the simulator, I decided that it would advantageous to utilise ns3 instead. ns2 is the current defacto standard for network simulation. Released in 1996, it consists of C++ and oTcl scripts to reduce the number of recompilation required to perform network simulations. ns3 however is primarily written in C++, with Python bindings. Written on a base of GTNetS \cite{gtnets}, it is a simulator with much better scalability characterisitics. \cite{ns-comparison} It also includes a advanced feature set, and a number of papers have been written using it is a base, which shows it's depth as a simulator, \cite{ns3-1} and \cite{ns3-2}. Also, based on my evaluation of the code, ns3 provides much better separation of concerns and much more active development base. For these reasons I have chosen to use ns3 instead of ns2.
+ns3 includes a representative implemention of Ethernet. It includes the necessary support structures to resemble both LLC, Logical Link Control, and DIX, DEC, Intel and Xerox, the three major participants in the design, Ethernet frame types. However, it is only a CSMA, Carrier Sense Medium Access implementation, as it provides no modelling of the physical layer. As I will be simulating fully switched networks using full duplex, the lack of Collision Detection should not effect my results.
+
+ns3 includes a sample Ethernet Bridge implementation, however this is not 802.1D compliant as it is lacking any support for a Spanning Tree protocol, it simply filters and floods packets.
+
+ns3 allows the use of Python to control the simulation. However in ns3 Python is desigined as a optional part of the interface to ns3, and it is perfectly possible to run large simulations written entirely in C++. By solely using C++, writing applications which link with libns3, the application can scale to far more hosts, and doesn't need a heavy binding which is required when using Python, or when using Tcl with ns2.
+
+Unlike ns3, ns3 is in active development and is considered the natural successor to ns2, once the remaining protocols have been implemented for ns3.
+
+\subsection{Conclusion}
+
+While the original proposal indicated that the project would be written for ns2, after research into the different simulators, I decided that it would advantageous to utilise ns3 instead. I originally chose ns2 as it was the apparent defacto standard for network simulation. However, due to its age, and the improved data link layer support in ns3, I have decided to use ns3 instead. This will improve the longevity of the results of my project, as they will be able to be used with the new simulator.
+
+ns3 will also improve the quality of the code I produce, as I will be able to follow the improved software architecture provided, which will make it easier to debug the code I write, and verify that it is performing correctly.
\section{Strategy}
projects / ii-diss.git / commitdiff