DiffServ QoS In NS-2 Simulator

Home
DiffServ Functionality
Bandwidth Broker
Links
Our Team
Downloads

Quality of Service in NS-2

Our team is studying Quality of Service issues in high speed networks. This work is done in the Lab of Distributed Systems and Telematics of Computer Engineering and Informatics Department of University of Patras.

The areas that our team has focused the past years are the development and experimental simulation of several mechanisms. After the simulation tests, many mechanisms has been configured and studied in real networks and now are fully functional mechanisms on production QoS services. The simulation tests have been done in NS-2 (Network simulator 2) that is a well known simulation environment that many researchers use around the world. This page describes our team, and focuses on the already developed functionalities in NS-2. This period, our team works on the testing of a Bandwidth Broker structure that the team designed and developed. The forthcoming results will be evaluated in order to improve the bandwidth brokers operation. Also, this implementation will be used in order to test and evaluate various algorithms for admission control and inter-domain communication (adjacent bandwidth brokers). Finally, there are plans to integrate the existing functionality with MPLS technology.

Our additions for NS-2 simulator can be summarized in the following areas:

  • DiffServ functionlity
  • Bandwidth Brokers
  • Admission control algorithms for Bandwidth Brokers

QoS developed DiffServ functionality for NS-2

Packet classification using DSCP
Packets are classified at the edge routers using the prio_field in the IPHeaderClass. So packets which have the same source and destination nodes but belong to different applications , belong to different classes as well. 

Trace based on flow id and DSCP
You are able to define (through tcl) which packets will be traced at the trace objects of the ns topology. This is achieved by defining in the tcl script the flow_id and/or the value of prio_field of the packets that you are interested in tracing. 

MDRR Algorithm
Modified Deficit Round Robin Scheduling (MDDR) Algorithm is a scheduling algorithm that has been added at the (DiffServ) routers. It is a queueing strategy and has two versions, the strict and the alternative. If you choose the strict version, the zero queue is serviced first and then all the other queues in a round robin way. The alternative services the zero queue and all the other queues in a round robin way which means queue zero, queue one, queue zero, queue two, queue zero, queue three. 

Shaping
The shaping mechanism (applied in DiffServ routers) is used in order to normalize the rate in which the packets enter into an ingress router. In fact, it does not allow the packets to enter the router in a larger rate than the one specified. The packets that are delayed, enter a buffer and when this buffer is full, excessive packets are dropped. A different shaping rate and buffer size can be defined for each class of packets. 

Background traffic
We have developed code with which you are able create realistic background traffic in your ns-2 simulation environment. You can configure the basic parameters for the traffic generation according to your needs. These parameters are the start and the stop time of the simulation, as well as the rate for the TCP and UDP sources and finally the number of the links of your topology to which you want to insert background traffic.
 

QoS developed Bandwidth broker functionality for NS-2

Bandwidth Broker models


Admission Control Algorithms


Bandwidth Broker(BB version 1.0)
Our team has developed an application which plays the role of a Bandwidth Broker(BB). The BB framework has a BB base agent and many BB edge agents. When an edge agent asks for bandwidth, and if the BB base is available, the BB base asks each one of the bandwidth path edges if they have the requested bandwidth. First asks the first edge. If the Bbbase gets a positive answer continues with the second one. If all edges are o.k., then BB base sends them a command to fix the bandwidth otherwise the request is rejected.

Central Bandwidth Broker(BB version 1.1)
This BB is a new implementation of the previous version of our BB. When the simulation starts, BB edges send an information packet about their capabilities to the BB base. BB base takes these packets and creates a database. So when a request comes , he checks immediately his database. If the database answers positive ,then the BB base sends to the edges the command to fix the bandwidth otherwise the request is rejected. We also have created a log-file like system about the situation of the requests.

Distributed Bandwidth Broker(BB version 1.1)
This BB is also a new implementation of the previous version of our BB. Here, when a request comes , BB base asks immediately all the edges for bandwidth. When the first negative answer comes ,the request is rejected and only when all the edges answered yes the request is satisfied. We create a database to control our question packets. We check if the answer packet the BB base receives is valid because BB base may receive an answer packet from a BB edge agent about a request that has been already rejected. That packet is simply ignored. 

