We can measure this by counting the total number of Ethernet frames for a packet to go between two hosts. With a ineffficent forwarding system it will require more frames than in an efficent forwarding system.
-I will use this to compare Ethernet's system, which combines a spanning tree with bridges which learn the addresses of packets which have been forwarded, to the MOOSE system, which uses a Link State routing protocol, as well as learning the address of hosts.
+I will use this to compare Ethernet's system, where the forwarding protocol keeps a state table storing which host is off which port, which is used with the spanning trree to forward packets, to the MOOSE system, which uses a Link State routing protocol to keep track of switches, as well as learning the address of local hosts.
We need to look at two different types of addressing as well. Packets in Ethernet can either be broadcast, or unicast, so both mechanisms will be studied.
\label{fig-mesh}
\end{figure}
-MOOSE performs poorly when packets are broadcast. This is due to the selection of Reverse Path Forwarding to prevent broadcast storms. Broadcast storms are where, when packets are broadcast to the entire network, they loop around a series of links, causing ever increasing network utilisation. This in turn causes the network to become unusable until the problem is remedied by some external means.
+MOOSE performs poorly when packets are broadcast. This is due to the selection of Reverse Path Forwarding to prevent broadcast storms. Broadcast storms are scenarios in which packets that have been set as broadcast loop around a series of links, causing network saturation, reducing the effective utility of the network. In order to prevent this, some mechanism must be used to prevent this happening by culling duplicate frames.
-Reverse Path Forwarding works by detecting that a frame did not come from the most efficent route from source, and thus it is a duplicate, and thus it can be safely discarded. In MOOSE this works by looking at the source and port combination that a frame arrives at the switch with and checking that a frame sent to that switch would be sent on the same port. If it is, then the frame is flooded on all other ports, in the case of broadcast, otherwise it is dropped. This means that each frame is forwarded to one destination more than it would if a spanning tree existed, as it is only detected as a inefficent route on arrival at a switch, not before it is flooded.
+Reverse Path Forwarding works by detecting that a frame did not come from the most efficent route from source, and thus it is a duplicate, which allows it to be safely discarded. In MOOSE this works by looking at the source and port combination that a frame arrives at the switch with and checking that a frame sent to that switch would be sent on the same port. If it is, then the frame is flooded on all other ports, in the case of broadcast, otherwise it is dropped. This means that each frame is forwarded to one destination more than it would if a spanning tree existed, as it is only detected as a inefficent route on arrival at a switch, not before it is flooded.
-In a fully connected mesh network, this is causes very poor broadcast performance, as after the first switch floods the frame to all other ports, each switch which recieves it will have received it on the most efficent port and will flood the frame again. However, all of the switches to which it floods the frame will already have recieved the frame and thus it will be a duplicate.
+In a fully connected mesh network, this causes poor broadcast performance, as after the first switch floods the frame to all other ports, each switch which recieves it will have received it on the most efficent port and will flood the frame again. However, all of the switches to which it floods the frame will already have recieved the frame and thus it will be a duplicate.
As a result of this, the MOOSE protocol performs especially badly here, requiring 1156 broadcast frames to perform the simulation, 578 from each transmission. One frame is from the host to the switch, then 24 frames to each of the connected switches, followed by each of those switches sending another 24 frames, plus an additional frame from one switch to the host.
\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.
\subsection{MOOSE State Tables}
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 should not effect my results.
+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 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 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.
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.
+Unlike ns2, ns3 is in active development and is considered the natural successor to ns2, once the remaining protocols have been implemented for ns3.
\subsection{Conclusion}
projects / ii-diss.git / commitdiff