OPTIMAL NETWORK PARTITIONING FOR QOS PROTOCOLS.

B.J. Greene and A. Marshall1

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.

School of Electrical and Electronic Engineering, Ashby Building, Belfast.

{b.greene, a.marshall}@ee.qub.ac.uk

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].

Figure 1 Diagram of a small local area network.

Figure 3 Diagram of a campus area network.

Figure 2 Diagram of a large office network.

Figure 4 Diagram of a local section of a backbone

network.

Figure 5 Diagram of servers representing end points on the internet.

These networks are described as follows:

Small local area network (Figure 1)

This represents a small local area network comprising of 10Mb/s switched links. There are twenty
client nodes in the network as well as a local server. The local server and external router are
attached to the switch with a 100Mb/s link. The server node handles 80% of the client server
transactions created within the local network with the remaining 20% being handled on external
networks. As well as client server transactions there are also peer to peer connections (e.g. audio,
videoconferences), these are simulated with 50% of the traffic internal and 50% to external
networks.

Large office network (Figure 2)

This comprises of three small local area networks joined by 100Mb/s links and a master server
shared by the whole network. 60% of client server traffic is for local services from the local server,
20% are with the master server, and the remaining 20% are with external resources. Peer to peer
connections remain at 50% internal 50% external.

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.

Local backbone network (Figure 4)

This represents a small, local portion of the internet backbone. In these experiments all measured
traffic is destined for the node Internet_0, with the other nodes representing routes to this
destination. Traffic between the backbone nodes is generated by the use of routed traffic
generators (a feature of OPNET).

Internet server destinations (Figure 5)

This represents the destination servers within the internet. By using an IP cloud that essentially
generates a random distributed delay and randomly drops packets it is possible to generate more
realistic end points for transactions over the internet.

Traffic Scenarios
Traffic scenarios are to be considered that represent the following conditions: normal working, casual usage
(surfing) and approaching deadline.

Based on these scenarios the traffic generated is as shown in Table 1.

Normal
Condition

Surfing

Deadline
Approaching

FTP

Medium

Medium

Low

HTTP

Medium

High

Medium

Audio

Medium

Low

High

Video

Low

Medium-High

Low

Email

Medium

Medium-High

High

Database

Medium

Low

High

Table 1 Table showing traffic profiles in scenarios.

The scenarios were chosen for the following reasons:

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.

QoS Performance Metrics

From the experiments above a metric will be formed to allow calculation of when another QoS protocol
provides better service than that currently being experienced. These metrics must be able to provide a
measurement of parameters that will be noticeable to the user (perceived QoS) as well as those that highlight
the differences between the QoS protocols i.e. network measurable QoS parameters. The factors involved are:

Number and lifetime of flows per node

These parameters are used to indicate if a node is likely to suffer from CPU and memory shortage
due to the RSVP protocol. These shortages are due to the soft state knowledge held on each flow
through a node, and how often calculations need to be carried out for Connection Admission
Control (CAC).

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.

User perceived QoS

This provides a feedback of how well QoS requirements are met by the network. This will include
delay, delay variation, and bandwidth, but will be referenced to a perceived QoS, because different
applications react differently to variation from requested QoS [9], [10].

Aggregated QoS differential

This is a measure of the over or under provision of resources when per flow traffic is aggregated
to per class queuing.

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.