Professional Documents
Culture Documents
Abstract
RSVP and Diffserv have been proposed as mechanisms for implementing Service Quality in IP based
networks, which inherently provide a best effort only service. However RSVP has problems scaling, and its
implementation on nodes that transport a large number of traffic streams is impractical. Alternatively,
Diffserv provides a granular service, which cannot provide fully optimised network performance. This paper
considers the view that future networks will consist of combinations of these mechanisms: RSVP may be
more efficiently employed in the access network, whereas Diffserv will be deployed in the higher density
backbone. The work presented examines where and when the best partitioning of protocols should be, in
order to provide accurate compliance with user specified Quality of Service (QoS) parameters throughout the
network. Efficient partitioning would allow the network to carry higher traffic loads with a wider range of
traffic profiles.
Introduction
In real life situations computer networks consist of sections of dissimilar networks connected together by IP.
By joining networks together with IP we allow any device to communicate with other devices across any
medium or transport network. This provides great flexibility with regards to interconnection but makes it very
difficult to predict how efficiently or reliably traffic can be transported across the network. If all traffic were
similar, this would not be a problem, as additional bandwidth could be allocated to compensate for delays.
The problem lies in the fact that networks are used to carry dissimilar data between endpoints, and have
different network resource requirements. This provides the basis for work in QoS provision of mixed media
networks.
By allowing traffic with particular parameters a higher priority within the network a level of QoS can be
provided. The decision on which traffic receives higher priority can be provided in two ways. In the first
method the network administrator provides the network with a set of rules governing how traffic is to be
profiled and forwarded (this is the Diffserv approach [1]). The second method allows the user to negotiate the
QoS provision of the network for its particular traffic (This is the RSVP approach [2], [3]).
RSVP allows the user application to reserve network resources along the path of the traffic such that a level of
QoS is attained. The QoS parameters can be re-negotiated by the user on a per flow basis and thus provide a
fine-grained control of network resources. In providing this fine grained control over resources there is a
penalty: scalability is not feasible within this system, as soft state knowledge needs to be held on every traffic
flow for routers operating RSVP [4], [5]. This can be alleviated by the use of aggregated RSVP [6], where
edge routers classify packets into queues for transmission over the aggregated region of the network (i.e. per
class QoS).
The centrally administered differentiated services model provides a simple efficient QoS mechanism (per
class) that can be used by either end user or service provider, but does not allow for fine grained control of
QoS or user re-negotiation of QoS. The advantage of Diffserv is that it does not require signalling and is a
simple system that can operate efficiently in high capacity links.
Experimental Approach
This work looks at the RSVP, Diffserv and Best effort models of QoS provision and compares them in
differing scenarios. These scenarios represent the access, campus and backbone sections of a network in
various states of load. The implementation of these scenarios will be within OPNET 6.0 [7] and are
summarised in the Model Description section.
In order to identify information regarding to the QoS partitioning of a network there are two general methods
to consider:
Approach A
The individual links of a network are considered separately, and these are analysed in terms of QoS
performance with RSVP, Diffserv and best effort models. Scenarios represent typical traffic on
particular links.
Approach B
The network is considered as a single entity with scenarios representing different topologies and
traffic profiles. In this method there is scope to compare networks comprising differing QoS
protocols interacting with each other.
This work uses Method B as it provides more realistic, but case specific results. Because of the case specific
obtained by this method a wide range of scenarios have been chosen representing small local networks up to
large campus networks. These scenarios are detailed in Figures 1-5.
Model Description
Suitable architectures are chosen to represent local networks of a campus network. These networks are based
on models readily available within OPNET, and some additional models from George Mason University [8].
Campus network(Figure 3)
This represents a campus area network with two routers. Each router has a small local area
network and a large office network connected to it. This network represents the campus backbone
with little traffic being destined to local networks within the campus. The majority of the traffic on
the campus backbone is destined for networks external to the campus.
Traffic Scenarios
Traffic scenarios are to be considered that represent the following conditions: normal working, casual usage
(surfing) and approaching deadline.
Surfing
Deadline
Approaching
FTP
Medium
Medium
Low
HTTP
Medium
High
Medium
Audio
Medium
Low
High
Video
Low
Medium-High
Low
Medium
Medium-High
High
Database
Medium
Low
High
Normal
The majority of users will be using the network in normal conditions.
Surfing
This is representative of the case when network users are surfing for pleasure rather than official
work, and so a different traffic profile is generated.
Deadline
In this scenario the user will make the most use of real time services, and will expect immediate
response from all. In this scenario the user will notice network delays most easily.
Link utilisation
This parameter is a measure of the cost effectiveness of a link within a network or Virtual Private
Network (VPN).
Class utilisation
This is similar to the Link utilisation parameter but gives a measurement of how effectively a
particular reserved class is being used.
After simulation has been carried out the results will be post processed to isolate the above metrics. These
metrics will be analysed to examine how they relate to one another. Further analysis will be carried out to
examine relationships between requested QoS parameters, measured loads and calculated differentials such
that a single measure can be formed to evaluate how efficiently a particular QoS protocol is operating.
Conclusions
Based on the hypothetical networks of this paper it is expected that RSVP, Diffserv and Best effort models of
QoS provision will be used together. Although they will all be used together within the network it is expected
that they will be optimised in the following conditions.
Best Effort
This model is predominant in legacy networks where multimedia service protocols have not been
provisioned. It will also be used in conditions where links are not heavily utilised and excess
bandwidth provides the QoS required.
Diffserv
It is expected that the Diffserv model for providing QoS will favour backbone networks where its
efficiency and scalability will make it the only choice. Diffserv may also find application within
campus networks depending on the traffic presented i.e. a small number of large traffic sources.
RSVP
This model is expected to be the most efficient between local networks where link efficiency is
important and utilisation is high. It would also be useful within local networks if multimedia
services are heavily used.
Following Work
Based on the results obtained from the experiments outlined in this paper it is expected that this work will lead
to the building of a function that can be used to indicate the most efficient QoS scheme for a networking
scenario. This is not expected to be a single function that indicates which protocol is the most efficient but
more likely a set of functions that can be used on a set of nodes to indicate that a change of protocol would
provide a better level of QoS.
References
[1] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, An Architecture for Differentiated
Services, RFC 2475, December 1998.
[2] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, Resource ReSerVation Protocol (RSVP) -Version 1 Functional Specification, RFC 2205, September 1997.
[3] R. Braden, D. Clark, and S. Shenker, Integrated Services in the Internet Architecture: an Overview,
RFC 1633, June 1994.
[4] A. Mankin, F. Baker, B. Braden, S. Bradner, M. O`Dell, A. Romanow, A. Weinrib, and L. Zhang,
Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on
Deployment, RFC2208, September 1997.
[5] Ursula Schwantag, An Analysis of the Applicability of RSVP, Diploma Thesis at the Institute of
Telematics Universitat Karlsruhe, 15 July 1997.
[6] S. Berson, and S. Vincent, Aggregation of Internet Integrated Services State, IETF internet draft draftberson-classy-approach-01.txt, 21 November 1997.
[7] OPNET Simulation Package, (online) http://www.opnet.com/opnet_home.html
[8] Lava K Lavu, Ravi Malghan, Jeimei Ma, Gang Duan and Michael Nah, OPNET RSVP Model, (online)
http://www.nac.gmu.edu/qosip/
[9] Giuseppe Bianchi, and Andrew Campbell, A Programmable MAC Framework for Utility-Based
Adaptive Quality of Service Support, IEEE Journal on Selected areas in Communications, Vol 18, no 2,
February 2000.
[10] R.R.-F. Liao, P.Boukelee, and A.T. Campbell, Dynamic Generation of Bandwidth Utility Curves for
Utility-based Adaptation, Packet Video'99, Columbia University, New York City, April 1999.