The above figure represents the topology that will be implemented in this project.

The system would include three types of components:

1. Routing Nodes: These will be running the QoSPF module and calculating the routes to each host

2. Hosts: These will be used to demonstrate the difference in Quality of Service experienced by the packets with different priorities

3. Traffic injectors: These will inject static traffic into the network to help test the network in congested scenario.

​

The requirement to implement QoS based routing in our system is, every network device and end host should support QoS. In order to do that we will introduce the following components in the system.

​

​

​

​

 

​

​

​

​

​

​

​

 

 

 

​

​

​

​

​

​

​

The working of the system is explained in the figure below:

 

 

 

 

 

 

 

 

 

 

 

 

​

 

 

 

​

 

 

 

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

1. QOSPF -Congestion Reporter Module : This module is responsible for calculating the link utilization of interfaces of the router. This information provides a real-time estimate of the cost associated with each link.  In order to  find the link utilization, the module monitors the /proc/net/dev file. By periodically reading the transferred bytes of each interface, the module calculates the transmission rate of the outgoing packets at each interface. Based on the outgoing rate and the link capacity, a cost is associated with each link. This cost is then advertised to locally running LSA handler module. Since triggering an LSA every time for minor variations will congest the network, a moving average of available bandwidth is calculated over certain time i.e the bandwidth utilization is smoothened by computing the mean of several successive values, and using that mean value in the triggering policy. Thresholds are defined for the cost value to determine which window it belongs to. Whenever the cost crosses particular threshold points i.e. it changes windows, a new LSA is triggered. This makes sure the congestion persists for a while before new LSAs are rolled out.

​

  2. LSA Handler: It has the following responsibilities:

•   It shares information obtained from the congestion reporter module to the other routing nodes in the network. It constructs an LSA defining the cost and the link and forwards it to each of the adjacent node.

• It receives LSAs from the adjoining nodes and forwards them on all the links except the one it received on. In order to prevent looping packets, a sequence number is associated with each LSA. LSA receiver maintains a list of last received sequence number from each node and only accepts and forwards packets which have previously not been received.

• It extracts the information from each LSA about the new cost on a link and forwards it to the Forwarding Table Creator module to update the routing table entries based on new shortest paths, if any.

​

 3. QoS Forwarding Table Creator:  The forwarding table module creates the routing table entries for each QoS. This module fetches the initial

        topology from a file which describes the links between the nodes and their ip addresses. It runs the Dijkstra’s algorithm once to calculate shortest

       paths to each node and creates the static routes for the low priority QoS packets.

       Based on the information received from the neighbouring routers and the local congestion reporter, it updates the costs associated with the links on

       receiving new LSAs and runs the Dijkstra’s algorithm to calculate the new routes. These routes are used to populate the routing table for high

       priority QoS packets. This will help route higher priority packets through better paths. In this way, high priority data packets are always routed

       through least cost paths; the cost being updated dynamically for each link based on their utilization.

​

​

 4. IP-QoS lookup and forwarding: The IP QoS forwarding module is responsible for forwarding the data packets according to the routes given by the 

      QoS Forwarding Table Creator module. Essentially, it involves making the Linux IP stack aware of tQoS routing tables created by the QoSPF and

      enforcing it to forward packets accordingly. This requires configuration using Linux network utility : iptables. It involves the following:

​

                I. DSCP Marker: This will set the DSCP bits in the IP header of every outgoing packet depending on the destination port of the packet. It will

                   be required to demonstrate the paths taken by packets with two different QoS requirements.

                   The Linux utility iptables includes a DSCP target, which is able to set a DSCP value in the IP header. For example, to set a DSCP value to

                    HTTP packets, the following rule needs to be written in the iptable of the end host(s):

                                     iptables -t mangle -A FORWARD -p tcp --dport 80 -j DSCP --set-dscp 1

​

                 II. Configuration of the forwarding stack: By default the IP forwarding stack does not take into consideration the DSCP bit in the IP header. It

                     performs lookups on the default routing table(main) for all the packets, irrespective of the values in the DSCP field of the IP header. The

                     IP-QoS lookup and forwarding module will install the rules for the forwarding stack so that forwarding is done based on the destination 

                     address as well as the DSCP field value of the incoming packet. The incoming data packet will be inspected to read the DSCP bits to

                     identify the routing table it needs to perform the lookup operation on and routed accordingly. For the purpose of the project, there are two

                     routing tables: main(default) for the low priority packets and another routing table (named QoSRT) for the high priority packets. With the

                     rules installed, the Linux Forwarding stack will route the packets according to the class of the packet.

​

 5. Other Applications:

 

I. Packet Generator: The packet injectors will be running packet generator software to introduce heavy traffic in the network with an aim to cause congestion in the network. Nping, iperf and any of the other freely available packet generating softwares can be used for the purpose of the project.

 

II.  Applications: The hosts will be running applications that will introduce data traffic in the network. One of the hosts will be running an ftp server and the other will be running an ftp client. The time required to transfer a heavy file with different QoS will be assessed to measure the effectiveness of the protocol.

​