We have implemented BGP-AM in the ns-2 network
simulator [8]. Simulation results indicate that BGP-AM
leads to a shorter convergence time, with a comparable
number of update messages as the current BGP
implementation [1].
The paper is organized as follows. BGP dynamic
behavior is described in Section 2. In Sections 3 and 4, we
describe reusable MRAI timers and the adaptive MRAI
algorithm, respectively. Simulation results for two
network topologies are given in Section 5. We conclude
with Section 6.
2. Dynamic behavior of BGP
BGP speakers (routers) [1] exchange a large number
of update messages due to persistent changes of the
Internet topology. Each BGP speaker adds new and
deletes unfeasible routes to destinations. Therefore, BGP
is characterized by continuous changes of routing tables.
During the BGP convergence process, a BGP speaker
may exchange messages with its peers over several
iterations until it finds the best route (converges). The end
of the BGP convergence process for a single destination is
defined as the instant when all BGP speakers in a network
stop generating update messages for the specific
destination. The BGP convergence time for a single
destination is defined as the time elapsed between the
instant when the first update message containing a change
of the destination reachability is sent and the instant when
all corresponding update messages are received [2]. To
minimize the number of update messages and adequately
react to changes in the Internet topology, BGP
implements rate limiting by using MRAI timers. The
default duration of an MRAI round is 30 s [1] and it is
controlled by MRAI timers. However, manufacturers may
use other values for the duration of MRAI round. For
example, Juniper’s default configuration sets MRAI to 0 s
[6], [9].
The independent rate limiting of various destinations
may be achieved by using per-destination MRAI timers,
where one per-destination MRAI timer is associated with
one destination in a routing table. The routing table in a
core Internet router contains over 100,000 destinations
[10] and the implementation of such a large number of
timers is not feasible. Rather than using per-destination
MRAI timers, RFC 1771 [1] proposes implementing per-
peer timers. Each per-peer MRAI timer is associated with
one peer. The timer is set when a route advertisement is
sent to the corresponding peer, regardless of its
destination. An advantage of per-peer timers is that their
number is equal to the maximum number (several
hundred) of peers corresponding to one BGP speaker. A
disadvantage is that they limit advertisements of all
destinations sent to the peer (even those that are
advertised for the first time).
2.1 Uniform BGP processing delay
BGP processing delay is the delay imposed on an
update message in a BGP speaker. It is an important
parameter in the analysis of the BGP dynamic behavior. It
includes the queuing time of a message and the time
needed for BGP to process the received message. The
uniform BGP processing delay [2] has been widely used
in studies of the BGP convergence time [10]–[12]. It has
also been implemented in SSFNET [13]. It assumes that a
BGP speaker processes each update message
independently. (Updates are queued and processed
sequentially.) The processing delay of each message is
estimated using a uniformly distributed random variable
from the interval [p
min
, p
max
]. Commonly used values are
p
min
= 0.01 s and p
max
= 1 s [2]. The average processing
delay t
BGPprocess
(p) for a group of N queued updates is:
2
)-(
)(
minmax
pp
Npt
BGPprocess
×=
. (1)
Eq. (1) indicates that the average processing delay
depends linearly on the number of update messages.
Measurements have shown that this number may exceed
100 messages per second in the core Internet routers [10].
This suggests that using the uniform delay with p
min
=
0.01 s and p
max
= 1 s may not be appropriate in the case of
extensive exchange of update messages. Even for a
moderate number of messages (~20), using the uniform
delay leads to unrealistically high values for the average
BGP processing delay (~10 s).
Recent measurements on Cisco routers indicated that
the average BGP processing delay is much shorter than
predicted by the uniform delay [6]. They revealed that
BGP speakers process groups of update messages in
constant 200 ms processing cycles. When a BGP speaker
operates below its maximum CPU utilization, it may
process most messages that it receives at the end of a 200
ms cycle. The average BGP processing delay is between
101 and 110 ms. Over 95% messages are processed
within 210 ms. Nevertheless, in the case of high traffic
loads, a BGP speaker cannot process all received
messages in one 200 ms cycle and the maximum BGP
processing delay may reach several seconds.
Measurements of router CPU utilization [7] have
indicated that in over 99% cases, the core Internet routers
operate under 50% of their capacity. Processing BGP
messages usually has a higher scheduling priority than
other processes in a BGP speaker [6]. Hence, most of the
time, routers process all update messages within one 200
ms processing cycle, which is significantly shorter than
the value estimated by the uniform delay (~10 s).
2.2 Empirical BGP processing delay
We propose to use an empirical value for the BGP
136
Authorized licensed use limited to: IEEE Xplore. Downloaded on March 30, 2009 at 07:53 from IEEE Xplore. Restrictions apply.