As already discussed, [27] explains how the redhat linux kernel can be patched to add DiffServ over MPLS functionality and RSVP daemon to the linux ker-nel. It also explains how we can set LSP (Label Switch Path) along some explicit route over the DiffServ over MPLS network. Previous section ex-plains the set-up of DiffServ based service classes that are used for service differentiation and creation of network classes. Once we have understood these concepts, we can now create a network set-up that provides QoS guar-antees to different application classes and thus, to different applications.
We implemented QMPLS on a test-bed using 3 DiffServ over MPLS Linux routers as shown in Fig 5.1 and separate client and server that request and sends flow traffic. The user specifies the QoS requirements on the application
(a mail-application or a video streaming application) which are used by the admission control server to calculate the resources that might be needed to meet those requirements. The resources here include the path and the Diffserv class that would meet the requirements. In case, the requirements cannot be met, the request is refused admission. D-ITG [25] is used for end-to-end QoS measurement. To test the efficiency of the above proposed admission algorithm and architecture and justify, that proposed traffic classes at the network level which have one to one correspondence with the application classes in our case improve the QoS for application flows for DiffServ over MPLS network, following tests are performed.
5.4.1 Test-Case 1
These tests were intended to study the justification of having 2 proposed different QoS classes viz PCBR and PVBR for 2 different UDP flows (CBR and VBR) on a DiffServ over MPLS network. Following tests were performed:
Test 1
In test 1, 2 flows are transfered into the network. Flow 1 carries EF flow at the rate 100pkts/sec with each packet size equal to 256bytes. Flow 2 carries a poisson distributed traffic with the average rate of 16000 pkts/sec with uniformly distributed packet size between 40 B and 512B. Flow 1 simulates a CBR flow. Flow 2 represents VBR flows. Flow1 is sent for 120 secs. Flow 2 is sent after a delay of 30 sec and for a duration of 30 secs and the QoS for flow 1 (CBR) is observed.
• In the first case, the flows are transfered without any QoS policy. We
observe following QoS for flow 1:
Total time = 59.946979 s Total packets = 5995
Minimum delay = 0.000035 s Maximum delay = 0.062872 s Average delay = 0.000299 s Average jitter = 0.000189 s
Delay standard deviation = 0.002888 s Bytes received = 1534720
Average bitrate = 204.810321 Kbit/s Average packet rate = 100.005039 pkt/s Packets dropped = 5 (0.08 %)
• In the second case, the flows are transfered with DiffServ only imple-mented at the routers. Following QoS is observed for CBR flow:
Total time = 59.998300 s Total packets = 5996
Minimum delay = 0.000044 s Maximum delay = 0.099365 s Average delay = 0.003467 s Average jitter = 0.001460 s
Delay standard deviation = 0.014096 s
Bytes received = 1534976
Average bitrate = 204.669266 Kbit/s Average packet rate = 99.936165 pkt/s Packets dropped = 4 (0.07 %)
• In the 3rd case, the flows are transfered with both DiffServ over MPLS working in effect. Following QoS is observed for CBR flow:
Total time = 59.950599 s Total packets = 6000
Minimum delay = 0.000093 s Maximum delay = 0.145902 s Average delay = 0.003542 s Average jitter = 0.001430 s
Delay standard deviation = 0.014492 s Bytes received = 1536000
Average bitrate = 204.968761 Kbit/s Average packet rate = 100.082403 pkt/s Packets dropped = 0 (0.00 %)
From the above, we observe that the IP and DiffServ flow experience packetloss and bitrate when the additional VBR flow is sent to network for 30 sec. The DiffServ over MPLS (DS-MPLS) continue to retain its QoS performance parameters.
Our experiments have shown that it is difficult to obtain correct delay of the order of milli-second due to inaccuracy in the linux clock which used NTP to adjust times.
The graphs of the CBR flow obtained are shown.
Test 2
In this test, additional TCP flow of 1000pkts/sec with a packet size of 512 bytes was sent along with the above flows after a delay of 30 sec for 30 sec.
We make following observations for CBR flow:
1. For IP network, the QoS observed for CBR flow is:
Total time = 59.995827 s Total packets = 5762
Minimum delay = 0.000046 s Maximum delay = 2.606972 s Average delay = 0.106489 s Average jitter = 0.002387 s
Delay standard deviation = 0.413903 s Bytes received = 1475072
Average bitrate = 196.689946 Kbit/s Average packet rate = 96.040013 pkt/s Packets dropped = 238 (3.97 %)
2. For DS network, QoS for CBR flow is:
Total time = 59.991223 s Total packets = 5554
Minimum delay = 0.000045 s Maximum delay = 5.556188 s Average delay = 0.130001 s Average jitter = 0.002857 s
Delay standard deviation = 0.761692 s Bytes received = 1421824
Average bitrate = 189.604269 Kbit/s Average packet rate = 92.580210 pkt/s Packets dropped = 446 (7.43 %)
3. For DiffServ over MPLS network.
Total time = 59.935665 s Total packets = 6000
Minimum delay = 0.000096 s Maximum delay = 0.554820 s Average delay = 0.005500 s Average jitter = 0.000636 s
Delay standard deviation = 0.042086 s Bytes received = 1536000
Average bitrate = 205.019833 Kbit/s
Average packet rate = 100.107340 pkt/s Packets dropped = 0 (0.00 %)
From the above test, we again observe that the CBR flow for DiffServ over MPLS remains unaffected and results in no packetloss and better bitrate when additional flows are sent. CBR flow experience loss in case of both IP and DiffServ network. Delay in IP network is less dues to lesser processing at the routers and absence of queues.
Above results clearly show that the QoS received by each flow has im-proved when we separately do explicit routing for the 2 DiffServ classes (EF and AF). This means that we get improved QoS when we have 2 different application classes PCBR and PVBR for UDP flows mapped to different MPLS LSPs with the different DiffServ classes (EF and AF1x respectively).
From the above tests following conclusions are drawn and verified:
5.4.2 Test-Case 2
Here, we studied the proposition of having 2 different application classes for TCP flows viz one for greedy TCP flows (knows as Premium Multime-dia(PMM) by Aquila research) and other for short lived TCP flows (known as Premium Mission Control (PMC)) like DNS, database queries on Diffserv over MPLS network.
Following tests was performed: 2 TCP flows were sent. One at a rate of 12000pkts/sec and other at 1000pkts. We observe average bitrate of 47793.386223 (12,000pkts/sec) and 578.838888 Kbit/s (1000pkts/sec) on IP
network, 49790.996537 Kbit/s and 624.025128 Kbit/s on DiffServ(DS) net-work and 50845.120436 Kbit/s and 640.054895 Kbit/s on DiffServ over MPLS network. Thus, we find that the flows receive better throughput in case of DiffServ over MPLS (DS-MPLS) than DS and IP network and it also shows that a DS-MPLS class.
5.4.3 Test-Case 3
In this subsection, the effect of separation of UDP and TCP classes is studied.
For this following tests were performed:
In this test, 4 flows each corresponding to each application class is sent.
First flow is UDP and is sent at the rate of 1000 pkts/sec with the uniform packet size of 256B. Second flow again is a poisson distributed UDP flow sent at the average rate of 1000pkts/sec with the size changing uniformly between 40B and 512B. Third flow is a TCP flow sent at the rate of 5000pkts/sec with the packet size being equal to 512B. Fourth is a TCP flow sent at the rate of 100pkts/sec and has a packet size equal to 80B. Each flow above corresponds to each application class. Flow 1 corresponds to CBR, flow 2 to VBR, flow 3 to PMM and flow 4 to PMC.
We observe that the packetloss in case of DiffServ over MPLS for flow 1 is 15.41%, for DiffServ packet loss is 15.55% and for IP it is 15.77%. For flow 2, loss over DS-MPLS is 15.64%, over DS 15.67 % and over IP is 15.99%. For flow 3, bitrate over DS-MPLS is 20478.944310Kbit/sec, over DS is 20480.075606 Kbit/s and over IP is 20480.060075 Kbit/s. Bitrate over DS-MPLS for flow 4 is 64.004470 Kbit/s, over DS is 64.000710 Kbit/s and over IP is 64.002353 Kbit/s.
0 0.5 1 1.5 2 2.5 3
0 10 20 30 40 50 60
Numbers of Packets lost
Time
Packetloss over DS-MPLS Packetloss over DS Packet loss over IP
Figure 5.2: Packetloss of flow 1 in test-case 1
When we increase the rate of VBR flow from 1000pkts/sec to 4000pkts/sec, we observe that the bitrate of flow 3 for DS becomes 19949.464630 Kbit/s, for IP becomes 16757.225827 Kbit/s, for DS-MPLS it is 20480.062464 Kbit/s.
Bitrate for flow 4 for IP is 63.999306 Kbit/s, for DS is 64.003400 Kbit/s, for DS-MPLS is 64.004384 Kbit/s. Packet loss for flow 1 over DS-MPLS is 24.85
%, over DS is 27.00 % and over IP is 26.52 %. Thus, we clearly observe that DS-MPLS shows lesser degradation in QoS than DS and IP for all the classes when the traffic rate of VBR (class 2) flow is increased.
185
Figure 5.3: Bitrate for flow 1 in test-case1
0
Figure 5.4: Delay for flow 1 in test-case1
0
Figure 5.5: Jitter for flow 1 in test-case1
0
Figure 5.6: Packetloss of flow 1 in test-case2
0
Figure 5.7: Bitrate of flow 1 in test-case2
0
Bitrate over IP for flow1 Bitrate over DS for flow1 Bitrate over DS-MPLS for flow1
Figure 5.8: Bitrate of flow 1 in test-case3
0 10000 20000 30000 40000 50000 60000 70000 80000 90000 100000
0 20 40 60 80 100 120 140
Bitrate (Kbit/sec)
Time (s)
Bitrate over IP for flow1 Bitrate over DS for flow1 Bitrate over DS-MPLS for flow1
Figure 5.9: Bitrate of flow 2 in test-case3
Chapter 6
Conclusion and Future Work
At the core of the above problem lies the effect of explicit routing on differ-ent QoS parameter. We have proposed an architecture that does this. We have proposed 2 admission control algorithms one without preemption and one with preemption. During our work and research, it has become evident that no mapping mechanism to translate application QoS needs of the net-work to the underlying netnet-work configurations for the MPLS netnet-works.We have dealt with the research problem of meeting SLAs on per application basis wherein the customer choses a particular SLA out of few offered by the service provider. Service Level Agreement (SLA) is a formal negotiated agreement between a service provider and a customer. When a customer orders a service from a service provider, an SLA is negotiated and then a contract is made. In the SLA contract, QoS parameters that specify the quality level of service that the service provider will guarantee are included.
The service provider must perform SLA monitoring to verify whether the offered service is meeting the QoS parameters specified in the SLA.In order
to do so, the service provider is able to systematically map such network performance metrics and data to application level QoS parameters.
As a future work, different MPLS TE (traffic engineering) techniques for effective QoS for different proposed QoS classes can be studied. As an example, currently in our architecture, explicit path for CBR flow is found by not considering other classes in the network. Effect of other classes on finding the path such that the QoS performance of CBR flow is not disturbed can be an interesting problem.
References
[1] Paul Ferguson, Geoff Hustion. Quality of Service. John Wiley and Sons, Inc. 1998. ISBN:0471243582
[2] Dinesh Verma. Supporting Service Level Agreements on IP Networks.
Macmillan Technical. 1998
[3] Hyo-Jin Lee, Myung-Sup Kim and James W. Hong. Mapping between QoS Parameters and Network Performance Metrics for SLA monitoring.
Distributed Processing and Network Management. Dept. of Computer Science and Engineering POSTECH, Pohang, Korea
[4] D.Davide Lamanna, James Skene and Wolfgang Emmerich. SLAng: A Language for Defining Service Level Agreement.Department of Com-puter Science University College London Gower Street, London.
[5] Currecoechea, A. T. Campbell, and L. Hauw. A Survey of QoS Architec-tures.ACM/Springer Verlag Multimedia Systems Journal, Special Issue on QoS Architecture, 6(3):138.151. May 1998.
[6] Frank Siqueiral. Quartz: A QoS Architecture for Open Systems. Ph.
D. Thesis, Department of Computer Science, Trinity College,
Uni-versity of Dublin.http://www.inf.ufsc.br/ frank/papers/PhD-Thesis.pdf.
December, 1999.
[7] Silvia Giordano, LCA – EPFL Stefano Salsano, DIE – University of Rome, Tor Vergata Steven Van den Berghe, IMEC Giorgio Ventre, Uni-versity of Naples Federico II Dimitrios Giannakopoulos, National Tech-nical University of Athens. Advanced QoS Provisioning in IP Networks : The European Premium IP Projects. IEEE Communication Magazine.
January 2003
[8] European IST Project.Adaptive Resource Control for QoS Using an IP-based Layered Architecture (AQUILA). World Wide Web. http://www-st.inf.tu-dresden.de/aquila/
[9] Andrew T. Campbell.A Quality of Service Architecture.Ph. d. Thesis.
Computing Department, Lancaster University.1996
[10] Jingwen Jin, Klara Nahrstedt. Specification Languages for Distributed Multimedia Applications: A Survey and Taxonomy. IEEE MUL-TIMEDIA MAGAZINE. http://cairo.cs.uiuc.edu/publications/paper-files/ieeeimultimediajin.pdf
[11] Zheng Wang. Architecture and Mechanisms for Quality of Ser-vice.Morgan Kauffman
[12] RBraden, D. Clark, S. Shenker. Integrated Services in the In-ternet Architecture: an Overview, RFC1633. World Wide Web.
http://www.ietf.org/
[13] R. Braden, L.Zhang et. al.Resource Reservation P4 02/21/Protocol (RSVP), RFC 2205.World Wide Web.http://www.ietf.org/
[14] R J. Wroclawski. The Use of RSVP with IETF Integrated Services, RFC 2210. World Wide Web.http://www.ietf.org/
[15] R J. Wroclawski. Specification of the Controlled-Load Network Element Service, RFC2211. World Wide Web. http://www.ietf.org/
[16] S. Shenker, C. Patridge, R. Guerin.Specification of Guaranteed Quality of Service, RFC2212. World Wide Web. http://www.ietf.org/
[17] E. Rosen, et al. Multiprotocol Label Switching Architecture. IETF RFC3031 January 2001.
[18] D.Awduche, et al. Requirements for Traffic Engineering Over MPLS.
IETF RFC2702. September 1999.
[19] Le Faucheur, F., et. al., Requirements for support of Diff-Serv-aware MPLS Traffic Engineering, work in progress. http://www.ietf.org/
[20] ITU-T Recommendation Y.1541. Network Performance Objectives for IP-Based Services. May, 2002.
[21] N. Blefari-Melazzi, M. Femminella. Stateful vs. Stateless Admission Control: which can be the gap in utilization efficiency? GLOBECOM 2002 - IEEE Global Telecommunications Conference, vol. 21, no. 1, November 2002, pp. 2560 2564.
[22] Jianming Qiu Huai-Rong Shao Wenwu Zhu Ya-Qin Zhang. An End-to-End Probing-Based Admis-sion Control Scheme for Multimedia Applications.
http://csdl.computer.org/comp/proceedings/icme/2001/1198/00/11980170abs.htm.
[23] Aquila application specification language. http://www-st.inf.tu-dresden.de/aquila/files/application-profiles.htm
[24] Network Simulator. http://www.isi.edu/nsnam/ns/.
[25] http://www.grid.unina.it/software/ITG/
[26] Minimum Interference Routing of Bandwidth Guaranteed Tunnels with MPLS Traffic Engineering Applications Koushik Kar, Murali Kodi-alam, Member, IEEE, and T. V. Lakshman, Senior Member, IEEE.
http://www.ecse.rpi.edu/homepages/koushik/mypapers/jsac00.pdf.
[27] ds-mpls linux daemon and patch download from tequilla RSVP site.
http://dsmpls.atlantis.rug.ac.be
[28] ”Specification of traffic handling for the first trial” Aquila Deliverables.