\end{itemize}
-Each topology type takes a number of parameters and outputs a topology as a result. This topology is then stored in a file.
+Each topology type takes a number of parameters and outputs a topology as a result. This topology is then stored in a file. The topology types were chosen as they provide a sample of different topologies being considered in data centers, which is the suggested target for MOOSE.
\subsection{Simulation}
The first stage is to setup up the network. This is done by reading in a topology file and converting it into a series of ns3 objects. These are then stored in the Network class. This is done by loading the topology file into a Topology object, and then passing it to the Link Layer Helper. This also takes whether the simulation should be done using MOOSE or Ethernet and whether dynamic or static routing should take place.
-First it creates a node to represent each of the hosts and bridges in the topology. It then creates the Ethernet links between the hosts and bridges, and the links between the bridges as specified in the topology file. Each Ethernet link is Gigabit, with a 2 millisecond delay.
+First it creates a node to represent each of the hosts and bridges in the topology. It then creates the Ethernet links between the hosts and bridges, and the links between the bridges as specified in the topology file. Each Ethernet link is Gigabit, with a 20 nanosecond delay.
Once it has done this, it configures the routing. Early in the project, I decided to allow two different forms of routing, static and dynamic.
-Static routing is done at setup time by running an algorithm across all the ndoes to determine the network map. In the case of Ethernet it runs a static spanning tree algorithm, whereas in MOOSE it runs a all pairs shortest path algorithm by running Dijkstra's algorithm on each node. It can do this more efficently than running Johnson's algorithm as all the path costs are known to be positive. This is implemented using the Boost Graph library implementation of Dijkstra - \cite{boostgraph}.
+Static routing is done at setup time by running an algorithm across all the ndoes to determine the network map. In the case of Ethernet it runs a static spanning tree algorithm, whereas in MOOSE it runs a all pairs shortest path algorithm by running Dijkstra's algorithm on each node. It can do this more efficently than running Johnson's algorithm as all the path costs are known to be positive. This is implemented using the Boost Graph library implementation of Dijkstra's algorithm \cite{boostgraph}.
Dynamic routing on the other hand relies on the interchange of BPDU - Bridge Protocol Data Units for Ethernet as outlined in \cite{ieee802-1d} for the Rapid Spanning Tree protocol. MOOSE however can use a routing protocol - OSPFM (Open Shortest Path First for MOOSE), an implementation of OSPF \cite{rfc2328}, is suggested in \cite{dwh}. This happens during the running of the simulation.
Once the routing has been configured, the Link Layer Helper initalises a BridgeNetDevice on each bridge node in the case of Ethernet, or a MooseBridgeNetDevice in the case of MOOSE. This represents a switch and contains the implementation of the Link Layer protocol on the switch. The BridgeNetDevice and MooseBridgeNetDevice objects are created through the use of another factory class, BridgeNetDeviceHelper and MooseBridgeNetDeviceHelper respectively. These are responsible for creating the bridge and ports on the bridge.
-A pre-existing BridgeNetDevice implementation exisisted for Ethernet, it was incomplete, with no support for RSTP - Rapid Spanning Tree Protocol. It also had no limit on the size of the state table, and was implemented in a single class. I decided to split it up into several different classes to separate the different concerns. It now uses a BridgeNetDevice, with each port on the Bridge represented as a number of BridgePortNetDevice objects which controls the reception and transmission of packets on each port, and a BridgeState class which holds the state table for the Bridge. By performing this separation of concerns, the implementation ensures that each concern is handled efficently.
+A pre-existing BridgeNetDevice implementation existed in ns3 for Ethernet; it was incomplete, with no support for RSTP (Rapid Spanning Tree Protocol). It also had no limit on the size of the state table, and was implemented in a single class. I decided to split it up into several different classes to separate the different concerns. It now uses a BridgeNetDevice, with each port on the Bridge represented as a number of BridgePortNetDevice objects which controls the reception and transmission of packets on each port, and a BridgeState class which holds the state table for the Bridge. By performing this separation of concerns, the implementation ensures that each concern is handled efficently.
A similar approach was taken to implementing the MooseBridgeNetDevice, which again has a number of MooseBridgePortNetDevice objects to represent each port on the bridge, and a MooseBridgeState object to hold the bridge's state.
\subsubsection{Data}
-The next stage is to setup the data streams across the network. This is setup based on a file input which details which hosts to send what data to and from which hosts.The data file lists the time to start sending data, the host to send from, the host to send to, and the number of packets to send. This flexible format allows the simulation to simulate a large variety of different traffic scenarios.
+The next stage is to setup the data streams across the network. This is setup based on a file input which details which hosts to send what data to and from which hosts. The data file lists the time to start sending data, the host to send from, the host to send to, and the number of packets to send. This flexible format allows the simulation to simulate a large variety of different traffic scenarios.
Each UDP packet is sent from a UdpClient installed on the sender for each set of packets, to a UdpServer which is installed once per recipient, on port 9, the standard port for discarding packets \cite{rfc863}.
By analysing this file we can gain an insight into how efficent the routing protocols are, how long each packet took to traverse the network and other simulation metrics.
-The analysis program parses the CSMA file and collects the statistics on the packets observed before outputting them to a file. It also creates a graph displaying the nodes in the network topology.
+The analysis program parses the CSMA file and collects statistics on the packets observed before outputting them to a file. These include the number enqueued, dequeued, recieved and dropped. The packets are classified into ARP requests, ARP responses and UDP packets. Counts are also kept for unicast and broadcast packets, as well as a total. It also looks at the state table, and counts the number of entries for each table, for each bridge.
+
+It also creates a graph displaying the nodes in the network topology.
\subsection{File Formats}
\subsection{Topology Representation}
-The topology is represented internally with a a std::map between hosts and bridges, since each host may only appear on one bridge, and a std::set of pairs which contains bridge to bridge links with a custom comparator. The custom comparator is designed in order to give a total order to links, without caring about order, as links are bidirectional. Thus $<1,2>$ is treated equal to $<2,1>$. The order defined is that $<1,2> < <1,3> < <4,1> < <3,4>$, in other words, the lower number is used for the primary sort, and the larger one as a secondary sort. These provided adequate performance for the purpose.
+The topology is represented internally with a a std::map between hosts and bridges, since each host may only appear on one bridge, and a std::set of pairs which contains bridge to bridge links with a custom comparator. The custom comparator is designed in order to give a total order to links, without caring about order, as links are bidirectional. Thus $<1,2>$ is treated equal to $<2,1>$. The order defined is that $<1,2> < <1,3> < <4,1> < <3,4>$, in other words, the lower number is used for the primary sort, and the larger one as a secondary sort. These provided adequate performance for the purpose. A total order is required so that the set can ensure that each link is only stored once. The simplest way to do this is to provide a total order, and then a binary search can ensure it is unique.
\subsection{MOOSE State Tables}
-In order to hold the data required for the MOOSE implementation a series of tables were designed. While in reality these would be implemented in CAM (Content Addressable Memory) in order to provide O(1) performance, in this implementation they are implemented using std::map.
+In order to hold the data required for the MOOSE implementation a series of tables were designed. These are implemented using the std::map data structure. This is used as it provides fast, $O(log(n))$, lookup speed. This is important for the state table in which data is fetch by a predefined index.
The first is the Prefix table. This handles MOOSE traffic which is remote to this bridge. This provides a Prefix to Port and Expiration Time mapping. This is updated when traffic from that bridge is arriving at the bridge, the switch stores a bridge to port mapping. This will also be updated by the routing protocol. When data is to be sent to the specified prefix, the port is looked up, and after making sure it is still valid, the packet is sent on that port.
-The second is the Suffix table. This maps MOOSE Suffix Addresses (i.e. the host part) to a Ethernet address. This is indexed by both Ethernet address (48 bit MAC Address) and the suffix. The former index is used when converting incoming packets to the correct address, the later when converting incoming packets from the host, to the correct MOOSE address.
-
-The third table is the Port table. This maps MOOSE Suffix Addresses to the correct port. This is updated when a packet comes from the host, and used when a packet is sent to the host in question.
+The second is the Suffix table. This maps MOOSE Suffix Addresses (i.e. the host part) to a Ethernet address and a Port.. This is indexed by both Ethernet address (48 bit MAC Address) and the suffix. The former index is used when converting incoming packets to the correct address, the later when converting incoming packets from the host, to the correct MOOSE address. This is done by providing one std::map which maps between Ethernet address and a structure containing the suffix, the port and the MAC address, and another std::map which maps between suffix and a reference to this structure. When an entry is added or removed to one map, the same takes place in the other map to ensure they remain in sync.
\subsection{Reverse Path Forwarding}
\subsection{Static Routing}
-The MOOSE implementation has a static routing algorithm. This simply consists of insert all the bridges and links into a graph, assigning a weight for each link, in this case, since all the links are the same, they are all given a weight of 1, and the running Dijykstra's algorithm \cite{dijkstra} across all pairs of nodes. This is an optimisation of Johnson's algorithm, as it is known that there are no negative weights, and as such there is no need to run the Bellman-Ford algorithm. As such, it has complexity $O(n^{3})$.
+The MOOSE implementation has a static routing algorithm. This simply consists of insert all the bridges and links into a graph, assigning a weight for each link, in this case, since all the links are the same, they are all given a weight of 1, and then running Dijkstra's algorithm \cite{dijkstra} across all pairs of nodes.
+
+While Johnson's algorithm which returns all-pairs shortest paths would be the usual choice for such a operation, as we know that there are no negative weights, there is no need to run the Bellman-Ford algorithm, which is designed to eliminate such an occurence.
+
+As Dijkstra's algorithm has a complexity of $O(e + n log(n) )$, the static routing has a complexity of $O(ne + n^{2}log(n))$ since there are $n$ switches to run it across. This is the same as Johnson's algorithm, but faster due to a smaller constant factor.
%\subsection{Dynamic Link State Routing}
Since the number of hosts will need to be very large in order to demonstrate the issues associated with Ethernet, and they will be arranged in a number of different topologies, the most suitable mechanism in order perform this evaluation is under simulation, where the topology of the network can easily be altered.
-In this paper, I aim to make a quantatative evaluation of Ethernet and one of the proposed improvements, MOOSE, comparing them under a variety of different situations. I have chosen to focus on MOOSE as other protocols, like SEATTLE, have already been evaluated \cite{seattle-2}. In order to do this, I set out to create a representative implementation of the protocols on a modern network simulator, and run tests to explore their differences.
+In this paper, I will describe the creation of a representative implementation of Ethernet and one of the proposed improvements, MOOSE, for a network simulator. I have chosen to focus on MOOSE as other protocols, like SEATTLE, have already been evaluated \cite{seattle-2}. I will then use these implementations to run tests to explore their differences and make a quantitative evaluation under a number of different situations.
\section{Background}
-First a look at what Data Link Layer protocols do and where they sit in the network stack, and secondly a look at simulation techniques.
-
\subsection{Protocol Stack}
When implementing a computer network architecture, it is advantageous to separate the different functions into different protocol layers, with each layer providing services the layer above, and requiring services from the layers below. By performing this separation, we can divide up the complexity required to be implemented. This is done by each layer providing an abstraction for the layer above and below. This allows each layer to concentrate on only providing a small amount of functionality. This technique also allows the system to be modular, and allows us to select different protocols to perform different tasks for different applications on different architectures.
-Several different proposals have been made for the different layers of the network stack, the seven layer ISO OSI Model \cite{osi} and the three layers in the Internet Protocol Suite \cite{rfc1122}. In practice the model used by the Internet Protocol is largely represenative, along with a additional physical layer and link layer.
+Several different proposals have been made for the different layers of the network stack, the seven layer ISO OSI Model \cite{osi} and the three layers in the Internet Protocol Suite \cite{rfc1122}. In practice the model used by the Internet Protocol is largely representative, along with a additional physical layer and link layer.
Each layer describes the protocol data unit (PDU) used, as well as a the services it provides, and the terminilogy used.
\subsubsection{Data Link Layer}
-The data link layer layer providees basic addressing and controlling access to the physical layer, as well as subnet routing. A subnet is a small part of the complete network, often this maybe a Local Arean Network (LAN), though it may be as wide as an entire city, or just a small component of a LAN. This layer provides easy mobility of hosts among the subnet, without requiring reconfiguration. The dominant protocol in this area is Ethernet as part of IEEE 802.3. Data sent to this layer is encapsulated in a Ethernet frame, which then has additional data placed at the header and trailer of the frame.
+The data link layer providees basic addressing and controlling access to the physical layer, as well as subnet routing. A subnet is a small part of the complete network, often this may be a Local Arean Network (LAN), though it may be as wide as an entire city, or just a small component of a LAN. This layer provides easy mobility of hosts among the subnet, without requiring reconfiguration. The dominant protocol in this area is Ethernet as part of IEEE 802.3. Data sent to this layer is encapsulated in a Ethernet frame, which then has additional metadata placed at the header and trailer of the frame.
\subsubsection{Network Layer}
-The network layer provides routing across the wider network, and identification of hosts on a global scale, with current networks having estimated as having a billion hosts. The primary protocol in this area is IP - Internet Protocol, in particular IPv4 \cite{rfc791} although IPv6 \cite{rfc1883} is starting to gain traction due to impending address exhaustion \cite{icann-030211}. This provides IP Packets as the primary abstraction
+The network layer provides routing across the wider network, and identification of hosts on a global scale, with current networks having estimated as having a billion hosts. The primary protocol in this area is IP - Internet Protocol, in particular IPv4 \cite{rfc791} although IPv6 \cite{rfc1883} is starting to gain traction due to impending address exhaustion \cite{icann-030211}. This provides IP Packets as the primary abstraction.
\subsubsection{Transport Layer}
Network simulation is a evolving area of research, with many different simulators and simulation techniques being used. It is rapidly becoming the most popular way of performing large scale network research for both local area networks, and the wider internet due to the low cost and speed of iteration of different tests that it allows. When testing networks of significant scale, the approach commonly taken is to verify it works on a small testbed, before scaling up under simulatuion.
-There are a number of different approaches to simulating a computer network architecture. The first is discrete event simulation. Here a simulator is primed with a topology and a number of event sources. These event sources fire events, which are executed in turn, which may then fire other events. The events are stored in a priority queue. Each event is executed according to it's time, with a global variable containing the current time of the simulation being advanced upon the executing of each event. This is continued until either there are no more events left in the queue, or some predefined time has passed. This simulation technique has the advantage that areas in which nothing of interest are passed over quickly, while events which are notable are where the majority of the computation is spent.
+There are a number of different approaches to simulating a computer network architecture. The first is discrete event simulation. Here a simulator is primed with a topology and a number of event sources. These event sources fire events, which are executed in turn, which may then fire other events. The events are stored in a priority queue. Each event is executed according to the time associated with it, with a global variable containing the current time of the simulation being advanced upon the executing of each event. This is continued until either there are no more events left in the queue, or some predefined time has passed. This simulation technique has the advantage that periods of time in which nothing of interest occurs are passed over quickly, while events which are notable are where the majority of the computation is spent.
-Other types of network simulation include markov chain simulations which are useful for modelling queueing systems. These depend on systems with little state that can be modelled by a stochastic process. This isn't the case for packet simulation, where there is a large amount of state and no overall defined equation across the entire simulation.
+Other types of network simulation include Markov chain simulations which are useful for modelling queueing systems. These depend on systems with little state that can be modelled by a stochastic process. This is not the case for packet simulation, where there is a large amount of state and no overall defined equation across the entire simulation.
-A further type of simulation is continuous simulation where the timestep is incremented, and events ocurring between the two states are modelled. This works well for physical phonomena, such as radio waves or propogation of signals in wires where the situation is continually evolving. However, they spend the same processing power on all periods of time during the simulation, whether the period is one of high activity or low activity. Also, in order to get a good representation of the underlying phonemena, you have to use very small time increments which gives a high simulation cost.
+A further type of simulation is continuous simulation where the timestep is incremented, and events ocurring between the two states are modelled. This works well for physical phonomena, such as radio waves or propagation of signals in wires where the situation is continually evolving. However, they spend the same processing power on all periods of time during the simulation, whether the period is one of high activity or low activity. Also, in order to get a good representation of the underlying phonemena, you have to use very small time increments which gives a high simulation cost.
\section{Context}
-The most important work in this area is set out by Scott et al \cite{moose1} which sets out the ideas behind MOOSE which this paper aims to test under simulation. A prototype NetFPGA implementation also exists by Wagner-Hall et al \cite{moose2} which outlines a practical implementation of MOOSE is described.
+The most relevant work in this area is set out by Scott et al \cite{moose1} which sets out the ideas behind MOOSE which this paper aims to test under simulation. A prototype NetFPGA implementation also exists by Wagner-Hall et al \cite{moose2} which outlines a practical implementation of MOOSE. No implementation of MOOSE exists for any network simulator.
\section{Aims}
-I aimed to implement a simulation capable of simulating MOOSE and Ethernet networks on a commodity PC to give a realistic comparison of MOOSE and Ethernet within a number of areas:
+I aimed to implement a simulation capable of simulating MOOSE and Ethernet networks on a commodity PC to give a realistic comparison of MOOSE and Ethernet.
-\begin{itemize}
+This will involve designing and developing a number of components:
-\item The size of the state data held by the switch and change in performance characteristics as this reaches a predefined limit.
+\begin{itemize}
-\item The amount of overhead in terms of control messages relative to the amount of data transfered.
+\item The size of the state data held by the switch.
\item The efficiency of the routes used by the protocol.
+\item The different behaviours when broadcasting data and unicasting data.
+
\end{itemize}
I aim to show how MOOSE and Ethernet compare as the number of hosts under simulation rises.
Ethernet is the most widely deployed and used Local Area Networking - LAN - technology currently in the market. While the physical layer of the standard has undergone a number of iterations, the data link layer protocol has remained largely stagnant due to the lack of motivation and a desire for interoperability with current equipment.
-Ethernet was first described in a memo on May 22, 1973 at Xerox PARC by Bob Metcalfe \cite{ethernet} who designed it to interconnect workstations and printers in a modern computer network \cite[p.~125]{spurgeon}. It was to be a shared medium network based on the previous work by the University of Hawaii in the late 1960's with the Aloha protocol \cite{abramson}. Ethernet used the CSMA - Carrier Sense Multiple Access - designed for ALOHA for and added Collision Detection, to create a cable connected shared medium network. This allowed the original Ethernet networks to be a single shared medium network where all the computers were connected together using a series of cables. Every computer on the network would receive all the packets and, based on the header, the Ethernet interface would inform the system when a packet arrived which was for the host in question.
+Ethernet was first described in a memo on May 22, 1973 at Xerox PARC by Bob Metcalfe \cite{ethernet} who designed it to interconnect workstations and printers in a modern computer network \cite[p.~125]{spurgeon}. It was to be a shared medium network based on the previous work by the University of Hawaii in the late 1960's with the Aloha protocol \cite{abramson}. Ethernet used the CSMA - Carrier Sense Multiple Access - schema designed for ALOHA for and added Collision Detection, to create a cable connected shared medium network. This allowed the original Ethernet networks to be a single shared medium network where all the computers were connected together using a series of cables. Every computer on the network would receive all the packets and, based on the header, the Ethernet interface would inform the system when a packet arrived which was for the host in question.
-This relied on each computer having a unique address to which it could be sent packets, which the controller would listen out for. This was also the only required property - the address did not need to be transferable, it did not need to describe any information about the owner and it did not need to contain routing information. In order to provide this guarantee, Ethernet controllers were allocated a 48 bit long address. The first three bytes, 24 bits, consist of one bit which determines whether the packet is multicast / broadcast or unicast, one bit which determines whether the address is locally administered or universally administered, and then the remaining 22 bits, which in the case of unicast, universally administered addresses, are used to designate a manufacturer, and are assigned by the IEEE.The last three bytes are assigned by the manufacturer, with the manufacturer guaranteeing that the address is unique, with additional block of of addresses allocated when a manufacturer had run out. Each manufactuer gives each interface a unique address by incrementally assigning the addresses within each block.
+This relied on each computer having a unique address to which it could be sent packets, which the controller would listen out for. This was also the only required property - the address did not need to be transferable, it did not need to describe any information about the owner and it did not need to contain routing information. In order to provide this guarantee, Ethernet controllers were allocated a 48 bit long address. The first three bytes, 24 bits, consist of one bit which determines whether the packet is multicast / broadcast or unicast, one bit which determines whether the address is locally administered or universally administered, and then the remaining 22 bits, which in the case of unicast, universally administered addresses, are used to designate a manufacturer, and are assigned by the Institute of Electrical and Electronics Engineers.The last three bytes are assigned by the manufacturer, with the manufacturer guaranteeing that the address is unique, with additional block of of addresses allocated when a manufacturer had run out. Each manufactuer gives each interface a unique address by incrementally assigning the addresses within each block.
-As network traffic increased, and more computers were added to local area networks, the reality of all computers sharing a single shared media with which any packet would collide with other traffic became impractical. This was exacerbated by computers being located far away from each other, descreasing the utility of Carrier Sense, increasing the likelihood of collision, which is followed by a process where each host backed off before trying again, thus decreasing utilisation of the network.
+As network traffic increased, and more computers were added to local area networks, the reality of all computers sharing a single shared media with which any packet would collide with other traffic became impractical. Computers were also being placed further away from each other. Ethernet defines a limit on the distance between hosts, as when it increases, it decreases the utility of Carrier Sense which increases the likelihood of collision, which causes a process where each host backed off before trying again, thus decreasing utilisation of the network.
The solution to this was to split the single collision domain into a set of different domains which would be joined together using network bridges to form a single broadcast domain \cite{ieee802-1d}. The bridge, or switch as it is also known due to the manner in which it operates, filters traffic between the different collision domains, only sending traffic where it is required. As the number of hosts on the network, and the speed of network traffic increased, more and more collision domains were created. Modern Ethernet networks are entirely switched networks with each host having a full duplex point to point link to the local switch, and each switch being connected directly to other switches, to form a network topology.
-The next problem was that as networks became more vital to the operation of a business, it became desirable to have redundant links, so that when a link failed, traffic could be diverted. In order to allow this the switches were often arranged in a way that formed topological loops. However, the Ethernet protocol relies on traffic being sent to a tree, and not a graph with cycles in it, in order to prevent broadcast traffic from cycling the network endlessly using up all the available bandwidth. In order to solve this Ethernet uses a spanning tree protocol in order to convert the graph of switches into a tree. This tree is not guaranteed to be a minimum spanning tree, instead it is guaranteed that all switches have the shortest possible path to a root bridge, which may be specified by the network administrator.s. The current iteration of this protocol is the Rapid Spanning Tree Protocol, RSTP, which changes the state of links until that condition is met. In practical terms this means that redundant links which could be used to increase the available network bandwidth are instead disabled. Should the state of the network change, they will be re-enabled to allow the network to continue to operate.
+The next problem was that as networks became more vital to the operation of a business, it became desirable to have redundant links, so that when a link failed, traffic could be diverted. In order to allow this the switches were often arranged in a way that formed topological loops. However, the Ethernet protocol relies on traffic being sent to a tree, and not a graph with cycles in it, in order to prevent a broadcast storm. This is where broadcast traffic cycles the network endlessly using up all the available bandwidth. In order to solve this Ethernet uses a spanning tree protocol in order to convert the graph of switches into a tree. This tree is not guaranteed to be a minimum spanning tree, instead it is guaranteed that all switches have the shortest possible path to a root bridge, which may be specified by the network administrators. The current iteration of this protocol is the Rapid Spanning Tree Protocol, RSTP, which changes the state of links until that condition is met. In practical terms this means that redundant links which could be used to increase the available network bandwidth are instead disabled. Should the state of the network change, they will be re-enabled to allow the network to continue to operate.
\subsubsection{Bridge Implementation}
When the bridge receives an Ethernet frame, it looks at the source address and learns the combination of the source and the port in came in on. It then looks up the destination address and if it finds a match, it will send it out on that port. However, if it fails to find a match it will flood the data on all ports, except the one it came in on.
-Should the state table become full, it will be forced to drop an entry from the state table in order to store the new one. This will mean that when a new packet comes from that destination, it will be flooded.
+Should the state table become full, it will be forced to drop an entry from the state table in order to store the new one. This will mean that when a new packet arrives for that destination, it will be flooded.
-In any Ethernet network, all destinations appear in all the state tables. This is because the first copy of a frame to a bridge will be flooded, meaning that all switches will get a copy of the frame.
+In any Ethernet network, all destinations will almost always appear in all the state tables. This is because each host utilises ARP, the Address Resolution Protocol, to resolve IP addresses to Ethernet addresses. When a query is sent out, it is broadcast, and as data kept by hosts is only cached for a short amount of time, each must send a broadcast packet regularly if it is sending traffic. When a host sends a broadcast packet, it will cause it's address to be entered into all the state tables.
\subsubsection{Limitations}
% TODO: Additional limitations
-As Ethernet addresses contain no routing information, unlike IP addresses in which parts of the network space are delegated to segments of the network, it is impossible in a practical scenario to perform any form of address aggregation. This means in order for network switches to switch traffic between different network segments it has to contain a lookup between each address and the port to send the data. Due to the high speed at which modern network links operate, this has to be done quickly. Depending on the switch, this might be done using Content Addressable Memory, CAM, \cite{cam} which provides $O(1)$ lookup time for unsorted data, however is very expensive in large blocks and consumes considerable amounts of power. Alternatively it can be done using a lookup table, which while cheaper, provides worse performance as the number of entries grows. Since the time spent processing a frame is critical, this limits the feasible size of the state table. This means that modern Ethernet switches have a practical state table size maximum of between 8000 and 32000 hosts \cite{switchds}.
+As Ethernet addresses contain no routing information, unlike IP addresses in which parts of the network space are delegated to regions of the network, it is impossible in a practical scenario to perform any form of address aggregation. This means in order for network switches to switch traffic between different network segments it has to contain a lookup between each address and the port to send the data. Due to the high speed at which modern network links operate, this has to be done quickly. Depending on the switch, this might be done using Content Addressable Memory, CAM, \cite{cam} which provides $O(1)$ lookup time for unsorted data, however is very expensive in large blocks and consumes considerable amounts of power. Alternatively it can be done using a lookup table, which while cheaper, provides worse performance as the number of entries grows. Since the time spent processing a frame is critical, this limits the feasible size of the state table. This means that modern Ethernet switches have a practical state table size maximum of between 8000 and 32000 hosts \cite{switchds}.
-Current trends in data centres, with large numbers of machines in a dense configuration \cite{facebook}, with each machine able to contain multiple hosts via virtualisation software such as Xen \cite{xen}, giving each host a virtual Ethernet controller causes this limit to be exceeded \cite{moose1}. As such, the number of hosts on the network will exceed the size of state table. This will cause any host's whose state can not be stored in the switch to have their frames entering the switch being flooding the frame on every port. As such the overall traffic on the network will increase, decreasing the utilisation and increasing the delay per packet.
+Current trends in data centres, with large numbers of machines in a dense configuration \cite{facebook}, with each machine able to contain multiple hosts via virtualisation software such as Xen \cite{xen}, giving each host a virtual Ethernet controller, it is increasingly likely that this limit will be exceeded \cite{moose1}. This will cause any host whose state isn'tstored in the switch to have their frames entering the switch to be flooded as a new frame on every port. As such the overall traffic on the network will increase, decreasing the utilisation and increasing the delay per packet.
Another limitation is that when the spanning tree protocol converts the network to a tree from the inital graph topology, it disables the number of available links. By doing this, it reduces the available network bandwidth. With a better routing protocol, these links could be put to use to decrease the shortest path between two hosts, as well as being used for multipath routing.
% TODO: Make this section clearer. Add graphic
-MOOSE, Multi-level Origin-Organised Scalable Ethernet, is a proposed improvement on the Ethernet protocol that is designed to be backwards compatible with the large number of ethernet controllers currently in the market place. MOOSE can be implemented in a network by replacing the code operating the bridges. This can either be done by replacing the bridges with a MOOSE bridge, or by installing the MOOSE code on the existing bridges, if they are capable.
+MOOSE, Multi-level Origin-Organised Scalable Ethernet \cite{moose1}, is a proposed improvement on the Ethernet protocol that is designed to be backwards compatible with the large number of ethernet controllers currently in the market place. MOOSE can be implemented in a network by replacing the code operating the bridges. This can either be done by replacing the bridges with a MOOSE bridge, or by installing the MOOSE code on the existing bridges, if they are capable.
MOOSE performs in place rewriting of Ethernet datagrams on the switch in order to provide the aggregation of addresses on a per switch basis. By providing for routing information within the address, the MOOSE switch allows for traffic to be routed between MOOSE switches, allowing for better utilisation of network links.
The MOOSE address is then constructed in two separate parts. The first is the switch identifier, which is the switch to which the host is directly attached. The second part is the host identifier. This gives MOOSE addresses a hierarchical nature, allowing routing based on the identifier, as well as allowing aggregation of host addresses under one switch.
-Each host is assigned a single host identifier, and when the switch recieves traffic from the host, it rewrites the source address to contain the MOOSE address of the host. For example, when a host is attached to a switch with a MOOSE address of 02:00:01:00:00:00, it will be assigned a MOOSE address sch as 02:00:01:00:00:01 and any traffic it sends will be rewritten to this address. When traffic is recieved by the switch at this address, it will be rewritten back to the hosts' MAC address and sent to the host. If another host is attached, it will be assigned 02:00:01:00:00:02 and so forth. A host attached to a different switch on the same subnet, might be assigned to 02:00:02:00:00:00.
+Each host is assigned a single host identifier, and when the switch receives traffic from the host, it rewrites the source address to contain the MOOSE address of the host. For example, when a host is attached to a switch with a MOOSE address of 02:00:01:00:00:00, it will be assigned a MOOSE address such as 02:00:01:00:00:01 and any traffic it sends will be rewritten to this address. When traffic is received by the switch at this address, it will be rewritten back to the host's MAC address and sent to the host. If another host is attached, it will be assigned 02:00:01:00:00:02 and so forth. A host attached to a different switch on the same subnet, might be assigned to 02:00:02:00:00:00.
In the state table, a MOOSE switch contains a mapping between host identifiers and MAC addresses and ports, and a separate state table mapping between switch identifiers and ports. By aggregating all of a switch's hosts under a single entry in the state table, a vast reduction in size is achieved.
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.
-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.
+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 ns - network simulator - which is available as ns2 and ns3.
\subsubsection{ns2}
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.
-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 will not effect the results I collect.
+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 Multiple Access implementation, as it provides no modelling of the physical layer. As I will be simulating fully switched networks using full duplex links, the lack of Collision Detection will not affect the results I collect.
ns3 includes a sample Ethernet Bridge implementation, however this is not 802.1D compliant as it is lacking support for a Spanning Tree protocol, it simply filters and floods packets.
\subsection{Software Development Methodology}
-I decided to use a iterative development method, in order to maintain quality of the code, and to ensure the code was completed on time and with the necessary features. This was done by iteratively designing a new feature in accordance with the overal aim, implementing the feature and then testing it. This cycle was repeated until all the necessary features were implemented. This enforced encapsulation of a feature with a single element of code, providing separation of concerns. It also ensured that each feature was built on a stable base. On each iteration of the code, all the tests were run to ensure that no regression had occured. These tests provide a good set of debugging features which ensured that refactoring the code did not impact code quality.
+I decided to use a iterative development method, in order to maintain quality of the code, and to ensure the code was completed on time and with the necessary features. This was done by iteratively designing a new feature in accordance with the overall aim, implementing the feature and then testing it. This cycle was repeated until all the necessary features were implemented. This enforced encapsulation of a feature with a single element of code, providing separation of concerns. It also ensured that each feature was built on a stable base. On each iteration of the code, all the tests were run to ensure that no regression had occured. These tests provide a good set of debugging features which ensured that refactoring the code did not impact code quality.
\subsection{Source Control}
projects / ii-diss.git / commitdiff