Central Distributed Bandwidth Broker(BB version 1.1)
This BB includes all the benefits of both the central and the distributed model. The requests are processed just like the central model with the difference that it stores the database information both into his database and at the edges.

Simple admission control (SAC)
Each incoming request is examined by itself, and is accepted if there is still available bandwidth for the service.

Price-based admission control (PBAC)
The algorithm makes a decision on which requests will be accepted trying to optimize the network utilization by gathering and evaluating multiple requests together.

Adaptive admission control (AAC)
Tries to gather multiple requests and evaluate them together for purposes of increasing the resource utilization, but also uses an adaptation module in order to keep processing requirements low.

Adaptive admission control with resubmissions (AACR)
An enhanced version of the AAC algorithm, it has the capability to recognize previously rejected requests and increase their priority.
 

Useful Links & Bibliography

  • S. McCanne and S. Floyd, ns Network Simulator, available at:http://www.isi.edu/nsnam/ns/
  • http://www.ietf.org/html.charters/OLD/diffserv-charter.html
  • http://www.ietf.org/html.charters/intserv-charter.html
  • S. Vegesna, IP Quality of Service: the complete resource for understanding and deploying IP quality of service for Cisco networks, Cisco Press, 2001
  • Vivek Alwin,Advanced MPLS Design and Implementation, CISCO PRESS, ISBN 158705020X
  • RFC 2205, R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", IETF
  • RFC 2475 An Architecture for Differentiated Services, S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, December 1998
  • RFC 2597, Assured Forwarding PHB Group, J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, 1999
  • RFC 2598 An Expedited Forwarding Per Hop Behavior V. Jacobson, K. Nichols, K. Poduri, June 1999
  • RFC 2697, A single rate three color marker, J. Heinanen, R. Guerin, September 1999
  • RFC 2698,A Two Rate Three Color Marker, J. Heinanen, R. Guerin, September 1999
  • RFC 2859, A Time Sliding Window Three Color Marker (TSWTCM), W. Fang, N. Seddigh, June 2000
  • RFC 2905 AAA Authorization Application Examples, J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence, August 2000
  • RFC 3031 MultiProtocol Label Switching Architecture E. Rosen, A. Viswanathan, R. Callon, January 2001
  • RFC 3086, Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification, K. Nichols, B. Carpenter April 2001
  • RFC 3209 RSVP-TE: Extensions to RSVP for LSP Tunnels D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow December 2001
  • QBone Bandwidth Broker Architecture,http://qbone.internet2.edu/bb/bboutline2.html
  • Techniques for End-to-End Quality-of-Service control in multi-domain IP Networks,http://homes.dico.unimi.it/~pagae/NPTLab/camp.html
  •  Active Resource Management (ARM) For The Differentiated Services Environment,http://www.caip.rutgers.edu/TASSL/Projects/Adaptive_QoS/ananth/bandwidth.html
  • http://www.geant2.net
  • http://www.geant.net
  • http://www.cisco.com
  • http://www.juniper.net

Project team

  • Christos Bouras (Scientific Co-ordinator of Distributed Systems and Telematics Lab)


Ex- members of our team

  • Kostas Stamos (Computer Engineer & Informatics, Phd)
  • Afrodite Sevasti (Computer Engineer & Informatics, Phd)
  • Ioannis Pappas (Computer Engineer & Informatics)
  • Nikolaos Stathis (Computer Engineer & Informatics)
  • Dimitris Primpas (Computer Engineer & Informatics, Phd)
  • Vassilis Papapanagiwtou (Undergraduate Student)

    •  

Additional information about the members of our team are available in the People area of the website, where full CVs as well as the publications and the projects that they participate are available.
 

The source code implementing the developed functionalities has been tested at ns-2.26 and ns-2.33:

If you have an ns-2.26 installation, download this file.
If you have an ns-2.33 installation, download this file.

The zip files contain installation instructions inside README.txt. 

If you need any help please contact the project team.