Added draft of implementation chapter
authorRichard Whitehouse <github@richardwhiuk.com>
Wed, 27 Apr 2011 11:49:13 +0000 (12:49 +0100)
committerRichard Whitehouse <github@richardwhiuk.com>
Wed, 27 Apr 2011 11:49:13 +0000 (12:49 +0100)
implementation.tex

index 03f2c886f46baba61af7d6a7d41569aca9b59f65..e144095916809d5b86aec9e03566c06747a3df50 100644 (file)
@@ -1,2 +1,38 @@
 \chapter{Implementation}
 
+The starting point for the implementation was the ns3 project. This was branched into a new git repository and built on my desktop computer. Once I had ensured that ns3 was working, by using the test routines provided, the next step was to enhance the existing Ethernet implementation.
+
+The inital implementation of a CSMA switch was split into two different parts in order to separate the different functionality, namely into the bridge and a separate class for representing a port on the switch, as this would be needed to hold state in the RSTP implementation. An additional deficency in the CSMA implementation was identified, namely that the state table did not limit the number of entries which could be stored in it. This was fixed, allowing only 8000 host entries to remain in the table at any time. If more than that were in the table, new entries would be dropped.
+
+After this had been completed the structure of the MOOSE implementation was implemented. This primarily involved coding support structures to hold the MOOSE address identifiers, comprising of both a host and switch section. The state of the MOOSE switch was also coded. This involved two separate state table structures. 
+
+The first, indexed by switch identifier, which is mapped to port. This maps other MOOSE switches to allow forwarding of packets.
+
+The second, is indexed by both host identifier and Ethernet addresss, is again mapped to a port on the switch. This holds hosts attached to the switch. The first index is used to forward and translate packets arriving at the switch and being forwarded to the host. The second allows the packets from the host arriving at the switch to be translated into MOOSE packets.
+
+Once this had been completed, the next stage was implementing the translation of packets by the MOOSE switch. This was achieved by using the state tables described above, and sequentially generating a new host identifier, and thus MOOSE address based on the switch's MAC address.
+
+The next stage was implementing ARP rewriting. As ARP packets contain a hardware address inside the packet, they require rewriting by the switch in order for the protocol to work correctly.
+
+At this stage, both Ethernet and MOOSE correctly worked on a acyclic network. As such I implemented a testing framework a simulated a number of packets to verify the work so far was completed correctly.
+
+For the next stage, I implemented static routing. This was done by working out the routing for each switch before hand. For MOOSE I used the Boost Graph Library dykstra implementation. I also used the Boost Graph Library for Ethernet, in that case Kruskall's minimum spanning tree algorithm. However, it soon became obvious that this provides different results than the RSTP algorithm as instead of optimising for total spanning tree length, it optimises distance from the root bridge to each switch.
+
+I replaced the minimum spanning tree algorithm with one which arbitarily selects a root bridge, and then iteratively adds each neighbour to a priority queue, ordered by distance to the root, and then retrieves the first from the queue which isn't already a member of the tree. It terminates when either the queue is empty, or the tree includes all bridges. In the case of all links having the same weight, I optimise to use a normal queue instead.
+
+
+
+% things to write about:
+
+%    refactor
+
+%    moose implementation
+
+%    topology thing
+
+%    routing implementation
+
+%    dynamic routing
+
+%     ....
+