Bugzilla – Bug 2216
Create SwitchHelper object to make L2 networks easier to set up
Last modified: 2015-11-13 13:18:05 EST
Created attachment 2183 [details] Switch Helper header file It is relatively easy to add the internet protocol stack to a node or list of nodes in ns3: InternetStackHelper ns3IpStack; NodeContainer endpointNodes (t2, t3, b2, b3); ns3IpStack.Install (endpointNodes); The same is not true when using a Bridge because the BridgeHelper device requires the user to keep track of the NetDevices on the bridge and pass a NetDeviceContainer to the Install method. This makes it less convenient to set up and use Bridges in a simulation script. Also, the commonly used name for a bridge with multiple ports is a Switch. Users may be confused if they are trying to create a model of a switched network when they don't see something called "switch." The two files attached here implement a subclass of BridgeHelper called SwitchHelper. It inherits everything from BridgeHelper and just adds a more convenient method for installing L2 bridging code on a node. The aim is to make it easier to set up switched networks, and to also make it appear as though there is a Switch device (by virtue of the object's name). With the SwitchHelper, it is easy to add L2 bridging code to a list of nodes, and is exactly analogous to how users already add the internet protocol stack to a list of nodes: SwitchHelper Switch; NodeContainer Switches(s1,s2,s3,s4); Switch.Install (Switches); It is proposed to add these files to src/bridge/helper and update src/bridge/wscript appropriately. I am not sure that I have completely followed the style guidelines, but hope this is a good start.
Created attachment 2184 [details] Switch Helper implementation
Regarding style, it looks good in general; one comment is to avoid use of NS_LOG_FUNCTION_NOARGS() except for static methods; if the this pointer exists for the object, NS_LOG_FUNCTION () is preferred, and show the arguments; e.g. NetDeviceContainer SwitchHelper::Install (Ptr<Node> node) { NS_LOG_FUNCTION_NOARGS (); becomes NetDeviceContainer SwitchHelper::Install (Ptr<Node> node) { NS_LOG_FUNCTION (this << node); or perhaps NetDeviceContainer SwitchHelper::Install (Ptr<Node> node) { NS_LOG_FUNCTION (this << " Node ID: " << node->GetId ());
regarding the header and implementation: * This method makes it easier to set up an Ethernet Switch. It does 3 things: * (1) creates an ns3::BridgeNetDevice with the attributes * configured by BridgeHelper::SetDeviceAttribute, * (2) adds the device to the node, and * (3) attaches the node's NetDevices as ports of the bridge. the code is not doing this; it is just iterating the provided nodes and adding all NetDevices it finds to the bridge. It doesn't provide an API for attribute configuration. It doesn't actually add devices to the node. Presumably the nodes provided by the user would be nodes that were ready for conversion into a switch, but the code is not checking that the devices that it finds are all suitable for bridging (i.e. some error checking could be done). Wouldn't it be easier for users to specify a collection of nodes that he or she wants to be connected via a switch, and had an API such that the user could provide the node collection such as: n1 n2 n3 n4 and the switch helper would connect them all by creating a new node; e.g. NodeContainer nc; nc.Create (4); SwitchHelper switch (nc); NodeContainer switchNode = switch.Install (); yielding (with CSMA links): n1 n2 \ / \ / \ / n5 / \ / \ n3 n4 A working example program would help here. I would also avoid calling it an Ethernet switch, since we do not have an Ethernet model (yet). Is it intended to be used with a future (contributed) Ethernet module?
Thanks for the feedback. I will clarify and add an example.