Wireless Network Simulation System
FANS Simulation of Optical Burst Switching for NSFNET
M. El Houmaidi, O. Kachirski, R. Guha
School of Computer Science
University of Central Florida, Orlando, FL 32816
Abstract :- In this paper we propose a simulation framework designed for simulating advanced network technologies. We provide a detailed architecture of the framework and describe all the necessary steps to develop simulations for any particular networking application under consideration. We demonstrate the use of this framework by simulating an optical burst switched network to aid in our quality of service studies. With the help of simulation results we show that our QoS-enhanced signaling protocol for optical networks achieves better performance and lower burst loss than existing protocols.
1. Introduction
It has been established that Internet traffic is self-similar, bursty and has a heavy tail statistical nature [4]. This traffic pattern-based observation leads to the need for a signaling protocol not only suitable for long duration flows but also improving the network throughput and the provisioning speed at the same time. Optical burst switching with its signaling protocol suite is the switching paradigm of choice combining the best of Optical Flow Switching and Optical Packet Switching for high bit-rate transfer, providing real-time support for multi-media internet traffic, and fast switch configuration for short duration sessions.
The latest signaling protocol, JET (Just Enough Time) [1] for burst switched optical networks (BSON) controls the end-to-end delay by adjusting the offset time at the source edge node based on the processing time of the control packet along the path taken by the burst. The burst is buffered at the source edge node for the duration of offset time. JET does not support any QoS scheme taking into consideration the properties of the WDM (Wavelength Division Multiplexing) layer. Furthermore, our scheme combines the contention resolution with a dynamic class-based allocation of resources such as FDLs (Fiber Delay Lines) and OWCs (Optical Wavelength Converters) [2].
This new switching paradigm is continuously evolving and all its components (signaling, burstification, routing and QoS) are being studied and enhanced by the research community. In [2], we have introduced an optical wavelength converter placement algorithm using limited range conversion. The complexity of the protocol and the numerous constraints achieving the optimal performance, dictated the need for a robust, extensible simulation framework to further study possible improvements to the Quality of Service (QoS) in BSON.
FANS framework (Framework for Advanced Network Simulation) was developed by our research group at the University of Central Florida as a research tool to provide time-saving flexible test-bed for a wide range of network technologies. The framework is cross-platform, GUI-driven and can be used as a generic advanced network simulator for a variety of purposes, such as routing in ad hoc networks, QoS schemes for burst switched optical networks, mobility models of totally mobile wireless networks, and Bluetooth Pico-nets. We currently use an implementation of FANS architecture as a test-bed for our burst switched optical network algorithms testing. In the following sections we first describe the architecture of FANS framework, then give an example of simulating QoS combining Fiber delay lines and Optical wavelength converters for burst switched optical networks using FANS.
2. FANS architecture
We have developed a customized network simulator that is general enough to target advanced networks of diverse configurations, yet is easily configurable for specific network applications. Our goals were to create a clean, easy-to-understand and extensible design using object-oriented approach, ensure general cross-platform portability, and intuitive GUI-driven simulation interface. Performance and scalability were the two most important design issues. The architecture of FANS (simulator and interface) is based on a building-block approach. Researchers implement algorithms or prototypes from modules that receive inputs in the form of events, process them, and generate outputs (events, log entries, GUI updates). The entire network is built from objects – nodes, links, event generators, and communication channels. Connections between nodes are maintained by the connection handler object. Most common types of network architectures are supported and can be configured – such as, for example, ad hoc and infrastructure wireless networks [5]. Object-oriented approach is central to the generality and flexibility of the system and allows users of our framework to reuse, share and catalog simulation components by modifying or replacing appropriate classes.
Majority of existing advanced network simulators aim at supporting every possible aspect of network communications, such as, for example, every layer of many communication protocols used. This adds tremendous overhead to the simulation system, often resulting in scalability problems and slow execution times. The FANS framework avoids these problems, by implementing only the key functionality of a network – supporting simulation clock, network communication and node behavior. These functions are implemented on an abstract level, allowing the user to include specific communication protocols, routing algorithms and other required simulation parameters, as necessary. The intuitive graphical user interface reflects any changes in the simulation execution as they happen, in real-time, allowing the user to adjust the simulation parameters at run-time. Another advantage of our framework is the ability to use almost any data file as a source of network communications. Data file pre-processor converts binary network traffic data into the format accepted by FANS simulation system, converting network addresses into plain addressing scheme used with our simulation framework. As an example, intrusion data from the Lincoln Laboratories IDS tests was used to test our wireless IDS system [6].
FANS architecture consists of four key modules, each comprised of a number of components - GUI (graphical user interface), Simulator Core Module, Network Traffic Module, Data Collection Module. Figure 1 shows the FANS architecture. Some of the modules carry optional functionality and can be included into the simulation as necessary. The functionality of each module is described further on in this section.
- Graphical User Interface Module
The graphical user interface (GUI) module shows the simulation execution in real-time. The GUI class is tied up to the simulation engine clock, and displays the required information every clock cycle. GUI class shows the simulation area with simulation objects. Certain simulation parameters can be adjusted via GUI module, such as traffic load and simulation clock delay. GUI module also provides controls for simulation execution – user can pause simulation, step through the simulation one clock cycle at a time, add and remove simulation objects. GUI module also records simulation statistics in a log window. Data logging module processes this data at the end of simulation and saves the results in CSV format, which can be later processed by a mathematical analysis software package.
- Simulator Core Module
The simulator core module is composed of the simulation engine and the simulation objects.
Simulation Engine: The heart of the FANS framework is a Simulation Engine. The simulation is tied up to a graphical user interface, allowing users to monitor simulation progress in real-time and modify simulation parameters on the fly. The simulation engine runs an internal clock, the speed cycle of which can be controlled at run-time. Programmatically implemented as a high-priority thread, the simulation engine runs in a loop continuously, driving execution of all other components of the simulation. Any events happening at a certain time must be processed by simulation objects at once, within a single simulation cycle. The simulation engine is common to all simulation models, and cannot be modified by the user.
Simulation Objects: Simulation objects execute independently and are time-synchronized via the simulation engine clock. Our FANS framework has a few pre-defined simulation objects. One object type is a network node object. Nodes are members of any network simulation, and can be either stationary or mobile. Each network node object also includes two methods used for inter-object communication – Send and Receive. Send method is invoked when a node is transmitting data (frames/bursts), and has routing information as its arguments. Send method determines the proper route, and sends the traffic along this route by invoking Receive method on each node recursively. Receive method first checks the traffic destination, then depending on the routing algorithm used, forwards the traffic to the destination or performs other traffic manipulation (such as burst delay). This allows the user to simulate various network architectures – from wireless to optical. Routing protocol is another simulation object. The routing protocol included with FANS framework is a simple table-driven protocol, which is implemented as a separate routing class. To modify the routing protocol, user must include all necessary parameters in a network node object, then add their own routing protocol class.
- Network Traffic Module
Network traffic for FANS framework is generated by the Network Traffic Processor object. The implementation of the object is common to all the simulations and includes reading a pre-processed data file in XML format, and routing network traffic to the appropriate network node. FANS uses a flat addressing scheme to reduce communication overhead, and therefore all network addresses are converted to compatible notation by the BIN/XML Parser module before running the simulation. Traffic processor object generates network traffic at certain timestamps, and makes use of simulation engine’s internal clock to time distribution of events. This allows us to speed up simulation execution, limiting the simulation speed only by the hardware specifications and the maximum incoming event rate.
- Data Logging Module
Data logger class saves the simulation results for future analysis. During simulation execution, results are stored in memory and displayed in a readable form via GUI data display window for performance reasons (frequent disk I/O operations reflects negatively on simulation performance). The representation of results can be tailored to particulate simulation requirements and is defined in the GUI class.
Data parser: At the end of the simulation run, these results are first pre-processed by a data parser to format data suitable for import into the mathematical analysis software.
CSV file generator: The pre-processed output is saved as a CSV file (a widely-used comma-separated data file format) by the CSV file generator.
Simulation process
The simulation procedure is as follows. First, a simulation diagram is devised by the user, which includes the list of all objects taking part in the simulation and interaction mechanisms between the objects. Statistics output formats, as well as simulation stop conditions should also be specified at this point. Next, the implementation is written for all of the above objects, following the guidelines included with the simulation framework. Data parsers should also be adapted to reflect the new data structures. The objects are then placed in the simulator core directory and compiled. The GUI is then started, which then instantiates all simulation objects and displays them on-screen (for those objects that have visual behavior defined). Objects then can be manipulated via graphical interface during simulation runtime. Events are passed to appropriate objects via messages and processed. All collected statistics are displayed in a log window, which is then saved into a file. The results of the simulation can be pre-processed for further analysis or graph plotting by the Data Parser module. The supplied data parser converts log file into a CSV format, which then can be imported into a variety of statistical programs.
3. FANS for burst switched optical networks design
Our first use of FANS architecture was to develop a test-bed for a wireless intrusion detection system (IDS) simulation prototype [5, 6]. In this paper, FANS architecture is applied to burst switched optical networks (BSON). This section covers the architecture of our simulation, step-by-step design process, implementation of several BSON-related algorithms, and simulation runs.
Our FANS simulation is based on a discrete-event model with a time-advance mechanism to the most imminent event to be processed. Each event processing affects the state of the system and the time of occurrence of future events. Our simulation models seven different events: an arrival of a control packet for path establishment in the network, a departure of a reserve control packet from a particular node to the next hop node, the event of blocked burst due to lack of resources, the event of arrival of the burst at the destination node, the release of resources by a control packet, the event of burst ready after FDL delay, and the event of ending the simulation after C bursts are processed (simulation stop condition). C is 106 times the considered load of traffic in the network. The load, in Erlangs, is the product of the arrival rate and the average burst length. The simulation takes into consideration the control packet processing time, P, at each node. P is assumed to be 10 µs. The propagation delay is estimated based on the kilometric distance between nodes and the speed of light. Three alternate hop-based shortest paths between node-pairs are computed in advance. If the burst is dropped when routed along the first path, the second, then third alternate paths are tried.
We consider the NSFNET topology (figure 2) which is used extensively in optical networks simulations. We show the benefits of QEJET supporting 4 classes of traffic. Each fiber link has W wavelengths. The burst length is exponentially distributed with an average of L μs and the normalized load intensity is ρ.
We assume that FDLs and OWCs are available at selected core nodes of the OBS network. OWCs are used for high priority bursts where end-to-end delay needs to be kept to a minimum. FDLs are used to delay a burst at a core node to resolve contention for higher priority bursts. High priority bursts take advantage of wavelength conversion to incur minimal end-to-end delay and lower priority bust will be delayed using a variable-delay FDL bank (each output fiber has a dedicated FDL). As in [3], we adopt the variable-delay FDL design but our design is different than [3] in term of usage of wavelength converters to allow the maximum possible of bursts to be delayed at the same time. Each fiber delay element (represented by a circle) can provide a delay of b time units. A delay line can provide a variable delay ranging from zero to MAXD = (20 + 21 + … +2(max_d)) x b units of time.
Our QoS enhanced JET scheme is based on the Horizon scheduling [1]. The algorithm has an advantage in hardware implementation. Each class of traffic has a priority that drives the allocation of FDLs and OWCs. Higher priority bursts require minimal end-to-end delay and will use OWCs as much as possible (pre-emption is possible of lower priority bursts). Low priority bursts will incur delays in FDLs.