TclObjectThis document gives a brief overview of how the simulator is designed. It gives the details of the object hierarchies and how the classes interact. It is inevitable that anyone who uses a simulator will more or less change it to suit ones need. To facilitate this we have provided the design document and the Programmers Manual. The reader is advised to read this document first and then the Programmers Manual
TclObjectTclObject is the highest class in the object hierarchy. All the major classes are derived from this class. These include the classes shown in the figure plus some less significant ones. This class contains a static list of all the objects created by the user. Each object is assigned a unique name and these are used to identify the object when used by the user. It also records the name of the class to which the object belongs. The advantage of using this common base class is that objects of all kinds can be stored in the same list . The function using the object knows how to treat the object and simply typecasts it for its own use. The series of command objects are declared as static. Thus you can have only one such object which is identified by its special name. For e.g. the AtCommand object is identified by the "ns-at" name which is called internally by the ns at command. These command functions are used for converting user input to different types of TclObjects. The class NsObject is not static and from it almost all the other main classes are derived.
The Scheduler class is the heart of the simulator. It contains the current time and the list of all the Network Events that are scheduled to occur. It contains a static variable instance_ which can be used by any of the classes to get access to the same scheduler ( you actually invoke the Scheduler::instance() function) . You can generate a new event only by calling the schedule function of the scheduler and that too by specifying the delay from the current time. Thus the integrity of the events is not compromised but still achieving globalization of time and the events' list. The run function is called by using the ns run command which keeps on executing events until the event list becomes empty
The Event class represents the actual events that are generated by the simulator. It contains the time of the event and the Handler object which will handle the event. By using this as the base class, Packet and AtHandler were defined. The advantage of this scheme is that whoever has to handle the event, converts the event to whatever form it wants to convert it to and then handles it accordingly.
The Handler object is used as the base class for all the classes that need to handle events. All it contains is a pure virtual function which enforces that all future inherited classes must provide this function. So if one wants to introduce a new class which needs to handle events, then it must inherit from the Handler class.
The Matcher classes are used to identify the class whose object has to be created. The user simply supplies a keyword identifying the Matcher class and the Matcher class returns a newly created object of the associated class. For example, the class DropTailMatcher is used to identify the DropTailLink class by comparing the id "drop-tail". The user can specify the type of the link as "drop-tail" in the input file and using the Matcher class can create an object of type DropTailLink.
The Matcher class is the parent class of all the Matcher classes. For every class whose object need to be created, you can create the corresponding Matcher class with a chosen id for taking user input. Every Matcher class is declared static so that only one Matcher object can be created. Just like the TclObject, Matcher also stores all the objects in a static list of all the Matcher objects.
VarThe Var classes are required for storing the default variables speified in the ns_default.tcl file. Their hierarchy is shown in the figure. Whenever an object is created the default values can be set by searching for the appropriate variable and class name. Similarly setting the values of their variables is also allowed. All the network default parameters belong to one of these classes Var classes. The Var classes also use the helper functions bw_atof and time_atof through which the user input in words is converted to their respective values. For example the bw_atrof takes in bandwidth as a string with Mb, Kb and converts it into bytes.
NsObjectNsObject is base class for all the entities in a Network. These include Nodes, Links, Agents, Trace and DataSources. Node, Link and Agents are derived from both the Handler and NsObject. The reason for this is that these 3 objects have to handle various events while the others do not have to. NsObject contains a list of Var objects which have been stored from ns_default.tcl file. So when an object inherited from the NsObject class is created the default values of its variables can be set using the appropriate function from these functions; link_real, link_bw, link_time, link_int and link_bool. This can be done in the constructor of the class. As all the Var objects are visible to all the objects, the user input can be easily translated into their respective values. Also one avoids the use fo hardcoded constructor values and can change the default values without recompiling the program. Another attribute of this class is the Trace object which if attached to an object can be used to trace its statistics. Other objects like various data sources and flow managers are also derived from NsObject.
The Node Class represent the actual physical ndoes and routers in the network. Node has a static variable cnt_ which records the total number of nodes in the current network. Multiple traffic sources can be attached to one node but they all have different ports. However, there is limit to the maximum number of ports that can be created at a node. The Agents are kept in a list called demux_. Each node has a routing table which is filled by the routing algorithm. Routing is done on the basis of the destination address. Nodes can be placed in one group for multicast routing. Nodes do not generate any packets by themselves but instead it is the agents who generate and consume packets.
Agents are the objects that actually produce and consume packets. They are the transport entities and/or processes that run on end hosts. Each agent is automatically assigned a port number unique across all agents on a given node (analogous to a tcp or udp port). The agent knows the node with which it is connected to so that it can forward its packets to it. It also contains the packet size, the type of traffic, and the destination address (both node and agent). The Agent class is the base class for all types of TCP implementations. These include the TCP agents including Reno, Newreno, sack1 and also the TCP sinks including DelACKSink, SACK1TCPSink, SACK1DelACKTcpSink. Some types of agents may have sources attached to them while others may generate their own data. For example, you can attach ``ftp'' and ``telnet'' sources to ``tcp'' agents but ``constant bit-rate'' agents generate their own data. Packets are forwarded along the shortest path route from a source to a destination, where the distance metric is simply the hop count. If the network topology changes during the simulation, routes are recomputed instantaneously -- i.e., the routing protocol is not simulated. Reverse-path forwarding trees are similarly computed for multicast routing.
LinkThe Link class represents the physical link that connects nodes and routers. A node can have multiple outgoing links (i.e. a router) or a single link (i.e. source) All links are implemented as queues where packets arrivals, departures and drops can occur. All the statistics are kept about the traffic flowing in terms of bytes and Packets are kept here. A Link is unidirectional. It also has a seperate object for tracing the queue. From the Link class different types of Links are derived. All they have to do is define their own methods of enqueuing and dequeuing the packets.
This class is used for accumulating the statistics of an object. It takes into account the length of time for which a certain entry remains in action. It is useful for finding the averages over time like the queue lengths etc.
This class simply cumputes the mean of the data entries.
This class generates uniform or exponential Random numbers which are the Random Early Detection algorithm.
In designing the ATM part of our simulator, we made it a point that we should not have to make any changes to the existing TCP traffic. This included that not a single strategy or algorithm in the TCP network should be changed. We were successful in this, by keeping the two networks completely independent of each other.
ATMNetworkThe AMTNetwork is an actual complete ATM Network. It has been derived from the Node class so that the TCP traffic can be simply routed to the Network. The Network appears to the TCP traffic as just a single node. The advantage is that we do not have to change the TCP routing logic and still perform independent routing inside the ATMNetwork. The Network knows all the ndoes and the links. The connection admission control and the routing logic is also implemented here. The user can specify his/her own routing logic and the connection Admission control algorithm. The number of nodes in the network is limited only by memory. The number of nodes simply double whenever all the nodes are used. The links are maintained as a matrix of links. When a packet comes to the network, it is broken down and handed over to the appropriate node. Later when the packet is recovered it is sent back to the network which passes it on just like any normal TCP node. There can be multiple ATM Networks declared in the total topology. This adds another dimension to modelling networks.
ATMNodeThis is the parent class for all the nodes in an ATM network. We kept it seperate from the TCP node because we wanted to keep them excluded from the TCP routing algorithm. The nodes include both ATM Switches and ATM Sources. The nodes know the network they belong to and the links that are attached to them. They also contain dummy links, which are just used to identify the external links by which these nodes are implicitly connected. The ATMNetwork is the actual entity that is connected to the TCP nodes. Similarly they have their own routing tables. The ATM AAL layer is also implemented here. The AAL layer ensures that the packets are assembled properly. Also the user is not allowed to send packets from a TCP source to an ATM node as an end node. It is either TCP to TCP or ATM to ATM.
The ATMAal layer keeps a record of the last cell record from a particular source. If two packets from the same source are segmented, their cells do not get merged with each other i.e. the sequence of there cells remains the same. So we only need to record the last cell from every ATMNode at the AAL layer. Also cells are dropped here if they are out of sequence indicating that the packet is incomplete.
ATMLinkThe ATMLink is inherited from the Link class. The main difference in this link is that the end node must be of type ATMNode and that the arrivals are synchronised. This means that if a cell arrives at the link, it must wait till the start of a slot and only then can it be transmitted. Secondly it has a fixed slot size for all the cells. It also has to record the available bandwidth for determining whether a connection should be allowed or not.
ATMSwitchesThe switch is a node which contains buffers and can discard cells based on the discard algorithm. It also keeps a record of the statistics at the switch. The buffer for the switch is not implemented as a queue. It is only a set of counters which keep a record of the current queue size and the queue limit. Two types of switches are implemented here. The Output Buffer switch and the SharedBuffer switch. The difference is that the buffer limits are different for the two types.
If a new Switch architecture has to be implemented, then all the user has to do is to inherit from this switch, perhaps aslo inherit from the buffer and you can implement your own switch by just writing your own handle funciton.
ATMDiscardThe Discard algortihm is implemented in such a way that the user has to write just one function and the algorithm is implemented. It has one function which is supplied the switch buffer the current cell and the port to which is supposed to be routed to. It can then decide whether to discard the packet or not. For the integrity of the switch, the discard algorithm can not change the buffer or the cell. Also it has to be supplied the port number because the discard algorithm does not need to know how and where to route the cell.
ATMCellThe ATMCell is derived from the Packet so it can keep a record of all the attributes of the TCP Packet. Also it can then be masked inside an Event by typecasting it. We need to specify two things in order for identifying the Packet for the cell. The sequence number inside the packet and the total number of cells in the packet. It also contains the priority of the cell needed by the discard algorithms.
ATMAgentThe ATMAgent class has been derived from the Agent class so that any type of traffic source can be created. The ATMAgent can be attached to the ATM Source. Then it can generate cells according to the traffic characteristics specified by the user. These include the Quality of Service parameters which include the Mean Cell rate, Peak Cell Rate, Burst Size, Delay variance, Cell Loss Ratio. This first asks the network whether it can support the required traffic or not. If allowed the network allocates the resources and the agent starts to send cells according to its type. The Sink associated with the agent handles the cells once they have reached the other end. The sink keeps the record of the statistics and checks how well has the network been able to satisfy the requirements of the traffic.
New agents can be very easily implemented by inheriting from this agent. Thus a researcher can concentrate on determining how to model VBR traffic and also study different Resource Allocation Schemes and Connection Admission Control Schemes to find an optimal set of parameters for it.
ATMRouteLogicThe RouteLogic class is inherited from the TclObject class. Different Routing Algorithms can be implemented here. The user only needs to make one function which will establish the route between the source and the destination. Thus different types of routing strategies can be easily studied in the network. Currently only the Minimum hop count algorithm is implemented here.
Our simulator is designed in such a way that it is very easy to model new connection admission schemes. The connection admission scheme will have access to the network elements and it can probe them to acquire the current state of the resources and then determine whether to admit the call or not.
Adding another discard algorithm is the easiest thing to do. It can be derived from any of the discard algorithm class. The check_discard function will simply look at the current buffer and the cell and the port to which has to be sent and then determine in any way whether to discard this cell or not.
ATM Switches of various companies use different in the way they handle the packets. Some are limited in their routing facilities. Others have buffers implemented in a different fashion. Some can not have certain discard algorithms implemented in them. So for all these the switch can be derived from the main switch class or if need be the buffer can be implemented in whatever the user wants it to be by inheriting from the buffer class. All this can be very easily implemented in our simulator.
Our simulator allows for an easy implementation of the Routing Algorithms. You can have a minimum delay algorithm, a need based routing algorithm (route only established when a cell actually comes), removal of routing entries after a timeout, delay in establishing a route and many other things. However these should be implemented more carefully because in the current system, the routing is done on the eventual destination. This can be converted into a connection based routing scheme but the switches also have to be derived to allow that to happen.
It is well-known that the Poisson model has failed in modelling accurately the bursty data traffic. Using this simulator it is very easy to try different schemes for generating traffic by making your own agent class and seeing that their behaviour is really what it was expected to be.
One can also study the parameters of TCP traffic and find how they can be optimised for ATM traffic. These include the packet sizes, the window sizes, timer parameters etc.