Software Architecture of NetSimQ

Software Architecture

The above gives the software architecture of, and the classes defined in, NetSimQ. 1. The simulation layer: defines the primitive classes in the event-driven simulation, i.e., the event class (Event), the event queue class (EventQueue), the event handler class (EventHandler), the event monitor class (EventMonitor), and the simulation engine class (SimEngine). A common strategy to implement simulation engines is to globally define the event types and use a ``switch'' statement in the simulation engine to dispatch all the events to their appropriate event handlers. Although

conceptually straightforward, this implementation strategy makes future extension for new events difficult. Each time a new event is added, perhaps as the result of incorporating a new network architecture (i.e., a change in the specific network architecture layer), the switch statement in the simulation engine has to be modified accordingly. The consequence is that a change in a higher layer may trigger changes in a lower layer, which violates the design principle of object-oriented programming. To facilitate future extension, we adopt a totally different implementation strategy and separate event execution from event handling. Specifically, we put the event handler in the event class, i.e., each event now carries its own event handler. When the simulation engine takes an event, it does not have to tell the event type (and hence the corresponding event handler to invoke), but simply invokes the event handler carried by the event. That is, we delegate the responsibility of assigning appropriate event handlers to events to the specific network architecture layer. To facilitate debugging and step-by-step demonstration of instantaneous network changes, we also include in the simulation layer the {\sf EventMonitor} class that provides a facility to monitor events currently handled by the simulation engine or an event handler. 2. The generic network component layer: contains primitive classes that constitute a generic network: a network (Network class) consists of nodes (Node class) and links (Link class). (The Link class defined here may connect more than one node to support, for example, the broadcast feature in Ethernet.) A node sends packets (Packet class) to another node through one of its output links. When a packet arrives at a node, it is either relayed to the next node (the information of which is extracted from the routing table (PathID class)), or processed by some protocol (Protocol class). All of the Node, Link and Protocol classes are event handlers and inherit from the EventHandler class in the simulation layer. 3. The specific network architecture layer: defines classes specific to a network architecture, e.g., the characteristics of a network and operations that are invoked in response to call setup/teardown. The current version of NetSimQ specifies a point-to-point packet switched network in which (i) each link is uni-directional and connects two nodes; (ii) communication is session-based and follows the proposed QoS framework.

Specifically, this layer subclasses the Network class and the Node class from the corresponding classes in the generic network component layer, with the addition of several session operations, such as session creation, session setup, and session termination. Moreover, it also defines the Session class and the superclasses for the traffic description (Traffic class), the unicast/multicast routing algorithms (Routing class), the resource management protocol (RsrMgt class), the admission control facility (Admission class), and the message scheduling algorithm (Link class, which inherits from the Link class in the generic network component layer), respectively. The superclasses are defined here to keep generic attributes of a set of similar objects. Specific objects (that implement specific algorithms/protocols) can be extended from superclasses with their own specific methods. The superclasses (and, in particular, the programming interfaces of those superclasses) have been carefully defined to encompass a wide spectrum of algorithms/protocols in the algorithm layer. Demonstrations and user interfaces that are related to the network architecture are also defined in the specific network architecture layer. The user interfaces allow users to configure the network of interest in terms of network topology, sessions and their traffic/QoS characteristics, and algorithms/protocols used in the various components of the QoS framework. In particular, we define two superclasses NetUIPage and NetDisplay. Each NetUIPage is in charge of one network attribute, e.g., network topology, network configuration, session configuration, and simulation run. Only one page can be active at a time. NetDisplay displays the network topology: it takes mouse events (click and move) from the user and passes them to the activeNetUIPage which in turn performs appropriate actions in response to the mouse events. SimulationBroker acts as a bridge between user interface objects and the other simulation objects. The NetworkStat and SessionStat classes calculate and keep the global network and per-session performance statistics, respectively, while the LinkDemo class facilitates display of the packet schedule at a link and/or the buffer usage at a node. Also defined in the specific network architecture layer is the ``stimuli'' to the simulation, i.e., the session generation engine (SessionGenerator class) which generates sessions according to the user-specified probability distributions, and the session generation handler (SessionGenerateHandler class) which interacts with the simulation engine to continuously generate relevant events.

4. The algorithm layer: defines the algorithms and protocols used in the various components of the QoS framework. All the models/algorithms/protocols currently supported in NetSimQ are listed here. With all the algorithms/protocols implemented in classes and with the modular, composable design of NetSimQ, various algorithms/protocols can be figured in in a plug-and-play fashion and evaluated in a unified framework.