Embed Size (px)
Citation preview
BGRP: Quiet Grafting Mechanisms for Providing a Scalable
End-to-End QoS solution
Petros Sampatakosa, Lila Dimopouloua, Eugenia Nikolouzoua,*, Iakovos S. Venierisa,Thomas Engelb,1, Martin Winterc,2
aDepartment of Electrical and Computer Engineering, National Technical University of Athens, 9 Heroon Polytechniou str, 157 73 Athens, GreecebCorporate Technology, Networks and Multimedia Communications, Siemens AG, Munich, GermanycInformation and Communication Networks, Hofmann str. 51, Siemens AG, 81359 Munich, Germany
Received 29 August 2002; revised 20 June 2003; accepted 14 July 2003
Abstract
The provisioning of quality of service guarantees over a region spanning multiple administrative domains is nowadays one of the most
basic and crucial issues. A scalable and efficient end-to-end QoS architecture is indispensable for ensuring the desired QoS guarantees to
QoS-aware services. Towards this end, this paper introduces a scalable inter-domain resource control architecture for Differentiated Services
networks. The proposed architecture is based on the Border Gateway Resource Protocol framework, while scalability issues are further
elaborated. Therefore, our discussion mainly extends to Quiet Grafting mechanisms, which succeed in significantly limiting the signalling
load and efficiently handling the resources reserved between domains. Extended simulation scenarios verify the efficiency of the proposed
‘quiet grafting mechanisms’, while the applicability of the results, especially with respect to real world networks and scenarios is stated.
q 2003 Elsevier B.V. All rights reserved.
Keywords: Inter-domain reservation protocol; Border gateway reservation protocol; Quiet grafting; Sink tree; Scalability
1. Introduction
Internet traffic has been growing at an exponential rate,
being driven by the increasing number of users and the
introduction of new demanding applications. For large
transit networks being traversed by a great amount of traffic,
it is almost impossible to maintain reservation control state
for all traffic flows without affecting the performance of the
network. At the same time, packet-forwarding state is also
important to be kept at a minimum for allowing a resource
reservation scheme coupled with traffic engineering mech-
anisms to scale with the ever-increasing traffic load.
Although this coarse granularity comes at the expense of
providing hard QoS guarantees to traffic flows, it allows
for scalability and efficiency. However, at present,
the prevailing best effort model does not provide any kind
of service differentiation or guarantee for this evolving
environment. The current Internet is incapable of satisfying
diverse quality requirements and different user expectations,
particularly in an end-to-end scenario. This necessitates an
end-to-end resource reservation scheme for the provision of
quality of service (QoS) guarantees, which will scale well
with the evolution of the Internet.
The current effort is basically focused on two distinct
approaches: the Integrated Services (IntServ) [1] and the
Differentiated Services (DiffServ) [2,3]. The former was
the first significant step for the introduction of QoS in the
Internet. IntServ uses the Resource Reservation Protocol
(RSVP) for the explicit set-up of reservation state on each
network node along the path from the sender to the receiver.
However, the need for separate reservation establishment
for each flow as well as the constant exchange of RSVP
messages for maintaining a session have raised scalability
concerns. The main problem is that the amount of state
information stored in each router increases proportionally
with the number of flows. This places a huge storage and
0140-3664/$ - see front matter q 2003 Elsevier B.V. All rights reserved.
doi:10.1016/j.comcom.2003.07.001
Computer Communications 27 (2004) 423–433
www.elsevier.com/locate/comcom
1 Tel.: þ49-89-636-48093; fax: þ49-89-636-51115.2 Tel.: þ49-89-722-63718; fax: þ49-89-722-41920.
* Corresponding author. Tel.: þ30-10-2772-2424; fax: þ30-10-2772-
2534.
E-mail addresses: [email protected] (E. Nikolouzou), psampa@
telecom.ntua.gr (P. Sampatakos), [email protected] (L. Dimopoulou),
[email protected] (I.S. Venieris), [email protected]
(T. Engel), [email protected] (M. Winter).
processing overhead especially on the backbone routers.
Therefore, the support of the IntServ/RSVP framework
imposes many scalability limitations especially when the
Internet core network is considered, which is traversed by
millions of flows.
In contrast to the per-flow orientation of RSVP, the
DiffServ architecture classifies packets into a small number
of aggregated flows, based on the DiffServ Code-Point in
the packet’s IP header. The primary benefit of DiffServ is
scalability, since it eliminates the need for per-flow state and
per-flow processing and therefore scales well to large-scale
networks. However, this model is rather static since it lacks
the signalling protocol for dynamic resource reservation. It
only provides data-plane mechanisms (in band QoS
signalling), able to treat user traffic with a relative QoS
(e.g. based on static Service Level Agreements, SLAs),
while it lacks control-plane mechanisms that operate prior
to data transmission for dynamically reserving resources
(out of band QoS signalling) [4]. Towards this direction, the
concept of the Bandwidth Broker has been introduced from
the early stages of the DiffServ model [5], and is mainly
responsible for performing policy-based admission control
and managing network resources among other.
Combinations of IntServ over DiffServ architectures
have been introduced and several other protocols have been
defined for signalling the QoS requirements of flows to
nodes in an IP network [6]. Nevertheless, as witnessed by
the activity of the IETF NSIS WG [7], the support of
dynamic QoS over a number of different domains is still an
open issue. QoS signalling capabilities are indeed needed to
extend the provisioning of QoS in IP networks from a static
model towards a dynamic one. However, a fundamental
issue in the definition of an inter-domain QoS model is the
scalability, since the motivation is to support QoS services
on the scale of the global Internet.
On providing a more scalable and easy deployable
solution for inter-domain resource reservation, we propose
the BGRP Plus (BGRPP) architecture [8], which has
originated from the Border Gateway Resource Protocol
(BGRP) framework [9]. The latter proposes a solution to the
scaling problem, by providing sink tree based aggregation
for resource reservations over a network of DiffServ
domains. The aggregated reservations are negotiated
between BGRP-enabled nodes, which are co-located at
each BGP (Border Gateway Protocol)-capable border router
of each DiffServ domain. Admission Control is performed
individually within each domain pertaining to the end-to-
end path, taking into account its available resources as well
as bilateral agreements with its peer domain. By aggregating
the reservations according to the sink trees created by the
BGP routing protocol [10,11], the number of reservations
and thus the amount of state and control information in the
network is reduced.
However, aggregation of reservations is just the first step
towards scalability. To further limit the signalling load and
the processing power required by the BGRP-enabled nodes,
mechanisms for the early response to reservation messages,
in Ref. [9] called Quiet Grafting, are proposed in this paper.
The so-called Quiet Grafting mechanisms are defined within
the BGRPP context, which is presented in detail in Ref. [8].
They focus on reducing the path that a signalling message
has to travel along a region composed of a number of
DiffServ domains in order for a reservation request to be
established. Our main objective is to state the significance of
these mechanisms, which are evaluated through a number of
simulation scenarios, considered in the context of real
network topologies.
The remainder of this paper is organized as follows.
Section 2 outlines the inter-domain signalling requirements
that are specifically met by the BGRPP framework and
gives an overview of the protocol’s operation. Section 3
focuses on the Quiet Grafting mechanisms and provides an
analysis of the proposed solutions. We continue with
Section 4 where the results of the simulations carried out
for evaluating the proposed enhancements are presented.
Finally the conclusions are given in Section 5.
2. Inter-domain resource reservation
2.1. Requirements
When defining inter-domain resource reservation mech-
anisms, it is imperative that certain requirements [12] are
taken into account since the applicability of such solution
will span several administrative boundaries, each with its
own policies, resource control architectures and traffic
engineering mechanisms. For that reason, a common
language (signalling protocol) is needed for communicating
end-to-end the QoS requirements of user traffic while at the
same time respecting the individualities of the autonomous
operation of each traversed domain. The requirements of an
inter-domain resource reservation scheme are listed below:
† Scalability and robustness. The protocol has to scale well
with the Internet size and growth. It should allow
minimization of resource reservation state, bandwidth
utilization and processing load demands for intermediate
nodes. In addition, it must be robust against failure and
other conditions. Typically soft state management is
considered for robustness reasons when reserving
resources.
† Autonomous operation and independence between
domains. Autonomous operation of each domain should
be enabled. Accordingly, each domain’s network oper-
ator independently administers his network, chooses its
traffic engineering policies, and configures the behaviour
of the intra-domain resource reservation elements.
Moreover, admission control is also made autonomously
in each domain. Consequently, the inter-domain protocol
should be independent of the intra-domain resource
control architecture. However, the definition of
P. Sampatakos et al. / Computer Communications 27 (2004) 423–433424
a common interface between intra-domain and
inter-domain resource control is a prerequisite.
† Independence from routing functionality. Inter-domain
resource reservation does not entail routing functionality
but should rely on inter-domain routing (e.g. BGP) for
routing decisions. An interface has to be defined between
inter-domain routing and inter-domain resource reser-
vation to allow the latter to retrieve routing information
(e.g. the NEXT_HOP).
† Respecting SLA. In the inter-domain scope, the most
important constraint is not an optimization of network
resources but the conformity to the SLA with the
neighbour. When a reservation request crosses auton-
omous systems (ASs), the border routers should make
sure that the request is in compliance with the SLA.
The BGRPP framework emerges as a scalable answer to
these needs.
2.2. BGRPP—a candidate solution
When resource reservation mechanisms will be deployed
in a large-scale environment, it is imperative that scalability
issues are taken into utter consideration. The problem
particularly arises in large transit domains where the number
of simultaneous reservations processed at each domain’s
routers may become extremely high and thus prohibitive
with regard to the computational and communication
resources. More precisely, the number of reservations that
a router may maintain in a non-aggregated reservation
scheme grows like OðN2Þ with N the number of end-hosts in
the internet. It is therefore evident that individual handling
of each flow (on an end-host basis) is not considered to be a
viable solution when applicable to inter-domain QoS
reservation schemes. In essence, the need for a further
aggregation is made apparent for addressing effectively the
aforementioned constraints.
The BGRP approach, introduced by Pan et al. [9],
proposes the aggregation of reservations on the basis of the
destination domain. This functionality is closely related to
the property of the BGP routing protocol that enables the
creation of sink trees while domains trace their route
towards a particular domain. Consequently, reservations are
aggregated along the sink trees created by BGP, thus
limiting to a great extent the number of active reservations
maintained at the routers to a factor of OðNÞ: However, here,
N corresponds to the number of ASs.
Accordingly, BGRPP operates between BGP-capable
border routers of each DiffServ domain, namely the BGRPP
agents. For providing the desired communication, three
messages are mainly used in the BGRPP framework as
described in Ref. [8]: the PROBE, GRAFT and REFRESH
messages. Fig. 1 depicts a reference network where the
BGRPP framework can be applied. We have to stress here
that the presented messages are not regarded as an
innovation of the BGRPP architecture but are based on
the ones introduced in the BGRP framework.
Towards a better understanding of the BGRPP operation,
it is assumed that the source domain is capable of
performing some kind of per-flow admission control, taking
into account the available resources up to BR1. The source
domain has, however, no information regarding the
availability of resources along the rest of the path towards
the destination domain. To perform inter-domain resource
Fig. 1. A reference network for the appliance of the BGRPP concepts.
P. Sampatakos et al. / Computer Communications 27 (2004) 423–433 425
reservation, the source domain determines the egress border
router, which contacts the corresponding BGRPP agent. The
latter, through the BGRPP protocol operation, is able to
request the reservation of resources while checking their
availability in each domain along the path to the destination.
Each BGRPP agent controls the resources on the next
BGRPP path segment towards the destination, i.e. the path
between its associated BR and the BR of its peer BGRPP
agent. Resource reservation in the source and destination
domain is not a task of the BGRPP protocol. However, as we
describe later, BGRPP has to provide mechanisms to enable
resource reservation in the destination domain.
Therefore, the BGRPP agent of the source domain
creates a PROBE message, forming in this way an inter-
domain resource reservation request, where the required
amount of resources and the destination address are
specified. However, it is not evident, to which sink tree
this reservation will belong. So the PROBE message is
forwarded between BGRPP agents hop-by-hop along the
BGP route until it reaches the destination domain. On its
way towards the destination domain, the path of auton-
omous domains traversed by the PROBE message is
recorded within it and resource availability within each
domain is checked upon. Given that the BGRPP agents
forming the end-to-end path can provide adequate
resources, the PROBE message reaches its destination.
The last BGRPP agent, which corresponds to the root of the
sink tree, can assign a sink tree identifier to the reservation,
which uniquely identifies the sink tree the reservation
belongs to. Then, a GRAFT message is generated contain-
ing this identifier. The GRAFT message travels back to the
source along the recorded path. Each BGRPP agent
belonging to this path, after processing the GRAFT
message, aggregates the reservation with the existing ones
pertaining to the same sink tree and reserves the requested
resources.
Finally, REFRESH messages are exchanged regularly
between BGRPP agents with the aim of preserving
the reservation state established at the corresponding
routers.
Summarizing, BGRP mainly addresses the scalability
problem in terms of the state information kept at the border
routers and the REFRESH messages overhead. However,
the enhancements proposed in the rest of the paper,
differentiating BGRPP from the BGRP framework, aim at
limiting the path length traversed by the PROBE and
GRAFT messages, alleviating to a greater extent the
scalability problem.
3. Quiet grafting
3.1. Objectives and requirements
Quiet Grafting comprises the sum of mechanisms
used for further enhancing the scalability property of
the BGRP. BGRPP therefore corresponds to BGRP when
the latter is augmented with the Quiet Grafting mechan-
isms, described later in the paper. In BGRPP, scalability is
further enhanced with respect to the following two
elements:
† The bandwidth utilization of the protocol messages
exchanged between BGRPP peers.
† The CPU usage for message processing. By this last
objective, we imply reducing the frequency of BGRPP
reservation messages and not their complexity.
These two elements form the main objectives of the
proposed Quiet Grafting mechanisms. They are realized
by enabling the grafting of reservations into the sink
tree, without the need for reservation messages to travel
all the way to the root of the tree. This capability,
however, imposes certain requirements to the conven-
tional BGRP.
If we look more carefully into the protocol operation, we
will see that each BGRPP agent forming the end-to-end path
has no way to identify the sink tree that a reservation
belongs to. It simply forwards the PROBE message hop-by-
hop between BGRPP agents by following the BGP route to
the destination domain. Due to the route aggregation
performed by BGP, it no longer has a flat view of the
Internet but rather an hierarchical one and therefore cannot
determine the destination domain of a reservation. More-
over, resource availability is checked individually in all
domains traversed by the PROBE message. These two
observations form the basis of searching for the appropriate
techniques for conveying such information to BGRPP
entities.
If this is feasible, an intermediate BGRPP agent will be
able to successfully answer a PROBE message, before the
latter reaches the destination domain. Towards this end, the
following conditions should be met:
† The BGRPP agent must be able to identify the sink tree,
to which the reservation belongs.
† The BGRPP agent must have pre-reserved resources for
this sink tree, so that it can guarantee that the resources
are available on the path from the current point to the
destination domain.
† As the last BGRPP agent may no longer be informed
about a new reservation, the BGRPP agent intercepting
the request must provide means to contact the destination
domain, so that resources can also be reserved on the
non-BGRPP-controlled path (from BR4 to ER2 in Fig. 1).
The following sections describe the proposed techniques,
that is, network layer reachability information (NLRI)
Labelling, Resource Cushion creation and Signalling in the
last domain, which aim at providing an efficient solution to
the above requirements.
P. Sampatakos et al. / Computer Communications 27 (2004) 423–433426
3.2. NLRI labelling for sink tree identification
The potential for grafting a new reservation onto an
existing sink tree necessitates the classification of
the reservation to the corresponding tree. For enabling this
mapping, NLRI is considered adequate since it can be used
to identify the root of the tree at a distant point in the
network. The NLRI information is propagated back from
the root of the sink tree in GRAFT messages and this
information is stored in each BGRPP agent, which processes
the message. Future PROBE messages that arrive at NLRI-
aware BGRPP agents can be checked for whether or not
they belong to the specific tree and can be potentially
grafted (if resources are also available). In particular, the
BGRPP agent compares the destination IP address of the
reservation request with the available tree’s NLRI infor-
mation and performs the sink tree identification.
Here, we give some more details on the BGP operation
while trying to justify the back-propagation of the NLRI that
identifies the root of the tree. BGP4 provides a new set of
mechanisms for supporting Classless Inter-Domain Routing
(CIDR) [13]. The concept of CIDR is to move from the
traditional IP classes (A, B, C) to the more flexible model of
IP prefixes. Therefore, in BGP terms, a destination (root
of the sink tree in our case) is characterized by an instance of
the 2-tuples klength, prefixl, where length is the number of
masking bits that the particular prefix has [14]. This
information is carried within BGP update messages, and is
referred to as NLRI. However, when route aggregation is
performed by a BGP entity, the latter no longer distributes
the NLRIs of specific routes but decides to send for example
a single NLRI corresponding to the aggregate of a number
of routes. This way, a BGRPP entity located far away from
the root of a tree (co-located with a BGP peer) might be
aware (through BGP) of the aggregate NLRI covering a
number of domains. By comparing a reservation’s IP
address with this NLRI, it has no fine-grained knowledge
of the request’s destination domain.
Although the NLRI labelling allows us to identify the
destination of a request, it gives us no guarantees that the
same route is always followed towards the same destination,
i.e. that a single route exists. However, we can say with
certainty that BGP provides this assurance in its normal
operation, unless a BGP route change appears possibly due to
a failure in the network. A route is primarily determined by
the AS’s local preference (policies, etc.) which is defined
by the ‘local preference’ attribute of BGP updates, and then
by the length of the path (shortest path is preferred, AS_path
attribute). Given these facts, BGP will create a single route
between a source and destination domain.
This proves to be of great importance since a reservation
request (PROBE message) can be satisfied earlier (answered
with a GRAFT message) without having to travel all the
way towards the root of the sink tree as long as the latter has
been identified. Successful sink tree identification is a
precondition in order to perform successful Quiet Grafting
as described in next sections. The potential of a route
failure, which will lead to a route change, can be addressed
by having the BGRPP agent that detected this change send a
PROBE message towards the root of the tree for establishing
the reservation state on the new path. This message will be
answered with a GRAFT message by the first BGRPP entity
pertaining to this sink tree.
3.3. Techniques for the creation of resource cushions
Irrespective of the identification of a sink tree as
described above, the quiet grafting of a new reservation
will not be feasible if there are not enough resources so as to
accommodate the new request. Therefore, it is required that
BGRPP agents are assigned with more bandwidth than
currently reserved. To accomplish that, over-reservation,
quantization and hysteresis techniques are likely to be
employed.
However, the limitations being introduced by the first
two approaches are of considerable concern with respect to
their impact on the quiet grafting probability and can
inadvertently produce the opposite effects to the ones
envisioned. Over-reservation entails the reservation of more
resources than actually required from BGRPP nodes
towards the root of the sink tree, based on traffic demand
predictions. Predicting future loads on network links has
been elaborated in many previous works [15,16] and still
remains an ongoing task, since an overestimation of future
bandwidth demands may result in inefficiently utilizing the
network resources. Moreover, the application of the specific
technique in our case would introduce further perplexity,
given that the prediction of bandwidth demands over end-to-
end paths would be required. Furthermore, the uncontrolled
usage of the over-reservation technique could lead to a
reduction of the quiet grafting effectiveness when consider-
ing the fact that future requests, coming from BGRPP nodes
other than the ones with over-reserved resources, are likely
not to be grafted onto the tree or not to be accommodated at
all due to a shortage of resources.
Quantization of the requested resources, i.e. rounding
them up to a multiple of a chosen quantum, could lead as
before to undesirable results. This is particularly true in the
case of sink trees that consist of many leaf nodes (N) and are
moreover incapable, due to lack of future reservation
requests, of using the remaining amount of the reserved
bandwidth. As a result, the root of the sink tree would end up
having reserved at least N £ quantum resources, far
surpassing the actual needs. Thus, the adoption of the
quantization mechanism could only be justified for sink
trees with a limited amount of leaves and a much greater
rate of reservation requests.
We have to stress here that the use of either of the above
two techniques should be coupled with a scheme for the
release of unused resources. For example, a combination of
over-reservation and hysteresis techniques is proposed in
Ref. [9] in order to improve the performance of BGRP.
P. Sampatakos et al. / Computer Communications 27 (2004) 423–433 427
In essence, given the aforementioned concerns coupled
with the complexity induced by the adoption of the
corresponding techniques, it has been proposed that the
BGRPP agents do not perform over-reservation or quantiza-
tion upon receiving a new reservation request. Instead, the
concept of hysteresis will be deployed for the formation of
resource cushions at the BGRPP agents.
The resource algorithm presented in this paper, as will be
described later in detail, will base its resource release policy
on a delayed resource release scheme, where bandwidth will
be released only when it is not used for a certain period of
time.
3.3.1. Resource cushion algorithm
On the condition that a BGRPP agent is able to determine
the sink tree after processing the PROBE message, it will
then check whether it has pre-reserved resources on this sink
tree. If this is the case, it can generate a GRAFT message
and terminate the PROBE at this stage. Otherwise, the
BGRPP agent will further forward the PROBE message to
the next BGRPP agent, as determined by the NEXT_HOP
attribute of the BGPP path to the destination of the request.
The amount of pre-reserved resources that is available at
a given time for a sink tree is called resource cushion. The
pre-reserved resources are accumulated by not immediately
releasing the resources, when a reservation is finished. The
actual release procedure is dictated by the resource cushion
algorithm. Building resource cushions has a great impact on
the reduction of the signalling load.
A BGRP agent uses two parameters to control the size of
its resource cushions. These parameters are:
RBS: release block size
RP: retain period
Both parameters together define a virtual release rate
RR ¼ RBS/RP. Whenever a resource cushion exceeds the
RBS, a release timer is activated which runs down during
the duration of a single RP (Fig. 2).
If a resource cushion shrinks to a size below RBS during
a running release timer, then the release timer is cancelled.
In the case where the release timer runs out without being
cancelled, then the corresponding resource cushion is
decreased by RBS and a REFRESH message releasing
this amount of resources is generated and sent downstream
to the next BGRPP agent on the sink tree. Thus, resource
cushions are reduced with the release rate RR unless they
are used to serve arriving resource requests. In this way,
released resources are not immediately forwarded towards
the sink of the tree, but are used to form resource cushions.
Retained resources are released step-wise improving in this
way the performance of the network.
3.4. Signalling in the last domain
As already specified, the BGRPP enables the reservation
of resources along the end-to-end path, running on BGP-
enabled routers, i.e. the border routers of each domain.
Moreover, the Quiet Grafting mechanisms inhibit the
forwarding of signalling messages to the destination
domain, since these may be already answered at some
intermediate stage. This has as an impact that the last
domain is unaware of a new user reservation or a release
request.
Specifically, resource reservations are carried out or pre-
reserved resources are used up to the ingress border router of
the destination domain. Therefore, only the ingress border
router of the last domain has reserved resources, while no
resource reservation is performed on the path from the
ingress border router to the egress edge router, which is
connected to the destination host. In order to enable though
edge-to-edge QoS-aware services, it is necessary to reserve
resources within the last domain.
In particular, taken into account the requirement of
independence between intra- and inter-domain resource
control mechanisms, each domain should provide a
standardized interface to its intra-domain resource control
entity. Therefore, by augmenting the information carried
within the GRAFT message, we can solve the problem of
signalling in the last domain. It is actually proposed to back-
propagate a reference to this interface as well as the IP
address of the ingress border router of the last domain within
the GRAFT message so that this information is stored at
each intermediate BGRPP agent. In this way, the originating
BGRPP agent can then use this reference to directly reserve
resources in the destination domain.
4. Simulations
4.1. Simulation goals
In this section, the gain of introducing the Quiet Grafting
mechanisms in a network will be evaluated, in terms of
average hop number reduction that a PROBE (GRAFT)
message has to traverse in order for a reservation to beFig. 2. The creation of resource cushions.
P. Sampatakos et al. / Computer Communications 27 (2004) 423–433428
established. For that reason, two simulation scenarios,
aiming at a dynamic analysis, will be specified.
Quiet grafting aspires to reduce the average number of
traversed hops for a signalling message, and consequently
the total number of messages in the network. We aim at
evaluating the gain on the reduction of the path length in
relation to (a) the extent of the NLRI information
advertisement to the BGRPP agents and (b) the depth of
the sink trees.
Our second goal evaluates the same gain when the
resource cushion mechanism is applied. It is worth
mentioning that there is a trade-off between signalling
overhead and resource utilization. We are seeking a relation
between the gain in terms of the average hop number
reduction, and the utilization of the reserved resources.
Both simulation scenarios aim at studying and evaluating
the efficiency of the Quiet Grafting mechanisms. The first
scenario serves as a proof of concept for the early tree
identification mechanism evaluating the gain on the
message path length reduction. The second scenario
validates the applicability of the resource cushion algorithm
and evaluates the performance of the proposed approach.
4.2. Proof of concept of early identification
Our main goal is to evaluate the effectiveness of the
Quiet Grafting mechanisms in terms of the number of hops
that a reservation request has to traverse in order to be
accommodated into its corresponding sink tree. It is
assumed that resources are always available, and therefore
the effectiveness of the NLRI information distribution will
be solely examined.
The topology for carrying out the simulations has been
defined after taking into account the actual topology of the
Internet. More precisely, the number of the AS domains that
an inter-domain reservation can possibly traverse will not
exceed the 9 [17,18]. In addition, for each transit AS
domain, there will be most probably two border routers
(Fig. 1) that will forward the reservation request to the
border router of the adjacent downstream AS domain. Given
the fact that there will be one BGRPP agent corresponding
to a border router of the AS domain, we can deduce that the
path being traversed by a reservation request will consist of
a maximum number of 18 BGRPP agents.
Hence, the simulations performed are based on sink tree
topologies that vary in depth3 (3–13) in order that they
reflect the actual topology of the Internet. Moreover, in
regard to the spreading of the sink trees, binary trees have
been solely examined since more complex topologies are
not considered to be of significant added value with respect
to the goal of the simulations. An example binary sink tree
of depth 4 is shown in Fig. 5.
For identifying the effectiveness of the NLRI distribution
to the nodes of a sink tree, it is essential to examine how
the number of populated nodes can contribute to the
reduction of the path length. With the term ‘populated
nodes’ we denote the BGRPP agents that are aware of the
NLRI information of the destination domain (root of the
tree) and therefore can identify the destination (sink tree)
of the impending reservation request. These nodes are
assigned the task of intercepting a reservation request before
reaching the root of the tree and silently grafting it onto the
sink tree. It would be ideal if every node of a sink tree was
populated but obviously, the ‘number’ of populated nodes
performing this identification introduces a scalability
problem. If this were true, then we would actually bring
into scene again the problem that has been tackled by the
BGP through the aggregation it performs on routes.
Given a particular binary sink tree, an ‘initial state’
(number) of populated nodes needs to be created in relation
to which, the mean path length of a potential reservation
request is computed. This state is produced after performing
a certain number of reservations towards the root of the tree.
The nodes of the tree (not necessarily leaves) dedicated for
initiating those reservations are randomly chosen. All the
nodes that are traversed while the reservations make their
way up to the root are transformed to populated nodes. In
this way, an initial state of populated nodes can be produced
whose topology significantly mitigates the potential degree
of homogeneity introduced by the binary tree.
Our aim is to compute the impact of this state, i.e. of the
number of populated nodes, on the average number of nodes
that a reservation request has to traverse before striking a
populated one. To that end, a certain amount of additional
reservation requests to the ones that have produced the
‘initial state’ needs to take place. As before, randomly
selected nodes initiate those reservations, which do not
modify the initial state of populated nodes, i.e. they do not
produce further populated nodes, as is the case with the
creation of the ‘initial state’. Therefore, a mean value of the
number of nodes traversed before striking a populated one
can be computed for a particular populated state.
4.2.1. Simulation results
The simulations were carried out for a variety of binary
sink trees and a variety of ‘initial states’ (number of
populated nodes) for each tree. Nonetheless, we have
chosen to demonstrate how a particular sink tree of depth
9 behaves to the augmentation of the populated nodes
since it is considered as the most representative for an
inter-domain reservation (four transit AS domains). It can
be seen from Fig. 3a and b how the number of
populated nodes, which comprises a relatively low
percentage (4–20%) of the total number of nodes
(2047), affects the average hop count of a PROBE
(GRAFT) message. Having in mind that for a non-
populated tree, where quiet grafting is not activated, the
number of nodes traversed is equal to 10, it can be
deduced that the percentage corresponding to the
reduction of the actual hop count attains the values of3 In the rest of the paper, the root of the tree is regarded to have depth 0.
P. Sampatakos et al. / Computer Communications 27 (2004) 423–433 429
around 47–77% for remarkably small percentages of
populated nodes.
However, it can be seen from Fig. 4, that in the case of
sink trees of small depth (1–3 transit domains), the
percentage reduction of the path length does not attain the
same values. In fact, a comparison between five sink trees
with depth values of 3, 5, 7, 9 and 11 is presented in
terms of the path reduction for the same percentage of
populated nodes. It is evident that the sink trees of small
depth do not exhibit the same effectiveness on the
reduction of the path length for a certain percentage of
populated nodes. For example, a sink tree of depth 5 with
20% populated nodes will attain a 63% reduction of the
path length whereas a sink tree of depth 11, for the same
percentage of populated nodes, will achieve an 80%
reduction of the path length.
4.3. Performance evaluation of resource
cushion mechanism
In order to evaluate the proposed Quiet Grafting
mechanisms, the resource cushion algorithm and the
ability of early sink tree identification are used in
conjunction. It is assumed that every BGRPP agent of
the sink tree can identify the destination domain, and
therefore can execute the following step; the BGRPP
agent will check, whether it has enough resources to
accommodate a new reservation request. If there are
sufficient resources, the PROBE message will be termi-
nated and a GRAFT message will be generated, following
the reverse path towards the source.
For that purpose, a simulation scenario is specified,
which is based on the realization of a sink tree reflecting
a real network that is consisted of a number of inter-
connected DiffServ domains. In fact, a simple binary and
complete tree is proposed, since the properties of
symmetry simplify the interpretation of the results.
Each node of the sink tree corresponds to a BGRPP
agent capable of performing quiet grafting.
In order to have a relatively large number of nodes,
while keeping at the same time complexity at a low
level, the depth of the tree for this simulation scenario
was chosen to be equal to 4. That results in a total
number of N ¼ 31 nodes. This scenario could represent a
real network topology, consisting of a number of source
domains, the destination domain and the transit domains
in order to form the binary tree as depicted in Fig. 5.
Concerning the traffic model used for the simulation
scenario, a traffic generator that generates reservation
requests with exponential distributed inter-arrival times
and exponential distributed holding times is attached to
nodes belonging to source domains. As regards the size
of each reservation request, for the sake of simplicity, a
homogeneous scenario is assumed where all the reser-
vations have the same fixed size. Without loss of
generality, each request asks for one unit of bandwidth,
since an infinite bandwidth capacity is presumed for
every node of the tree. Two different scenarios are
considered with different traffic loads, 20 and 100 flows
average accordingly, in order to examine the effect of
load on the performance of the quiet grafting mechanism.
During an initial phase, each reservation request
(PROBE message) has to travel all the way up to the
root of the tree in order that resources are reserved. After
the initial phase, sequential requests can be potentially
accommodated from the already reserved resources, due
Fig. 3. (a) Path length reduction (%) vs. populated nodes (%). (b) Mean path length traversed by the signalling messages vs. populated nodes (%).
Fig. 4. Path length reduction (%) for sink tree of different depths.
P. Sampatakos et al. / Computer Communications 27 (2004) 423–433430
to the resource cushion algorithm given the fact that the
sink tree has been successfully early identified.
Two performance metrics were used to rate the Quiet
Grafting mechanisms performance: the average signalling
overhead and the average resource utilization for the
whole sink tree.
The average signalling overhead S for a sink tree with a
number of n nodes, is defined as
S ¼
Xn
j¼1
routð jÞ
Xn
j¼1
rinð jÞ
£ 100%
where rinðjÞ is the number of received requests of node j and
routðjÞ is the number of forwarded requests of node j:
The signalling overhead indicates the fraction of signalling
messages that cannot be answered locally but are forwarded
to the next BGRPP node.
The average utilization r for the whole tree is defined as
r ¼
Xn
j¼1
Rreserved
Xn
j¼1
Rassigned
£ 100%
where Rreserved is the bandwidth used by the active
reservations and Rassigned is the bandwidth reserved by the
specific BGRPP node.
4.3.1. Simulation results
Based on the realized resource cushion mechanism, the
RBS and the RP parameters need to be appropriately tuned
Fig. 5. (a) The network topology. (b) The corresponding sink tree (bottom). We considered a network topology consisting of 16 source domains, a number of
transit domains and the destination domain. There are two levels of transit domains, which correspond to the depths ‘1’,‘2 and 3’ of the created sink tree.
P. Sampatakos et al. / Computer Communications 27 (2004) 423–433 431
for accomplishing the desired network performance. The
guidelines for setting these parameters compromise a trade-
off between achieved resource utilization and signalling
overhead. A great value of RBS may result in a low network
performance, but will provoke a smaller number of
exchanged signalling messages. On the other hand, a
small value of RP results in frequent checks on the current
resource status, and therefore improves the network
utilization, but burdens the routers’ processing.
The results concerning the overall resource utilization
and signalling overhead of the sink tree, in relation to RP
and RBS, are shown in Fig. 6 and Fig. 7 where 20f or
100f denote the different traffic loads (all simulation
scenarios have a duration of 10 h).
Fig. 6a and b present the effect of the release period
RP on the performance of the resource cushion
algorithm. As expected, the overall signalling overhead
percentage decreases, respectively, to the increase of the
release period. By increasing the RP parameter (which
represents the time during which the free resources
should exceed the RBS), resources are released less
frequently. Longer retained resources may accommodate
future requests, limiting in this way the number of
requests forwarded to the next node. On the other hand,
the increase of the RP has a negative impact on the
average utilization of the sink tree, since the resource
status is checked less frequently, resulting in longer
intervals between subsequent releases of resources.
Notice that under heavy load conditions the average
signalling overhead is reduced to 2.2171%. Moreover,
the fraction of initial resource requests that reach the
destination domain varies from 2.275 to 0.678% while
the RP increases from 10 to 200 s under low load
conditions, while the corresponding numbers under heavy
load conditions are 1.01–0.4525%.
The effect of the RBS is depicted in Fig. 7a and b. We can
observe that there is an RBS that follows changing demand
optimally. We have to stress here that lower RBSs do not
decrease allocated bandwidth fast enough, while larger
RBSs cannot follow small temporary demand changes. With
a very small RBS, resources are not released fast enough to
follow the changing bandwidth demand. Moreover, more
requests are forwarded with higher RBS values, because
releases follow demand closer. Nevertheless, large RBS
values do not allow to follow small demand changes. This
decreases the number of forwarded requests to lower levels
again beyond a certain RBS value.
This is justifiable if we consider that while the RBS is
increased (but still gets small values), a greater amount of
resources is released resulting in a higher level of
utilization. Moreover, since the release resources procedure
is more frequently performed, a smaller amount of resources
is retained for accommodating future requests, resulting in a
higher signalling overhead. Nevertheless, as the RBS rises
Fig. 6. (a) Signalling overhead vs. release period. (b) Resource utilization vs. release period.
Fig. 7. (a) Signalling overhead vs. RBS. (b) Resource utilization vs. RBS.
P. Sampatakos et al. / Computer Communications 27 (2004) 423–433432
up to really great values, the possibility of accumulating that
amount of free resources declines. This significantly impacts
the utilization level, particularly under low load conditions.
Accordingly, it is anticipated that the signalling overhead
will be reduced.
It is obvious from the above analysis that the algorithm’s
performance is much more sensitive to the RP than to the
RBS parameter. Moreover, the performance of the quiet
grafting mechanisms is considerably improved under heavy
load conditions.
5. Conclusions
In this paper, the need for a scalable inter-domain
resource control architecture has been considered, taken into
account the evolving Internet infrastructure and the
diversity of intra-domain resource control mechanisms.
The extensions proposed to the BGRP approach, namely
the Quiet Grafting mechanisms, comprise the main
contribution of this paper over the existing BGRP approach,
providing solutions for the early sink tree identification—
NLRI mechanisms—and enhanced mechanisms for the
resource management along the end-to-end path—resource
cushions. The BGRPP framework seems to provide a
promising solution, since it succeeds to further reduce the
signalling overhead, and consequently limits the protocol’s
bandwidth utilization as well as the induced processing
load. As an example, the gain from the use of Quiet Grafting
mechanisms over a scenario without this mechanism is
approximately 80% concerning the signalling overhead.
In the context of the AQUILA project, the BGRPP
framework was implemented and evaluated in a real
network topology, which has provided further insight and
experiences. Nevertheless, many issues still need to be
defined in order to render BGRPP capable of coping with
the evolving environments and providing end-to-end QoS
over heterogeneous networks (both wired and wireless).
More extended simulation scenarios could provide further
insight into the behaviour of the BGRPP in different
network topologies, and therefore examine the impact of
different sink trees on its performance. Further steps could
include the analysis of requirements for applying the
BGRPP concept over wireless networks (diverse radio
conditions and handoff issues) as well as for supporting
multicast reservations.
Acknowledgements
This work was performed in the framework of IST
Project AQUILA (Adaptive Resource Control for QoS
Using an IP-based Layered Architecture, IST-1999-10077)
[19] funded in part by the EU. The authors wish to express
their gratitude to the other members of the Aquila
Consortium for valuable discussions.
References
[1] R. Braden, D. Clark, S. Shenker, Integrated Services in the Internet
Architecture: An Overview, RFC 1633, IETF, June 1994.
[2] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, W. Weiss, An
Architecture for Differentiated Services, RFC 2475, IETF, December
1998.
[3] K. Nichols, V. Jacobson, L. Zhang, A Two-bit Differentiated Services
Architecture for the Internet, RFC 2638, IETF, July 1999.
[4] H.-L. Lu, I. Faynberg, An architectural framework for support of
quality of service in packet networks, IEEE Communications
Magazine (2003) 98–105.
[5] QBone Bandwidth Broker Architecture, Work in Progress, URL:
http://qbone.internet2.edu/bb/bboutline2.html
[6] J. Manner, X. Fu, Analysis of Existing Quality of Service Signaling
Protocols, draft-ietf-nsis-signalling-analysis-01.txt, Internet draft,
work in progress, February 2003.
[7] Next Steps in Signaling (NSIS WG), URL: http://www.ietf.org/html.
charters/nsis-charter.html
[8] S. Salsano, V. Genova, F. Ricciato, M. Winter, B.F. Koch, L.
Dimopoulou, E. Nikolouzou, P. Sampatakos, I.S. Venieris, G. Eichler,
Inter-domain QoS Signaling: The BGRP Plus Architecture, Internet
Draft, May 2002.
[9] P. Pan, E. Hahne, H. Schulzrinne, BGRP: sink-tree-based aggregation
for inter-domain reservations, Journal of Communications and
Networks 2 (2) (2000) 157–167. URL: http://www.cs.columbia.edu/
~pingpan/papers/bgrp.pdf
[10] Y. Rekhter, T. Li, A border gateway protocol 4 (BGP-4), RFC 1771,
IETF, March 1995.
[11] P. Traina, BGP-4 Protocol Analysis, RFC 1774, IETF, March 1995.
[12] M. Brunner, Requirements for QoS Signaling Protocols, IETF, draft-
ietf-nsis-req-07.txt, March 2003.
[13] Y. Rekhter, C. Topolcic, Exchanging Routing Information Across
Provider Boundaries in the CIDR Environment, RFC1520, IETF,
September 1993.
[14] B. Halabi, Internet Routing Architectures, Cisco Systems, 1997.
[15] R. Guerin, A. Orda, Networks with advance reservations: the routing
perspective, Proceedings of IEEE INFOCOM, April 2000.
[16] J.T. Virtamo, A model of reservation systems, IEEE Transactions on
Communications 1 (1992) 109–118.
[17] A. Broido, E. Nemeth, K. Claffy, Internet Expansion, Refinement and
Churn, CAIDA, February 2002, available at http://www.caida.org/
outreach/papers/2002/EGR/
[18] NLANR, Nlanr as path lengths, Web site at http://moat.nlanr.net/
ASPL/
[19] Aquila project, URL: http://www.ist-aquila.org
P. Sampatakos et al. / Computer Communications 27 (2004) 423–433 433
