CEDAR: a Core-Extraction Distributed Ad hoc
Routing algorithm
Prasun Sinha Raghupathy Sivakumar Vaduvur Bharghavan
University of Illinois at Urbana-Champaign
Email: {prasun, sivakumr, bharghav} @timely. crhc.uiuc.edu
Absiract—CEDARisanalgorithm for QoS routing in ad hoc network en-
vironments. It has three key components: (a) the establishment and main-
tenance of a setf-organizing routing infrastructure catted the
core for per-
forming route computations, (b) the propagation of the link-state of stable
high-bandwidth links in the core through
increase/decrease waves, and (c)a
QoS ra,ute computation algorithm that is exeeuted at the core nodes using
onty locally available state.
Our preliminary performance evaluation shows that CEDAR is a robust
and adaptive QoS routing algorithm that reacts effectively to the dynamics
of the network white stitl approximating link-state performance for stable
networks.
Keywords—Ad hoc routing, QoS routing
I. INTRODUCTION
An ad hoc network is a dynamic multi-hop wireless network
that is established by a group of mobile hosts on a shared wire-
less channel by virtue of their proximity to each other. Ad hoc
networks find applicability in military environments, wherein a
platoon of soldiers or a fleet of ships may establish an ad hoc net-
work in the region of their deployment. Military network envi-
ronments typically require quality of service for their mission-
critical applications. Hence, the focus of this paper is to provide
quality of service routing in ad hoc networks.
Ad hoc networks are dynamic in nature, and transmissions
are susceptible to fades, interference, and collisions from hid-
den/exposed stations. These characteristics make it a challeng-
ing task to design a QoS routing algorithm for ad hoc networks.
Following are the main design goals for such an algorithm:
1. The algorithm should be highly robust and should degrade
gracefully with increasing mobility.
2. Route computation should not require maintenance of
global information.
3. The computed route should be highly likely to sustain the
requested bandwidth for the flow.
4. ‘The route computation should involve as few hosts as pos-
sible to reduce the state management overhead involved in
(>0S routing.
5. Hosts should have quick access to routes when connections
need to be established.
We propose CEDAR as a QoS routing algorithm, which
achieves the above design goals for small to medium size ad hoc
networks consisting of tens to hundreds of nodes. The following
is a brief description of the three key components of CEDAR.
.
Core extraction: A set of hosts is distributedly and dynam-
ically elected to form the
core of the network by approx-
imating a minimum dominating set of the ad hoc network
using only local computation and local state. Each
core host
maintains the local topology of the hosts in its domain, and
alSO performs route computation on behalf of these hosts.
●
●
Link state propagation: QoS routing in CEDAR is achieved
by propagating the bandwidth availability information of
stable links in the
core graph. The basic idea is that the in-
formation about stable high-bandwidth links can be made
known to nodes far away in the network, while information
about dynamic links or low bandwidth links should remain
local. Slow-moving
increase waves and fast moving de-
crease waves
which denote corresponding changes in avail-
able bandwidths on links, are used to propagate non-local
information over core nodes.
Route computation: Route computation first establishes a
core path from the dominator (See Section II) of the source
to that of the destination. The co?e path provides the direc-
tionality of the route from the source to the destination. Us-
ing this directional information, CEDAR iteratively tries to
find a partial route from the source to the domain of the fur-
thest possible node in the
core path (which then becomes
the source for the next iteration) satisfying the requested
bandwidth, using only local information. Effectively, the
computed route is a shortest-widestl furthest path using the
core path as the guideline.
The rest of this paper is organized as follows. Section II de-
scribes the network model and terminology used in the paper.
Section III describes the computation and dynamic management
of the
core of the network, Section IV describes link state propa-
gation through the
core using increase and decrease waves. Sec-
tion V describes the route computation algorithm of CEDAR,
and puts together the algorithms described in the previous sec-
tions. Section VI analyzes the performance of CEDAR through
simulations and Section VII summarizes the paper.
II. NETWORK MODEL AND TERMINOLOGY
We assume that all the hosts communicate on the same shared
wireless channel. Neighborhood is assumed to be a commutative
property (i.e. if
A canhear l?, then 13 can hear A). Because of
the local nature of transmissions, hidden and exposed stations2
abound in an ad hoc network. We assume the use of a CSMAICA
like algorithm such as MACAW [1] for reliable unicast commu-
nication, and for solving the problem of hiddeu/exposed stations.
Essentially, data transmission is preceded by a control packet
handoff, and the sequence of packets exchanged in a commu-
nication is the following: RTS (from sender to receiver) - CTS
(from receiver to sender) - Data (from sender to receiver) - ACK
1A
shortest widest path is the maximum baudwidth path. If there are several
such paths, it is the one with the least number of hops.
2A bidden station is a host that is within the range of the receiver but not the
transmitter, while an exposed station is within the range of the transmitter but uot
the receiver.
0-7803-5420-6/99/$10.00 (c) 1999 IEEE
(from receiver to sender). Local data broadcasts are not assumed
to be reliable.
We assume that each host can estimate the available band-
width using some link-level mechanisms. We also assume a
close coordination between the MAC and routing layers is as-
sumed. In particular, reception of RTS and CTS control mes-
sages at the MAC layer is used to improve the behavior of the
routing layer, as explained in Section III.
We represent the ad hoc network by means of an undirected
graph G =
(V, E), where V is the set of nodes in the graph (hosts
in the network), and E is the set of edges in the graph (links in
the network). The ith open
neighborhood, IVi (z) of node ~ is the
set of nodes whose distance from x is not greater than i, except
node r itself. The ith
closed neighborhood Ni [x] of node x is
N(i) IJ
{X}.
A clominating set S c V is a set such that every node in V
is either in S or is a neighbor of a node in S, A dominating set
with minimum cardinality is called a minimum dominating set
(MDS). Also, every node not in S chooses one of its neighbors
who is in S as its
dominator. A virtual link [u, v] between two
nodes in the dominating set S is a path in G from u to v. We use
the term
tunnel interchangeably with virtual link in our discus-
sions.
Given an MDS
VC of graph G, we define a core of the graph
C =
(VC,,?3C), wherellc = {[u, v] I u c Vc, v e VC, U E
N3 (v )}.
Thus, the core graph consists of the MDS nodes VC,
and a set of virtual links between every two nodes in Vc that are
within a distance 3 of each other in G. Two nodes u and v which
have a virtual link [u, v] in the
core are said to be nearby nodes.
Thus, from the definition of the
core, if G is connected, then a
core C of G must also be connected (via virtual links).
III. CEDAR ARCHITECTURE AND THE CORE
The QoS routing architecture in CEDAR has three key com-
ponents: (a) the establishment of the
core in the ad hoc network
to manage topology information and perform route computation,
(b) the propagation of the link-state of stable high bandwidth
links in the
core graph through increase and decrease waves, and
(c) the route computation algorithm at
core nodes using only lo-
cal state.
In the rest of this section, we first describe the motivation for
choosing a core-based routing architecture, then describe a low
overhead mechanism to generate and maintain the
core of the
netwc,rk, and finally describe an efficient mechanism to accom-
plish a
‘core broadcast’ using unicast transmissions.
A. Rationale for a Core-based Architecture in CEDAR
Many contemporary proposals for ad hoc networking require
every node in the ad hoc network to perform route computations
and topology management [2], [3], [4]. However, CEDAR uses a
core-based infrastructure for QoS routing due to two compelling
reasons.
1. QoS route computation involves maintaining local and
some non-local link-state, and monitoring and reacting to
some topology changes. Clearly, it is beneficial to have as
few nodes in the network performing state management and
route computation as possible.
2. Local broadcasts are highly unreliable in ad hoc networks
due to the abundance of hidden and exposed stations.
Topology information propagation [4] and route probes [2],
[3] are inevitable in order to establish routes and will, of ne-
cessity, need to be broadcast if every node performs route
computation. While the adverse effects of unreliable broad-
casts are typically not considered in most of the related
work on ad hoc routing, we have observed that flooding in
ad hoc networks is highly lossy [5]. On the other hand, if
only a
core subset of nodes in the ad hoc network perform
route computations, it is possible to setup reliable unicast
channels between nearby
core nodes and accomplish both
the topology updates and route probes much more effec-
tively.
The issues with having only a
core subset of nodes performing
route computations are threefold. First, nodes in the ad hoc net-
work that do not perform route computation must have easy ac-
cess to a nearby
core node so that they can quickly request routes
to be set up. Second, the establishment of the
core must be a
purely local computation. In particular, no
core node must need
to know the topology of the entire
core graph. Third, a change
in the network topology may cause a recomputation of the
core
graph. Recomputation of the core graph must only occur in the
locality of the topology change, and must not involve a global re-
computation of the
core graph. On the other hand, the locally re-
computed
core graph must still only comprise of a small number
of
core nodes - otherwise the benefit of restricting route compu-
tation to a small
core graph is lost. Our core computation algo-
rithm satisfies the above requirements.
B. Generation and Maintenance of the Core in CEDAR
Ideally, the core comprises of the nodes in a minimum domi-
nating set
Vc of the ad hoc network G = (V, E). However, we
are using a robust and simple constant time algorithm which re-
quires only local computations and generates good approxima-
tions for the MDS in the average case.
Consider a node u, with first open neighborhood N1 (u), de-
gree
d(u) = IN1 (u) 1, dominator dorn(u), and effective degree
d“ (u), where
d* (u) is the number of its neighbors who have cho-
sen v, as their dominator. The
core computation algorithm which
is performed periodically, works as follows at each node u.
1. u broadcasts a beacon which contains the
following information pertaining to the
core computation:
<
U, d*(u), d(u), dom(u) >.
2. u sets
don(u) +-- v, where v is the node in Nl [u] with the
largest value for <
d*(v), d(v) >, in lexicographic order.
Note that u may choose itself as the dominator.
3.
u then sends v a unicast message including the following
information: < u, {(w,
dom(w)) [ VW c N1 (u)} >. v
then increments d*(v).
4. If d* (u) >0, then u joins the core.
Essentially, each node that needs to find a dominator selects the
highest degree node with the maximum effective degree in its
first closed neighborhood. Ties are broken by node id.
When a node u joins the
core, it issues a
‘piggybacked broadcast’ in N3 (u). A piggybacked broad-
cast is accomplished as follows. In its beacon, u transmits
a message: < u.
DOiW. 3. vath.traversed = null >.
0-7803-5420-6/99/$10.00 (c) 1999 IEEE
When node w hears a beacon that contains a message <
u, DOM, i,path-traversed >, it piggybacks the message <
u,
DOM, i – 1, path_traversed + w > in its own beacon if
i – 1 > 0. Thus, the piggybacked broadcast of a core node ad-
vertises its presence in its third neighborhood. This guarantees
that each
core node identifies its nearby core nodes, and can set
up virtual links to these nodes using the
path-traversed field
in the broadcast messages. The state that is contained in a
core
node u is the following: its nearby core nodes (i.e. the core nodes
in lV3 (u)); N*(u), the nodes that it dominates; for each node
v c N“(u), < Vw E iV1(v), < w,
dorn(w) >>. Thus each
core node has enough local topology information to reach the
domain of its nearby nodes and set up virtual links. However,
no core node has knowledge of the
core graph. In particular, no
non-local state needs to be maintained by
core nodes for the con-
struction or maintenance of the
core. Note from steps 2 and 4 that
over a period of time, the
core graph prunes itself because nodes
have a propensity to choose their
core neighbor with the highest
effect ive degree as their dominator.
Maintaining the
core in the presence of network dynamics is
very simple. Consider that due to mobility, a node loses con-
nectiv ity with its dominator. After listening to beacons from its
neighbors, the node either finds a
core neighbor which it now
nominates as its dominator, or nominates one of its neighbors to
join the
core, or itself joins the core.
C. Core Broadcast and its Application to CEDAR
As with most existing ad hoc networks, CEDAR requires the
broadcast of route probes to discover the location of a destina-
tion node, and the broadcast of some topology information (in
the form of increase/decrease waves). While most current algo-
rithms assume that flooding in ad hoc networks works reason-
ably well, our experience has shown otherwise. In particular, we
have observed that flooding probes, which causes repeated lo-
cal broadcasts, is highly unreliable because of the abundance of
hidden and exposed stations. Thus, we provide a mechanism for
‘core broadcast’ based on reliable unicast (using RTS-CTS etc.),
Note that it is reasonable to assume a unicast based mechanism
to achieve broadcast in the
core, because each core node is ex-
pected to have few nearby
core nodes. Besides, our core broad-
cast mechanism ensures that each
core node does, not transmit a
broadcast packet to every nearby
core node. CEDAR uses a close
coordination between the medium access layer and the routing
layer in order to achieve efficient
core broadcast.
Recall that a virtual link is a unicast path of length 1, 2, or
3. Recall also, that CSMA/CA protocols use a RTS-CTS-Data-
ACK handshake sequence to achieve reliable unicast packet
transmission.
Our goal is to use the MAC state in order to
achieve efficient
core broadcast using O (IV [) messages, where
[Vl is the number of nodes in the network.
In (order to achieve efficient
core broadcast, we assume that
each node temporarily caches every RTS and CTS packet that
it hears on the channel for
core broadcast packets only. Each
core broadcast message M that is transmitted to a core node i
has the unique tag <
M, i >. This tag is put in the RTS and
CTS packets of the
core broadcast packet, and is cached for a
short period of time by any node that receives (or overhears)
these packets on the channel. Consider that a
core node u has
heard a CTS(<
M, w >) on the channel. Then, it estimates that
its nearby node v has received
M, and does not forward M to
node v. Now suppose that
u and u are a distance 2 apart, and
the virtual channel
[u, v] passes through a node w, Since w is a
neighbor of v, w hears CTS(<
M, v >). Thus, when u sends a
RTS(<
M, v >) to w, w sends back a NACK back to u. If u and
v are a distance 3 apart, using the same argument we will have
atmost one extra message. Essentially, the idea is to monitor the
RTS and CTS packets in the channel in order to discover when
the intended receiver of a
core broadcast packet has already re-
ceived the packet from another node, and suppress the duplicate
transmission of this packet.
Core broadcast with node
1 as source
A
111610
I
8
Core broadcast with node
3 as source
Ad hcc Network Topology
Fig. 1. Example of a core broadcast. Nodes in black me core nodes. Sotid lines
denote links in the ad hoc network. Dotted pipes denote virtual tinks in the
core graph.
In the ad hoc network shown in Figure 1, when node 1 is the
source of the core broadcast, 10 would not be sending a message
to 11 as it would have heard a CTS from 11, when 11 was re-
ceiving the message from 3. Similarly, 8 would not be sending
on the tunnel to 10, as 9 would have heard the CTS from 10, and
hence, would send a NACK when 8 sends an RTS to 9. Also,
on the tunnel from 6 to 3, the message would be sent to 5, but 5
would not be able to forward it any further because of 4 having
heard CTS from 3, and hence, 5 receiving NACK from 4. Thus,
the example illustrates that a duplicate message can be avoided
on tunnels of length 1 and 2, but a duplicate message will travel
one extra hop for tunnels of length 3.
Note that
core broadcast has the following features:
1. The
core nodes do not explicitly maintain a source-based
tree. However, the
core broadcast dynamically (and implic-
itly) establishes a source-based tree, which is typically a
breadth-first search tree for the source of the
core broadcast.
2. The number of messages is
O(\Vc 1) in the average case. In
particular, the only case we transmit extra data messages is
when two nearby
core nodes are a distance 3 apart.
3. Since the trees are not explicitly maintained, different mes-
sages may establish different trees. Likewise, changes in
the network topology do not require any recomputation.
However, the coordination of the MAC layer and the rout-
ing layer ensures that the
core broadcast establishes a tree,
and that a
core node typically does not receive duplicates
for a
core broadcast.
While our approach for the
core broadcast is very low overhead
and adapts easily to topology changes, the RTS and CTS packets
corresponding to a
core broadcast need to be cached for some
time after their reception.
0-7803-5420-6/99/$10.00 (c) 1999 IEEE
Core broadcast finds applicability in two key aspects of A. Increase and Decrease Waves
CEDAR: discovery of the core path, and propagation of in-
creaseldecrease waves.
IV. QoS
STATE PROPAGATION IN CEDAR
Section III described the
core routing infrastructure of
CEDAR. Since each
core node uses only the locally cached state
to compute the shortest-widest furthest path along the
core path
in the route computation phase, we now turn our attention to the
nature of state that is stored in each
core node. Atone extreme is
the minimalist approach of only storing local topology informa-
tion at each
core node, This approach results in a poor routing
algorithm (i.e. the routing algorithm may fail to compute an ad-
missible route even if such routes exist in the ad hoc network) but
has a very low overhead for dynamic networks. At the other ex-
treme is the maximalist approach of storing the entire link state of
the ad hoc network at each
core node. This approach computes
optimal routes but incurs a high state management overhead for
dynamic networks, and potentially computes stale routes based
on ou~-of-date cached state when the network dynamics is high.
The problem with having only local state is that
core nodes
are unable to compute good routes in the absence of link-state
information about stable high-bandwidth remote links, while the
problem of having global state is that it is useless to maintain the
link state corresponding to low-bandwidth and highly dynamic
links that are far away because the cached state is likely to be
stale anyway. Fundamentally, each
core node needs to have the
up-to-date state about its local topology, and also the link-state
corresponding to relatively stable high-bandwidth links further
away. Providing for such a link-state propagation mechanism
ensures that CEDAR approaches the minimalist local state algo-
rithm in highly dynamic networks, and approaches the maximal-
ist link-state algorithm in highly stable networks. We achieve the
goal of having stability and bandwidth based link-state propaga-
tion using increase and decrease waves, as described in this sec-
tion.
The basic idea of having an increaseldecrease wave approach
for updating link-state is the following. There are two types of
waves: a slow-moving increase wave that denotes an increase of
bandwidth on a link, and a fast-moving
decrease wave that de-
notes a decrease of bandwidth on a link. For unstable links that
come up and go down frequently, the fast moving decrease wave
quickly overtakes and kills the slower moving increase wave,
thus ensuring that the link-state corresponding to dynamic links
is local. For stable links, the increase wave gradually propagates
through the
core. Each increase wave also has a maximum dis-
tance it is allowed to propagate. Low bandwidth increase waves
are all owed only to travel a short distance, while high bandwidth
increase waves are allowed to travel far into the network. Essen-
tially, the goal is to propagate only stable high-bandwidth link-
state throughout the
core, and keep the low-bandwidth and un-
stable link-state local.
We first describe the mechanics of the increase and decrease
waves, and then answer the three key questions pertaining to
these waves:
when should a wave be generated, howfast should
a wave propagate, and
howfar should a wave propagate.
For every link 1 = (a,
b), the nodes a and b are responsible
for monitoring the available bandwidth on
1, and for notifying
the respective dominators for initiating the increase and decrease
waves, when the bandwidth changes by some threshold value.
These waves are then propagated by the dominators
(core nodes)
to all other
core nodes via core broadcasts. Each core node has
two queues: the
ito-queue that contains the pending core broad-
cast messages for increase waves, and the
alto-queue that con-
tains the pending
core broadcast messages for decrease waves.
For each link
1 about which a core node caches link-state, the
core node contains the cached available bandwidth bau (1).
The following is the sequence of actions for an increase wave.
1. When a new link 1 = (a, b) comes up, or when the avail-
able bandwidth
b(a, b) increases beyond a threshold value,
then the two end-points of 1inform their dominators for ini-
tiating a
core broadcast for an increase wave:
ito(< a,
b, dorrt(a), dorn(b), b(a, b), Ml(b) >)
where ito (increase to) denotes the type of the wave, (a, b)
identifies the link, dorn(a) denotes the dominator of a,
don(b) denotes the dominator of b, b(a, b) denotes the
available bandwidth on the link, and
ttl (b) is a ‘time-to-
live’ field that denotes the maximum distance to which this
wave can be propagated as an increase wave. The
ids of the
dominators of the link end-points are required by the rout-
ing algorithm.
ttl (b) is an increasing function of the avail-
able bandwidth, as described in Section IV-B.
2. When a
core node u receives an ito wave
ito(a,
b, dorn(a), don(b), b(a, b), ttl),
(a)
(b)
(c)
(d)
if u has no state cached for (a,
b)
and (b(a, b) = O),
the wave is killed.
else if u has no state cached for (a,
b) and (b(a, b) > O),
bo. (a, b) +- b(a, b)
if (tti > O), then
add
ito(a, b, dom(a), don(b), b(a, b), ttl – 1)
to the ito-queue.
else if u has cached state for (a,
b) and (ttl > O),
bav(a, b) - b(a, b)
delete any pending ito/dto message for (a, b)
from the ito-queue and alto-queue.
if
(baV(a, b) < b(a, b))
add ito(a, b, dorn(a), dons(b), b(a, b), ttl – 1)
to the ito-queue.
else if
(b@V(a, b) > b(a, b)),
add dto(a, b, don(a), dorn(b), b(a, b), ttl – 1)
to the alto-queue.
else if u has cached state for (a,
b) and (ttl = O),
ba. (a, b) + b(a, b)
delete any pending ito/dto message for (a, b)
from the ito-queue and alto-queue.
add
dto(a, b, dowt(a), dorn(b), O, cm) to the alto-queue.
3. The ito-queue is flushed periodically, depending on the
speed of propagation of the increase wave.
The following is the sequence of actions for a
decrease wave.
1. When a link 1 = (a, b) goes down, or when the
available bandwidth
b(a, b) decreases beyond a threshold
value, then the two end-points of 1 inform their domina-
0-7803-5420-6/99/$10.00 (c) 1999 IEEE
tors for initiating a core broadcast for a decrease wave:
dto(a, b, dom(a), don(b), b(a, b), ttl(b)), where dto (de-
crease to) denotes the type of the wave, and the other pa-
rameters are as defined before.
2. When a
core node u receives a dto wave
dto(a,
b, dorn(a), dorn(b), b(a, b), ttl), it is processed in
the same way as the
ito wave is processed in 2 above.
3. ‘The alto-queue is flushed whenever there are packets in the
cpeue.
There are several interesting points in the above algorithm.
First, the way that the ito-queue and the alto-queue are flushed
ensures that the decrease waves propagate much faster than the
increa!se waves and suppress state propagation for unstable links.
Second, waves are converted between
ito and dto on-the-fly,
depending on whether the cached value for the available band-
width is lesser than the new update (ito wave generated) or not
(alto wave generated). Third, after a distance of ttl (which de-
pends on the current available bandwidth of the link), the
dto(<
a, b, dom(a), dom(b), O, co >) message ensures that all other
core nodes which had state cached for this link now destroy that
state. However, the
dto(< a, b, dorn(a), donz(b), O, m >) wave
does not propagate throughout the network - it is suppressed as
soon as it hits the
core nodes which do not have link state for
(a,
b) cached (point 2(a) in decrease wave propagation). As we
have noted before, the increase/decrease waves use the efficient
core broadcast mechanism for propagation.
B. Issues with increaseldecrease waves:
There are three key questions pertaining to the propagation of
increase/decrease waves that need to be answered. While finding
answers to these questions is still part of ongoing research, we
present below some preliminary answers.
● When should a IncreaselDecrease Wave be Generated? A
wave should only be generated when the available band-
width has changed by a threshold value since the last
wave was generated. A simple approach would be to
make the threshold a constant system parameter. Another
method suggested by [6] uses logarithmic update, which
c~oesnot wastefully generate increase/decrease waves when
the change in link capacity is unlikely to alter the probabil-
i~y of computing admissible routes.
● How Far does a IncreaselDecrease Wave Propagate?
our goal is to propagate information about stable high-
bandwidth links throughout the network and localize the
state of the low-bandwidth links. In other words, the max-
imum distance that an
increase wave can travel (i.e. the
time-to-live field) is an increasing function of the available
bandwidth of the link.
● How Fast does a Increase\Decrease Wave Propagate?
An increase wave waits for a fixed timeout period (e.g.,
twice the expected inter-arrival time between the genera-
tion of two successive waves for any link) at each node be-
fore being forwarded whereas a decrease wave is imme-
diately forwarded to its neighbors. Thus decrease waves
move much faster and can kill increase waves for unstable
links. The wait-before-forwarding for
increase waves also
naturally leads to the implicit establishment of a source-
based breadth-first-search tree for the
core broadcast de-
scribed in Section III.
V. QoS
ROUTING IN CEDAR
The QoS route computation in CEDAR consists of three key
components: (a) discovery of the location of the destination and
establishment of the
core path to the destination, (b) establish-
ment of a short stable admissible QoS route from the source to
the destination using the
core path as a directional guideline, and
(c) dynamic re-establishment of routes for ongoing connections
upon link failures and topology changes in the ad hoc network.
Briefly, QoS route computation in CEDAR is an on-demand
routing algorithm which proceeds as follows: when a source
node s seeks to establish a connection to a destination node
d,
s
provides its dominator node dom(s) with a < s, d, b > triple,
where
b is the required bandwidth for the connection. If dom(s)
can compute an admissible available route to
d using its local
state, it responds to s immediately. Otherwise, if dom(s) al-
ready has the dominator of
d cached and has a core path estab-
lished to
dom(d), it proceeds with the QoS route establishment
phase. If
dorn(s) does not know the location of d, it first dis-
covers
dom(d), simultaneously establishes a core path to d, and
then initiates the route computation phase. A
core path froms
to
d results in a path in the core graph from dom(s) to don(d).
dorn(s)
then tries to find the shortest-widest furthest admissible
path along the
core path, i.e. dom(s) uses its local state to find
the shortest-widest admissible path to a node
t in the domain of
the furthest possible
core node dom(t) in the core path. Once the
path froms tot is established,
dom(t) then uses its local state to
find the shortest-widest furthest admissible path to d along the
core path, and so on. Eventually, either an admissible route to
d is established, or the algorithm reports a failure to find an ad-
missible path. As we have already discussed in previous sec-
tions, the knowledge of remote stable high-bandwidth links at
each
core node significantly improves the probability of finding
an admissible path so long as such a path exists in the network.
In the following subsections, we describe the three key com-
ponents of QoS routing in CEDAR.
A. Establishment of the Core Path
The establishment of a core path takes place whens requests
dom(s) to setup a route to
d (say with required bandwidth b),
and dom(s) does not know the identity of dom (d) or does not
have a
core path to dom(d), Establishment of a core path con-
sists of the following steps.
1.
dom(s) initiates a core broadcast to set up a core path with
the following message:
<
core.path-req, dom(s), d, b, P = null >.
2.
When a core node u receives the core path request message
<
core.path.req, dom(s), d, b, P >, it sets P - PU {u},
and forwards the message to each of its nearby
core nodes
(according to the
core broadcast algorithm)
3. When
dom(t) receives the core path request message <
core.path.req,
dorn(s), d, b, P >, it sends back a source
routed unicast core-path.ack message to
dom(s) along the
inverse path recorded in
P. The response message also con-
tains
P, the core path from dom(s) to dom(d).
Upon reception of the core_path_ack message from dom(d),
dom(s)
completes the core path establishment phase and enters
0-7803-5420-6/99/$10.00 (c) 1999 IEEE