Computer Science Technical Report Archive

USC Computer Science Technical Reports, no. 603 (1995)

(USC DC Other)

USC Computer Science Technical Reports, no. 603 (1995)

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content A Route Serv er Arc hitecture for In terDomain Routing
R amesh Govindan
Cengiz A laettino glu
Kannan V ar adhan
Deb or ah Estrin
USCInformation Sciences Institute
Marina del Rey CA Abstract
In ternet transmission and switc hing facilities are partitioned in to dieren t administrativ e domainsT o ef
fect routing b et w een domains domain b or der r outers establish pairwise p eering sessions and exc hange routing
information at exchange p oints When a large n um b er of b order routers attachat anexc hange p oin t signi
can t op erational co ordination is necessary to main tain routing consistency An alternativ e arrangemen t in whic h
eac h b order router at an exc hange p oin t p eers only with a R oute Server reduces the necessary co ordination and
pro vides other signican t b enets
F rom a settheoretic c haracterization of b order router b eha vior w e deriv e a settheoretic expression that
completely and succinctly c haracterizes Route Serv er functionali t yP erformance measuremen ts from our Route
Serv er implemen tation rev eal that the storage requiremen ts of Route Serv ers can b e m uc h larger than that of a
t ypical b order router W e discuss a v arietyof tec hniques that can in some instances reduce Route Serv er storage
requiremen ts b y a factor of v e or more
In tro duction
In ternet resources suc h as hosts routers and transmission facilities are partitioned in to dieren t administrativ e
domains A campus or in ternal corp orate net w ork is an example of a domain Data exc hange b et w een campus or
corp orate domains is facilitated b y pr ovider domains these domains pro vide as a service transmission and switc hing
facilities for data exc hange b et w een their customers domains F urther b yin terconnecting with other pro viders a
pro vider ma y supp ort data exc hange b et w een its customers and those of other pro viders The routing requiremen ts for
data exc hange b et w een domains can b e quite dieren t from the routing requiremen ts for data exc hange in v olving the
resources of a single domain In the curren tIn ternet routing infrastructure the former is supp orted b y interdomain
r outing and the latter b y intr adomain r outing Curren tlyin terdomain routing is ac hiev ed using the In terDomain Routing Proto col IDRP
IDRP sup
p orts data exc hange b et w een dieren t domains but in a manner that do es not conict with domain autonom yand
heterogeneit y IDRP allo ws eac h domain to indep enden tly realize a wide v arietyof p olicies broadly suc h p olicies
either express a domains restrictions on access to its resources or its preferences among other domains resources
for dieren t classes of trac In IDRP domain b or der r outers BRs ma y indep enden tly restrict the propagation
of in terdomain routing information based on congured sele ction and exp ort criteriaT o exc hange in terdomain
routing information a domain BR rst establishes IDRP p e ering sessions t ypically transp ort connections with one
or more other domain BRs F rom these p e ers the BR receiv es a set of IDRP r outes an IDRP route indicates its
senders reac habilityto an addr ess pr ex a net w orkla y er address aggregate F or eac h distinct address prex the
BR c ho oses the route that b est matc hes its selection criteria Then to eac h of its p eers the BR propagates those
selected routes that b est matc h its exp ort criteria
This w ork w as supp orted b y the National Science F oundation under Co op erativ e Agreemen t NCR The w ork of K V aradhan
and D Estrin w as supp orted b y the National Science F oundation under con tract n um b er NCR Systems researc h at USC is
supp orted through NSF infrastructur e gran t a w ard n um ber CD A An y opinions ndings and conclusions or recommenda tio ns
expressed in this material are those of the authors and do not necessarily reect the views of the National Science F oundation
Actually the Border Gatew a y Proto col BGP v ersion is curren tly deplo y ed on the In ternet IDRP is a sup erset of BGP v ersion
IDRP deplo ymen t is exp ected in the near future

Domain BR
Peering sessions with
other BRs
IDRP peering session
Mesh peering at exchange point Physical topology at exchange point
Figure Mesh Pe ering This gure sho ws four domain BRs attachedtoanexc hange p oin t and the logical IDRP p eering
top ology Eac h BR p eers with ev ery other BR at the exc hange p oin t In addition a BR ma y also ha v e p eers not directly
attac hed to the exc hange p oin t eg other BRs in its o wn domain
Domain BR
Peering sessions with
other BRs
Route Server
Star peering at exchange point Physical topology at exchange point
Route Server
Figure Star Pe ering This gure sho ws four domain BRs attac hed to an exc hange p oin t and the logical IDRP p eering
top ology In star p eering a domain BR p eers only with a Route Serv er RS The latter p erforms route selection on b ehalf of
eachBR T o eect in terdomain routing pro viders in terconnect at exchange p oints T ypicallyan exc hange p ointis a
highsp eed subnet w ork to whic h pro vider BRs attac h A t the exc hange p oin t eac hpro vider BR usually establishes
an IDRP p eering session with ev ery other BR W e call suc h a p eering arrangementa mesh Figure Since eac h
BR at an exc hange p oin t is usually administered b y a dieren ten tit y signican t op erational co ordination maybe
necessary to main tain mesh p eering co ordination failures can result in incorrect global in terdomain routing The
mesh arrangemen t has sev eral other dra wbac ks as w ell Section These dra wbac ks are magnied at large exc hange p oin ts where tens of BRs are exp ected to attac h in the future
Examples of suc h exc hange p oin ts include MAEEast where nearly t w en typro viders already attac h the F ederal In
ternet Exc hanges and the London In ternet Exc hange These existing exc hange p oin ts ha v e b een established less from
basic arc hitectural considerations and more for economic reasons eg op erational cost amortization o v er pro viders
connected to the exc hange p oin t ho w ev er the National Science F oundations prop osed NSFNET and NREN pro
gram incorp orates exc hange p oin ts called Net w ork Access P oin ts or NAPs in to the routing infrastructure
design thereb ybesto wing them rstclass status With this dev elopmen t and with the exp ected proliferation of
In ternet pro viders the n um b er of attac hed BRs at exc hange p oin ts is lik ely to gro w signican tly A p eering arrangemen t that simplies op erational co ordination at these large exc hange p oin ts is desirable the star
Figure is one suc h arrangemen t In the star attac hed to an exc hange p oin t is a Route Serv er RS administered b y
an indep enden t third part y Domains presen t at the exc hange p oin t register their route selection and exp ort criteria
with this third part y Their BRs then establish IDRP p eering sessions with the RS The RS is congured with eac h
domains route selection and exp ort criteria The RSs route selection and propagation b eha vior is determined b y
the requiremen t that star p eering b e functionally equiv alen t to mesh p eering

This pap er rst describ es a settheoretic c haracterization of an IDRPsp eaking BRs route selection and route
propagation b eha vior Section Sp ecically b y represen ting the BRs inputs the routes that the BR receiv es from
its p eers as sets of tuples w esho w that its outputs the routes the BR propagates to its p eers can b e represen ted
as a series of w elldened set op erationseg set union set functional transformationson its inputs
In Section w e argue that the star and mesh arrangemen ts are functionally equiv alen t if the same routes are
selected b y eachBRin botharrangemen ts Starting from a formal statemen t of this condition w e mathematicall y
derive an expression for the routes that an RS m ust adv ertise to eac h BR in terms of the routes that it receiv es from
the BRs Section W ein terpret the deriv ed expression to describ e the proto col and route selection actions that
the RS m ust p erform
Av ersion of the Route Serv er has b een implemen ted and deplo y ed at the NSF NAPs W e describ e some p erfor
mance results from an initial Route Serv er implemen tation in Section These n um b ers indicate that the w orst case
route storage requiremen ts of an RS are comparable to the total route storage requiremen ts of its p eers Section describ es one tec hnique to reduce RS route storage requiremen ts In the star arrangemen t the RS represen ts a single
p oin t of failure for routing information exc hange Section discusses the use of m ultiple RSs at an exc hange p oin t for
increasing the reliabilit y of the star arrangemen t Multiple RSs ma y also b e used to reduce RS storage requiremen ts
Section also describ es t wotec hniques for this Finally Section describ es related w ork and Section presen ts our
conclusions
Settheoretic Characterization of IDRPsp eaking BRs
In Section w e briey describ ed ho w IDRP sp eaking BRs exc hange routing information and p erform route selection
In this section w e describ e that pro cess in greater detail cast it in settheoretic terms and nally arriv eataset theoretic expression for the BRs outputs in terms of its inputs
Informal Description of an IDRPsp eaking BR
Consider an IDRPsp eaking BR
a
whic h p eers with a n um b er of BRs at one or more exc hange p oin ts BR
a
ma y
also p eer with BRs in its o wn domain F rom eac h of its p eers BR
a
receiv es one or more IDRP routes Eac h IDRP
route con tains an addr ess pr ex An address prex A represen ts the top ological region of the In ternet in whichhosts
and routers net w orkla y er addresses ha v e A as a prex a route from BR
a
s p eer con taining prex A adv ertises that
p eers reac habilit y to some en tit y within or in the vicinit y of that top ological region Address prexes are usually
represen ted bya net w orkla y er address and a prex length
An IDRP route also con tains one or more attributesA ttributes con v ey information that maybe used bya
routes recipien ts for making pac k et forw arding or route selection decisions F or example the NEXTHOP attribute
con tains the net w orkla y er address that BR
a
m ust use to forw ard pac k ets destined for the address prex indicated
in the route usually the NEXTHOP con tains the net w orkla y er address of the routes sender Similarl y the v alue
of the RDPATH attribute is the list of iden tiers of domains tra v ersed b y the route the RDPATH is used byBRs to
a v oid routing lo ops When adv ertising a route BR
a
axes its domains iden tier all domains are assigned unique
iden tiers to the routes RDPATH W e divide in to four steps the pro cedure bywhic h an IDRPsp eaking BR
a
computes the routes that it adv ertises
to its p eers Figure Assigning Route Preferences F rom eac h of its p eers BR
a
receiv es at most one route p er address prex
F or
eac h of these routes BR
a
tests whether its domain iden tier is already presen t in the routes RDPATH if
the test succeeds the route is discarded Toeac h remaining route the BR assigns either a nonnegativ e
in teger pr efer enc e or The former indicates BR
a
s preference for that route among all routes adv ertising
reac habilit y to the same address prex the latter indicates that BR
a
will under no circumstances use the
route to reac h that address prex
Preference assignmen t decisions are based en tirely on congured selection criteria Selection criteria are
usually expressed in terms of the con ten ts of a routeeg the v alues of its attributes The statemen ts alw a ys
assign a preference of to routes heard from p eer BR
x
and alw a ys assign to routes originating from
This c haracteriza tio n is sligh tly inaccurate for IDRP IDRP denes a QoS attribute an IDRP sp eaking BR ma yadv ertise t w o dieren t
routes to the same address prex but with dieren t QoS v alues F or simplicit yw e ignore this distinction in most of the rest of the pap er
Section briey describ es ho w our settheoretic c haracteriza tionma y b e mo died to accommo date this

Assigning Route Preferences:
For each route received from a peer
based on configured selection criteria
Selecting Most Preferred Route:
For each distinct address prefix, pick
the route with the highest preference.
Deciding which routes to propagate:
To selected routes, apply universal export
criteria. Optionally modify exportable routes’
uniform attributes.
To each exportable route, apply peer-specific
export criteria and optionally set peer-specific
attributes before propagating route to peer.
from peers
received
Routes
Routes propagated to peers
Propagating Routes to Peers:
assign a non-negative preference
S
S
I
H
E
P
S
S
a
a,x
i
s
e
a
a
a
o
a,x
a,x
Figure BR Behavior This gure describ es the route selection and route propagation b eha vior of a IDRP sp eaking BR
This pictorial depiction motiv ates a settheoretic c haracterization of BR b eha vior
domain X are examples of selection criteria Selection criteria reect BR
a
s preferences for the use of other
domains resources
Selecting Most Preferred Route In this step BR
a
selects for eac h distinct address prex the route with the
highest preference If t w o or more routes ha v e the same highest preference IDRP sp ecies tiebreaking rules
based on the v alues of the routes attributes
Deciding Whic h Routes to Propagate BR
a
propagates some of the selected routes to eac h of its p eers based
on congured exp ort criteria Exp ort criteria express a domains restrictions on access to its resources These
criteria fall in to t w o categories universal and p e ersp e cic exp ort criteria Univ ersal exp ort criteria determine
the conditions under whic h a route ma y b e propagated to an y p eer the statemen t do not exp ort an y route
con taining address prex X to an y p eer is an example of a univ ersal exp ort criterion This step applies
univ ersal exp ort criteria to eac h selected route a route whic h fulls these criteria is deemed exp ortable All route attributes fall in to one of t w o categories one in whic heac h p eer to whic h the selected route is
propagated sees the same v alue for the attribute uniform attributes and another in whic h dieren t p eers
ma y see dieren tv alues of the attribute p e ersp e cic attributes for the same selected route In this step
BR
a
ma y assign v alues to uniform attributes The EXTINFO is an example of a uniform attribute it con tains
information ab out the origin of the route adv ertisemen t
Propagating Routes to P eers In this nal step BR
a
decides whic h of the exp ortable routes to actually prop
agate to eac h of its p eers T o do this it applies congured p eersp ecic exp ort criteria to eac h exp ortable
route The statemen t do not exp ort routes with domain Y in their RDPATH to p eer BR
x
is an example of a
p eersp ecic exp ort criterion for p eer BR
x
Only exp ortable routes that full p eersp ecic exp ort criteria for
p eer BR
x
are propagated to that p eer
Before propagating a route BR
a
ma y set the routes p eersp ecic attributes The v alue to assign to the p eer
sp ecic attribute is usually determined from congured information An example of a p eersp ecic attribute is
the MULTIEXITDISC If BR
a
has t w o or more exit p oin ts to a neigh b oring domain the v alue assigned to this
attribute can b e used to discriminate b et w een whic h of these exit p oin ts the neigh b oring domain m ust use to
forw ard pac k ets BR
a
ma y adv ertise dieren tv alues of this attribute to dieren t p eers

Settheoretic Characterization
In this section w e formally c haracterize the fourstep pro cedure describ ed in Section Sp ecically w e arriveata
settheoretic description of an IDRPsp eaking BRs output in terms of its inputs
W e denote an IDRP route b y the pair haddress prex route attributes i In general r oute attr ibutes themselv es
ma y b e describ ed as a sequence of hattribute v aluei pairs W e ignore this detail for notational simplicit y The inputs to the fourstep pro cedure of Section and the results of three of the four steps can b e represen ted
b y r oute sets see Figure A route set is a set of pairs denoting IDRP routes with at most one route pair for ev ery
distinct address prex F or an IDRPsp eaking BR
a
w e denote these route sets b y
i
S
ax
the inputs to BR
a
are the route sets that p eers BR
x
adv ertise to BR
a
s
S
a
is the route set selected b y BR
a
from among receiv ed routes that matc h its selection criteria
e
S
a
is the route set represen ting BR
a
s exp ortable routes
o
S
ax
BR
a
s outputs are the route sets that BR
a
propagates to eac h of its p eers BR
x
By our notation
i
S
ax
o
S
xa
The rst t w o steps in the fourstep pro cedure Section assign route preferences based on selection criteria
sometimes called imp ort criteria and select the highest preference route If w e denote the computation p erformed
in these t w o steps resp ectiv ely b y set functions I
a
and H Figure w e can write the follo wing equation for the
output of the second step
s
S
a
H x
I
a
i
S
ax
where for eac h route r in its argumen t set I
a
computes its result set using the follo wing pro cedure
T est whether r s RDPATH already con tains BR
a
s domain iden tier If the test fails r do es not ha v e a lo op ed
path v ector pro ceed to the next step
F rom the congured selection criteria assign a preference v alue to route r Insert this hroute preference i pair
in to the result set Pr efer enc e is either a nonnegativ ein teger or The function H tak es a set of hroute preference i pairs as its argumen t and computes its result set using the follo wing
pro cedure
P artition the input set in to subsets suc h that in eac h subset the address prexes of the route elemen ts of ev ery
hroute preference i pair are iden tical
F rom eac h subset formed in the previous step select the route asso ciated with the highest preference for
inclusion in the result set If all routes in the subset are assigned do not select an y route for inclusion in
the result set If more than one route in the subset has the highest preference break ties according to rules
sp ecied in
The third step in Section applies BR
a
s univ ersal exp ort criteria to compute its exp ortable routes If w e
represen t the computation p erformed in this step b y the function E
a
Figure w e can write the follo wing equation
for the output of the third step
e
S
a
E
a
s
S
a
F or eac h route r in its argumen t set E
a
computes its result set using the follo wing pro cedure
T est whether BR
a
s congured univ ersal exp ort criteria indicate that r can b e propagated to BR
a
s p eers If
the test succeeds pro ceed on to the next step
Set eac h uniform attribute in r appropriately Include the resulting route in the result set F or example this
step w ould set r s EXTINFO attribute if BR
a
w ere originating the adv ertisemen t for route r A more detailed
description of an IDRP sp eak ers handling of suc h attributes ma y b e found in
Finally the fourth step describ ed in Section applies BR
a
s peersp ecic exp ort criteria to compute BR
a
s
outputs If w e represen t the computation p erformed in this step b y the function P
ay
w e can write the follo wing
equation for BR
a
s output to p eer BR
y
o
S
ay
P
ay
e
S
a
P
ay
is a function that maps its argumen t set a set of routes in to another route set for eac h r in its argumen t set
P
ay
computes its result set using the follo wing pro cedure
T est whether BR
a
s congured p eersp ecic exp ort criteria indicate that r can b e propagated to BR
y
If the
test succeeds pro ceed to the next step
Set eac h p eersp ecic attribute in r appropriately Include the resulting route in the result set F or example
this step w ould either set a congured v alue for the MULTIEXITDISC attribute or pass unmo died the receiv ed
v alue whic hma y b e for instance a metric learned from in tradomain routing A more detailed description
of an IDRP sp eak ers handling of suc h attributes ma y b e found in
Com bining Equations and w e can easily express BR
a
s outputsthe sets
o
S
ay
in terms of its inputs
the sets
i
S
ax
Discussion
This settheoretic c haracterization succinctly captures BR route selection and route propagation b eha vior Ho w ev er
it is not a minim al c haracterization it is p ossible for instance to fold the functions E
a
and P
ax
in to one set function
This w ould result in an expression for the
o
S
ax
sets directly in terms of
s
S
a
Our c haracterization simplies the
deriv ation of Route Serv er b eha vior describ ed in Section Our use of the terms input and output route sets do not imply that IDRPsp eaking BRs p erio dically recom
pute and adv ertise routes to their p eers on the con trary IDRP BRs usually send a route adv ertisementonlywhen a
route to some address prex c hanges The com bined Equations and should b e view ed instead as an in v arian t
satised b y eac h IDRPsp eaking BR at every instant A domain BR mayc ho ose to propagate routes learned from in tradomain routing this asp ect of BR b eha vior
is not expressed in our settheoretic c haracterization whic h mo dels only IDRP p eering It is p ossible to trivially
extend our c haracterization to represen t this explicitly for example b y mo deling in tradomain route sets as b eing
learned from an in tradomain p eer
Weha v e assumed that an IDRP sp eak er adv ertises to its p eer at most one route p er address prex Actually an IDRP sp eak er ma y adv ertise at most one route p er address prex p er QoS v alue or the v alues of other IDRP
attributes lik e EXPENSE and TRANSITDELAY Our c haracterization can b e easily extended to mo del this b eha vior
for example b y distinguishing eac h route set dened in Section b y dieren t QoS v alues
F unctional Equiv alence Bet w een Mesh and Star P eering
Section describ ed the mesh p eering arrangemen tat exc hange p oin ts This arrangemen t has certain undesirable
c haracteristics ABRma y need to main tain p eering sessions with ev ery other BR at the exc hange p oin t This
arrangemen t also increases routing information trac a route from a BR can tra v erse the exc hange p ointas man y
times as the BR has p eers When a new BR is in tro duced at an exc hange p oin t eac h existing BR has to b e
recongured with route selection and exp ort criteria for the new BR F urther eac hexistingBR m ust also set up
a p eering session with the new BR Signican t op erational co ordination is necessary for these tasks since almost
ev ery BR at an exc hange p oin t is under a dieren t administrativ e authorit y global routing b eha vior can b e sev erely
aected b y co ordination failures
Numerous op erational and p erformance b enets result when instead of mesh p eering a functionally equiv alen t
star p eering arrangemen t Section is emplo y ed at exc hange p oin ts Eac h BR needs to main tain only a single p eering
session Routing trac tra v ersing the exc hange p oin ts transmission facilities is reduced Domain BRs no w need not
b e recongured when a new BR attac hes to the exc hange p oin tinstead only the RS needs to b e recongured to
p eer with the new BR F urther all route computation tak es place at the RS decoupling route computation from
data forw arding whic htak es place at the BRs this separation of function allo ws increased forw arding p erformance
at the BRs and easier deplo ymen t of new functionalityin to the routing infrastructure

In this section w e dene the condition for functional equiv alence b et w een the c omplete mesh and the c omplete
star p eering arrangemen ts at exc hange p oin ts In a complete mesh at exc hange p oin t Xev ery BR attac hed to X
p eers with ev ery other BR attac hed to X In a corresp onding complete star at Xev ery BR attac hed to X has
the same same selection and exp ort criteria as in the complete mesh and p eers only with the Route Serv er In this
and the next section w e use the terms mesh and star to resp ectiv ely mean unless otherwise sp ecied a complete
mesh and a complete star Later w esho w that the Route Serv er b eha vior w e deriv e from this equiv alence condition
can b e used ev en when mixed mesh and star arrangemen ts are deplo y ed at X Wesa y that the mesh and its corresp onding star are functionally equiv alen t if giv en the same inputs all BRs at
the exc hange p oin t select the same routes in b oth arrangemen ts Th us if in Figures and the routes adv ertised
o v er the IDRP p eering links into the b o x are the same in b oth arrangemen ts the routes selected b yeachBR
within the b o x m ust also b e the same F urther this condition m ust hold for all p ossible selection and exp ort
criteria at those BRs If our equiv alence condition holds the routes adv ertised o v er the IDRP p eering links out of
the b o x is also the same in b oth arrangemen ts from Equations and Our equiv alence condition can b e stated in terms of the notation dev elop ed in Section Denote b y
s
S
a
the
set
s
S
a
when BRs at X are congured in the mesh arrangemen t Denote b y
s
S
a
the set
s
S
a
when BRs at X are
congured in the corresp onding star arrangemen t Using a similar notation for the sets
i
S
ax
w e get
Equiv alence Condition F or eac h BR
a
in X and for all p ossible selection and exp ort criteria at BR
a
if
i
S
ag
i
S
ag
for all p eers
BR
g
of BR
a
whichare not attac hed to Xw e require
s
S
a
s
S
a
A Settheoretic Characterization of Route Serv ers
Using the formalism dev elop ed in Section and starting from the equiv alence condition of the previous section w e
can mathematical ly derive an expression for the Route Serv ers outputs in terms of its inputs This section presen ts
that deriv ation and the in terpretation of the deriv ed expression
Deriv ation of Route Serv er Beha vior
In a star arrangemen t the Route Serv er p eers with eac h BR
a
attac hed to X The RS receiv es a set of routes from
eac h BR
a
and adv ertises another set of routes to eac h BR
a
Denote the former route sets b y
i
R
a
the RSs inputs
and the latter b y
o
R
a
the RSs outputs BR
a
s selection and exp ort criteria in the star are the same as in the
mesh that is the functions I
a
E
a
and P
ax
are the same in b oth arrangemen ts The star arrangemen t ho w ev er
in tro duces a new p eersp ecic exp ort function P
aRS
If the star is functionally equiv alen t to the mesh w esho w
that there exists a settheoretic expression Equation for
o
R
a
in terms of
i
R
a
and the functions I and P By rewriting Equation w earriv e at the follo wing expressions for
s
S
a
and
s
S
a
s
S
a
H x B R x not on X
I
a
i
S
ax
x B R x on X
I
a
i
S
ax
s
S
a
H x B R x not on X
I
a
i
S
ax
I
a
o
R
a
Both equations simply split the set union of Equation in to t w o parts the route sets adv ertised b y p eers not directly
attac hed to X and the route sets adv ertised b y p eers directly attac hed to X The con tribution to
s
S
a
in Equation from p eers directly attac hed to X can b e rewritten as the set of
hroute preference i pairs ha ving the highest preference among routes adv ertised b y those p eers Equation then
b ecomes
s
S
a
H
x B R x not on X
I
a
i
S
ax
I
a
H x B R x is on X
I
a
i
S
ax
Giv en the same inputs to BR
a
in b oth arrangemen ts from p eers not attac hed to Xw e see b y an insp ection of
Equations and that
o
R
a
H x B R x on X
I
a
i
S
ax

By noticing that
i
S
ax
can b e written as
o
S
xa
and the latter set can b e rewritten in terms of
e
S
x
Equation w e
get the follo wing expression
o
R
a
H x B R x on X
I
a
P
xa
e
S
x
Recall that
e
S
x
can b e written in terms of
s
S
x
Equation and if the star is equiv alen t to the mesh then
w e can use Equation to rewrite Equation as
o
R
a
H x B R x on X
I
a
P
xa
e
S
x

Finallyif P
aRS
is the iden tit y function then
e
S
x
is simply the set of routes that BR
a
actually propagates to
the RS in the star arrangemen t from Equation w eha v e called this set
i
R
x
Making this substitution w eget
o
R
a
H x B R x on X
I
a
P
xa
i
R
x

T o summarize when the equiv alence condition of Section holds the Route Serv er m ust compute and adv ertise
for eac h BR
a
the set
o
R
a
from Equation further the set of routes that eac h BR
a
propagates to the RS is dened
b y the requiremen t that P
aRS
be the iden tit y function F or the purp oses of this pap er Equation suces as a
succinct description of Route Serv er b eha vior in star arrangemen ts F or completeness w em ust also sho w that the
con v erse is truethat is w em ust showthatgiv en the same set of inputs to the mesh and star arrangemen ts and
RS b eha vior dened b y Equation eac h BR selects the same routes in b oth arrangemen ts W e refer the in terested
reader to App endix for this
Informal Description of Route Serv ers
Equation completely and succinctly denes the b eha vior of a Route Serv er in star p eering arrangemen ts Based
on this equation w ema y describ e the Route Serv ers computation of
o
R
a
as a threestep pro cedure Figure This
pro cedure is rep eated for ev ery BR that p eers with the RS
Applying p eersp ecic exp ort criteria In this step to routes receiv ed from eachpeer BR
x
the Route Serv er
applies the same p eersp ecic exp ort criteria that BR
x
w ould apply b efore propagating routes to BR
a
Of
those routes that matc h this criteria the RS sets p eersp ecic attributes in the same way that BR
x
w ould
ha v e b efore propagating routes to BR
a
F or this the RS m ust b e congured with eac h clien t BR
a
s p eersp ecic exp ort criteria and p eersp ecic
attribute handling rules F urther for the RS to correctly em ulate a BRs p eersp ecic attribute handling
b eha vior eac hBRm ust pass on a routes p eersp ecic attributes unc hanged to the RS this is actually implied
b y the condition that P
aRS
b e the iden tit y function The rules for conguring BRs to pass receiv ed p eer
sp ecic attributes unc hanged dep end on the p eersp ecic attribute these rules are describ ed in
Assigning Route Preferences Toeac h route resulting from the previous step the RS assigns the same pr efer enc e
that BR
a
w ould assign the route Again in order to correctly em ulate BR
a
the RS m ust b e congured with
BR
a
s selection criteria
In this step the RS is able to correctly apply BR
a
s selection criteria b ecause it has correctly set the appropriate
p eersp ecic attributes and b ecause BR
x
has correctly applied uniform attributes b efore adv ertising routes to
the RS The RS itself do es not set an y uniform attributes
Selecting Most Preferred Route F rom the routes and their asso ciated preferences obtained from the previous
step the RS selects for eac h distinct address prex the route with the highest asso ciated preference If all
routes to an address prex are assigned the RS do es not select an y routes The set of routes selected in
this step forms
o
R
a

Applying peer-specific criteria:
Apply the peer-specific export criteria,
and set peer-specific attributes, in the
same way that the sender of the route
would have done for routes to this BR.
Assigning route preferences:
Assign the same preferences that
this BR would have assigned to routes.
Select highest preference:
Pick, for each distinct address prefix,
the route with the highest preference.
RR
R
Route Server
H
I
P
x
i
x,a
ab
oo
a
Figure RS R oute Sele ction This gure pictoriall y describ es the route selection b eha vior of a Route Serv er implied b y
Equation Discussion
The equiv alence condition of Section w as stated in terms of complete mesh and complete star arrangemen ts
Ho w ev er if a BR at X p eers with the RS as w ell as with some other BRs attac hed to X that arrangemen t is still
functionally equiv alen t to complete mesh p eering Th us if BR
a
p eers with BR
y
in addition to the RS and r is a
route in
s
S
a
receiv ed from BR
y
in the complete mesh BR
a
receiv es t w o copies of r in this new arrangemen tone
from the RS and one directly from BR
y
The more general arrangemen t in whic hev ery BR
x
at X p eers with ev ery
other BR
y
at X either directly or indirectly through the RS that is b oth BR
x
and BR
y
p eer with the RS or
b oth redundan tly is also functionally equiv alen t to the complete mesh
Our deriv ation has implicitly assumed that to a BR in a star arrangemen t the RS app ears to b e an IDRP
sp eak er Both Equation and the informal description of the previous section sho w ho w ev er that the Route
Serv ers route selection pro cedure is dieren t from that of an IDRP sp eak er In particular the c haracterization
describ ed in Section do es not apply to the Route Serv er There is ho w ev er signican t b enet to using IDRP
p eer connection managemen t and route exc hange mec hanisms for p eering b et w een RS and the BRs in the star
arrangemen t This a v oids in v en ting a completely new route exc hange mec hanism F urther no new co de need b e
deplo y ed at BRs to p eer with the RS
As with the c haracterization of BR b eha vior our description of RS b eha vior do es not imply that the RS p erio d
ically computes and propagates the routes in
o
R
a
Whenev er some p eer adv ertises a new route to an address prex
the RS up dates
o
R
a
for eac h BR
a
and adv ertises only up dates Equation should b e conceptually view ed as the
in v arian t satised b y the RS for eac h BR
a
at all times
In the star arrangemen t ev en though routing information b et w een t w o BRs attac hed to X passes through the
RS it is desirable that pac k et forw arding b et w een b et w een those t w o BRs b ypass the RS completely This is
ac hiev ed using the NEXTHOP attribute if
o
R
a
con tains a route r from BR
x
r s NEXTHOP attribute con tains BR
x
s
net w orkla y er address Using this address BR
a
forw ards data pac k ets directly to BR
x
In IDRP a BR is not required to assign a v alue to the NEXTHOP attribute of a route it propagates recipien ts
of suc h a route implicitly assume that the v alue of this attribute is the senders net w orkla y er address Therefore
in the mesh arrangemen t BR
a
ma y receiv e the same route r from BR
x
but without the NEXTHOP set in the
corresp onding star arrangemen t though this attribute w ould b e set This apparen t violation of our equiv alence
c haracterization is readily solv ed b y explicitly considering r to b e asso ciated with a NEXTHOP attribute in the mesh

5
10
2 3 4 5 6 7 8 9 10
Time (in msec)
Number of Peers
RS Route Processing Times
Figure RS Pr o c essing R e quir ements This graph sho ws the v ariation of RS route pro cessing time with the n um b er of p eers
Only ms are required to pro cess a top ology c hange aecting one address prex for ten p eers
ev en if BR
x
did not assign a v alue to that attribute b efore propagating r to BR
a
Route Serv er P erformance
The RS describ ed in Section can b e implemen ted in dieren tw a ys A p oten tially space ecien t implemen tation
main tains a single table con taining all inputs to the RS ie
i
R
a
for all BR
a
at X Supp ose BR
x
adv ertises a new
route to address prex dT o compute the eect of this c hange on
o
R
a
thisimplemen tation m ust apply P
xa
and I
a
to al l routes to d in its table It m ust rep eat this computation for ev ery BR
a
Suc h an implemen tation strategy is
computationally in tensiv ethe RS ma y not b e able to pro cess routing up dates quic kly enough
Our initial RS implemen tation mak es a more reasonable timespace tradeo On b ehalf of eac h BR our RS
implemen tatio n conceptually main tains a table called a viewthe view for BR
a
is denoted b y view
a
whic h stores
the result of
x B R x on X
I
a
P
xa
i
R
x
see Equation More precisely view
a
con tains a ro w for eac h address prex and a column for eac h p eer Let r be
the route to address prex d that is receiv ed b y the RS from p eer BR
x
The en try in the ro w for d and column for
BR
x
con tains the hroute preference i pair formed b y rst applying P
xa
to r and then applying I
a
to the resulting
route When the RS receiv es a new route to d from some BR
x
it can ecien tly compute the eect of this c hange
on
o
R
a
from view
a
Unlik e our RS an IDRPsp eaking BR main tains only one viewits o wn Therefore our RSs total stor age
r e quir ement is lik ely to b e signican tly larger than that of a BR If a route to an address prex c hanges the BR
need only compute the eect of this route on its view Ho w ev er our RS m ust compute the eect of this c hange on
ev ery view the time to do this r oute pr o c essing time is also lik ely to b e signican tly larger for the RS than a BR
F or an RS implemen tatio n that main tains separate views for eac h p eer w e can easily analyze the asymptotic
b eha vior of the metrics describ ed ab o v e Consider an exc hange p oin t X at whic h N BRs p eer with a Route Serv er If
in the w orst case eac hBR adv ertises routes to m address prexes the RSs total storage requiremen tis O mN
eac h view requires O mN storage from Equation F urther the route pro cessing time is O N
a top ology
c hange aecting a single address prex can result in O N pro cessing p er view F or an IDRPsp eaking BR from
Equation the storage requiremen tis O mN and the route pro cessing time is O N W e also instrumen ted our RS implem en tation to measure
the actual v alues of these metrics for some syn thetic
w orkloads In our exp erimen ts the RS ran on a SP AR CStation In eac h run of the exp erimen t the RS
op ened a BGP p eering session with N other b order routers SP AR CStation s and s receiv ed routes to m
address prexes from eac h BR and computed and adv ertised eac h BRs view W e instrumen ted the RS to measure
after eac h run the RSs total storage requiremen t and route pro cessing time The former w as measured as the
maxim um size of the RS pro cess data segmen t during the run the latter as the RS pro cess CPU utilization b et w een
receiving the rst route and sending the last route divided b y mW ev aried m from to in incremen ts
of and N from to Our RS implemen tat ion is for BGP v ersion W e do not exp ect our conclusions to dier for an IDRP RS

0
50
100
150
200
250
300
350
2 3 4 5 6 7 8 9 10
Memory (in MB)
Number of Peers
RS Total Storage Requirement
25000 address prefixes
15000 address prefixes
5000 address prefixes
Figure RS T otal Stor age R e quir ement This graph sho ws the v ariation of the RSs total storage requiremen t with the
n um b er of p eers Ev en with p eers a signican t amoun t of memory MB is required for route storage
Figure plots the RSs route pro cessing time when m is Only ms are required to pro cess a top ology
c hange aecting one address prex for ten p eers The curv e ts a parab ola in k eeping with our analysis ab o v e The
parab ola is quite shallo w upto p eers that is for upto ab out p eers our Route Serv er will pro cess t ypical
top ology c hangesthose aecting tens of address prexesin ab out a second Ho w ev er the RS can tak e on the
order of min utes to compute views after catastrophic ev en ts eg a link failure at the exc hange p ointwhic h causes
all p eer connections fail and sim ultaneously restart
Figure plots the RSs total storage requiremen t for three dieren tv alues of m These curv es also t a parab ola
v alidating our analysis ab o v e The storage requiremen t for p eers and address prexes is more than MB extrap olating the address prex curv e to p eers w e arriv e at a storage requiremen t of nearly MB
Bac kb one routers on the In ternet already carry nearly address prexes it is unrealistic to exp ect w orkstation
memory capacitytok eep pace with a Route Serv er with tens of p eers eac h of whom mightadv ertise routes to a
signican t fraction of these address prexes
Therefore while the RS route pro cessing times are considerable
w orkstation memory capacit y is lik ely to b e
the initial barrier limiting the use of RSs at large exc hange p oin ts
Our RS implemen tation replicates the en tire route descriptor in eac h view A careful reimplemen tation that
splits route descriptors in to viewsp ecic and common parts and stores only the viewsp ecic parts in view tables
can reduce the storage requirementb y a factor of four The next t w o sections discuss other tec hniques that can
also signican tly reduce RS storage requiremen ts and route pro cessing times
View Merging and Decom p ositi on
If the RS main tains a separate view for eac h BR attac hed to exc hange p oin t X its w orstcase storage requiremen t
v aries as the square of the n um b er of BRs see Section In this section w epresen t sucien t conditions under whic h
t w o or more views can b e merged or decomp osed in to subviews to reduce RS storage and computation requiremen ts
If for BRs BR
x
and BR
y
o
R
x
and
o
R
y
ev aluate to the same set for the same inputs the RS need only main tain
a single view on b ehalf of the t w o BRs In tuitiv ely view
x
and view
y
can b e merged only when b oth BRs selection
criteria are iden tical and all other p eers p eersp ecic exp ort criteria are the same for BR
x
and BR
y
F ormallythe
The route pro cessing times rep orted here do not capture the pro cessing of complex selection criteria suc h as preference assignmen t
based on path v ector regular expressions While suc h criteria are lik ely to b e expressed in a future commercial In ternet curren tIn ternet
domain selection criteria remain relativ ely simple

condition for merging the t w o views is b y insp ection of Equation Merge Condition a B R
a
on X I
x
P
ax
I
y
P
ay
T o motiv ate the decomp osition of views in to sub views w e describ e a dieren t represen tation of merge condition
Recall that view
x
is conceptually a table with a ro w for eac h address prex d and a column for eac h BR
a
at X
Section The en tryinro w d and column a of view
x
is calculated b y the follo wing function
entr y
xda
r
I
x
P
ax
r r is a route to addressprex d receiv ed from p eer BR
a
undened otherwise
That is to routes con taining address prex d from BR
a
this entry function applies BR
a
s p eersp ecic exp ort
criterion for BR
x
and then applies BR
x
s route selection criteria Using this w e can dene a r ow function that
computes ro w d of view
x
row
xd
r
r
N
hentr y
xdp r
entry
xdp N
r
N
i
where N is the n um b er of p eers This r ow function represen ts the pro cessing p erformed b y the RS on b ehalf of
BR
x
on routes con taining address prex d Using this notation merge condition can b e rewritten as
Merge condition d row
xd
row
yd
An RSs pro cessing on b ehalf of its p eers is determined b y selection and exp ort criteria of the BRs at X for merge
condition to b e satised these criteria m ust b e suc h that the RS iden tically pro cesses routes to every address
prex on b ehalf of b oth BR
x
and BR
y
An analysis of curren t domain p olicies rev eals that the lik eliho o d of
this ev entis v ery small further this situation is unlik ely to c hange in a future commercial In ternet with ev en more
div erse domain selection and exp ort criteria It is m uchmore lik ely that RS pro cessing on b ehalf of t w o BRs will
b e iden tical for some subset of address prexes That is it is more lik ely that view
x
and view
y
ha v e some common
r ow functions When this is true w e can decomp ose the t woviews in to three subviews These sub views resp ectiv ely
con tain Figure the ro ws with common r ow functions the ro ws of view
x
whose r ow functions are dieren t
from the corresp onding r ow functions of view
y
and the ro ws of view
y
whose r ow functions are dieren t from
the corresp onding r ow functions of view
x
F ormallyw e can decomp ose view
x
and view
y
in to three sub views if for a
subset of address prexes D Merge condition d D row
xd
row
yd
d D row
xd
row
yd
When t w o views are decomp osed in to three sub views the RS need only k eep one cop y of the common sub view
without this decomp osition it w ould ha v e required additional storage for the common sub view Greater sa vings ma y
b e obtained b y rep eatedly applying merge condition to the collection of N views one for eac h BR The follo wing
pro cedure ac hiev es maxim um space sa vings from view decomp osition Starting from the collection of N views one
for eac h BR the pro cedure selects an yt w o views in the collection applies merge condition to those views and
replaces the t w o selected views with the resulting three sub views in the collection This step is rep eated un til no
further decomp osition is p ossible This pro cedure has exp onen tial complexit y a discussion of heuristics for ecien tly
computing sub views is b ey ond the scop e of this pap er As a result of this pro cedure a route to address prex d can
app ear in as man y sub views as there are distinct r ow functions for d in the w orst case there ma ybe N distinct r ow
functions for d Analysis and Ev aluation of View Decomp osition
In the currentIn ternet domain selection and exp ort criteria are expressed using routing p olicy sp ecication languages
describ ed in While in general r ow functions can b e sp ecied in terms of an y route attribute these languages
allo w r ow functions to only dep end on a routes sender and on the address prex asso ciated with the route
In
this section w e rst deriv e the n um b er of p ossible r ow functions for address prex d under this restriction Then
Tw o functions are equiv alen t if they ha v e the same domain and for anyv alue in the domain b oth functions map to the same v alue
Actually RIPE allo ws r ow functions to dep end on the MULTI EXIT DISC Section attribute as w ell Since the lik eliho o d of
more than one BR from the same domain at one exc hange p ointis v ery lo w w e do not consider the attribute handling functions that
use MULTI EXIT DISC in our analysis

Common rows D
View
y
View
x
Common subview
Figure View De c omp osition Views for p eers BR x and BR y ma y b e decomp osed in to three sub views one con taining the
common ro ws in view x and view y the other t wocon taining the remnan ts from the t w o views
assuming all r ow functions are equally lik elyw e deriv e the probabilityof N BRs ha ving exactly v distinct r ow
functions W e use this probabilit y to estimate the exp ected RS storage requiremen t with view decomp osition and
compare it to the w orst case RS storage requiremen t without view decomp osition
Using a simple com binatorial argumen t w e countthe n umberofpossible r ow functions when a route to address
prex d is adv ertised b y p BRs In tuitiv ely this is the n um b er of p ossible c hoices for selection and exp ort criteria for
p dieren t routes to d a BR ma y reject some of these p routes then assign a rank order the preference assignmen t
step in Section to the remaining routes Th us if BR
a
rejects some i routes it can assign one of p i preference
v alues to the remaining routes w e can select i routes for rejection in
p
i
w a ys and assign p i preference v alues
to the rest in p i w a ys
Then the total n um ber of r ow functions that a BR
a
can c ho ose from for address prex
d is giv en b y
p
p
X
i p i p
i
Since there are N BRs and eachBR mayc ho ose a r ow function indep enden tly the total n umberofcom binations
of ro w functions equals p N
Among these
p v
v v
N v
ha v e exactly v distinct r ow functions v distinct
r ow functions can b e c hosen out of p functions in
p v
w a ys these v functions can b e arranged among v BRs
in vw a ys and the remaining N v BRs can b e assigned these v functions in v
N v
w a ys If w e assume that all
r ow functions are equally lik ely the probabilit y that there are exactly v distinct r ow functions for address prex d
among N BRs is giv en b y
P v
p v
v v
N v
p N
The exp ected n um b er of distinct r ow functions for d or equiv alen tly the exp ected n um b er of sub views that
a route to d is installed in when p BRs adv ertise a route to dis giv en b y
P
N
v v P v Th us when merge
condition is applied to r ow functions for d the exp ected RS storage requiremen t p er address prex is prop ortional
to p P
N
v v P v In the w orst case all the p routes to d are installed in eachof N sub views the RSs storage
requiremen t for routes to d is then prop ortional to p N Figure plots the ratio of the exp ected to the w orst case RS storage requiremen t as a function of p for dieren t
v alues of NF rom this gure w e see that signican tsa vings are p ossible for small v alues of pF or example in an
exc hange p oin t with BRs the size of some existing exc hange p oin ts view decomp osition can reduce RS storage
p i do es not include rank ordering where t w o p eers ha v e the same rank for routes to dThis is in ten tiona l since the IDRP tie
breaking rules actually ac hiev e total ordering

0
0.2
0.4
0.6
0.8
1
1 2 3 4 5 6 7 8
p
Ratio of Expected to Worst-case Storage Requirement
N = 10
N = 20
N = 30
N = 100
Figure Savings The abscissa of this graph is pthe n um b er of BRs adv ertising routes to a giv en address prex d The
ordinate sho ws the ratio of the exp ected RS storage requirementto the w orst case RS storage requiremen t for dieren tv alues
of p requiremen ts b y a factor of F or larger p view decomp osition do es not yield m uc h b enet the n um ber of r ow
functions for large p is large enough eg r ow functions for p that the probabilit yoft w o BRs c ho osing the
same r ow function is v ery lo w As exp ected the b enets of view decomp osition are higher for larger N In Figure w ev ary p from to N in practice not all v alues of p are equally lik elyW eno w estimate the
exp ected RS storage requirementfor a t ypical distribution for pSuc h a distribution could b e obtained from the
selection and exp ort criteria at an existing exc hange p oin t Unfortunately thisdata w as not a v ailable to us Instead
w e use the existing NSFNET bac kb one service to mim ic a large exc hange p oin t curren tly the NSFNET bac kb one
in terconnects BRs
T able giv es the distribution of p for the NSFNET bac kb one On the bac kb one most of the
address prexes are announced b ya small n um b er of p eers Ho w ev er the NSFNET bac kb one is distributed o v er a
wider area and in terconnects far more BRs than a t ypical exc hange p oin t for this reason w e exp ect this distribution
to b e ev en more sk ew ed to w ards small p at exc hange p oin ts
In our analysis eac hBR c ho oses its ro w functions uniformly among pro w functions in practice w e exp ect this
distribution to b e sk ew ed to w ards a subset of common r ow functions Let j b e that fraction of the p p ossible
r ow functions that are actually considered for computing P v Using the distribution for p from T able Figure plots the ratio of the exp ected RS storage requirementtothe w orst case requirementasafunction of j This gure indicates signican tsa vings for lowv alues of j as exp ected F or an exc hange p ointwith BRsview
decomp osition reduces the storage requirementb y a factor of for j and b ya factorof for j F or a
larger exc hange p oin t suc h as the en tire NSFNET bac kb one with p eers the sa vings are ev en more dramatic
from a factor of for j to for j Ev en these realistic estimates are p essimistic They are deriv ed under the assumption that that eachBR
indep endently c ho oses from among j p r ow functions In practice there is usually a correlation b et w een the r ow
functions for a destination F or example t w o BRs maycon tract with the pro vider domain for d to select similar r ow
functions for d In this case view decomp osition can pro vide ev en greater b enets
Multiple Route Serv ers
In Section w e describ ed the partial starpartial mesh alternativ e to the complete star arrangemen t This section
discusses a v arian t of the star in whic h more than one RS is emplo y ed at an exc hange p oin t Suc h an arrangementhas
man y uses including impro ving the failure tolerance of the complete star and reducing RS storage and computation
Actually NSFNET bac kb one in terconnec ts BRs of whic honly ha v e distinct domain selection and exp ort criteria

0
0.2
0.4
0.6
0.8
1
0 0.2 0.4 0.6 0.8 1
j
Ratio of Expected to Worst-case Storage Requirement with NSFNET Data
N = 10
N = 20
N = 30
N = 100
Figure Exp e ctedRS stor age r e quir ements The abscissa of this graph plots j the fraction of p ossible r ow functions that
are actually used b y BRs The ordinate of this graph is the ratio of the exp ected RS storage requiremen tto the w orst case
RS storage requirementwhen p is distributed as sho wn in T able p freq T able Distribution for p This table sho ws the fraction of address prexes to whic h routes are adv ertised b y p BRs on the
NSFNET bac kb one for dieren tv alues of p requiremen ts
Robustness
In the complete star arrangemen t if eac h BR only p eers with the RS the latter b ecomes a single p oin t of failure
Ho w ev er RS failures only aect routing information o w BRs con tin ue to forw ard pac k ets but ma y fail to adapt to
top ology c hanges By in tro ducing greater redundancy in the star arrangemen t it is p ossible to reduce the probabilit y
of suc h failures In the simplest approac h to pro viding suc h redundancyeac h BR
a
attac hed to X p eers with t w o
Route Serv ers RS
and RS
In this arrangemen t eac h BR
a
receiv es one set of routes from eac h Route Serv er w e see from Equation that
b oth the sets
o R
a
and
o R
a
resp ectiv ely the views for BR
a
main tained b y RS
and RS
are iden tical W ecan
easily sho w that this arrangemen t is functionally equiv alen t to the complete mesh In tuitiv ely eac h BR
a
receiv es t w o
copies of the routes it w ould ha v e receiv ed in the complete star this do es not c hange the con ten ts of
s
S
a
When either
RS fails the arrangemen t rev erts to the complete star This solution do es not require an y co ordination b et w een
Route Serv ers
Load Splitting
Multiple RSs ma y also b e used to reduce RS storage requiremen ts Consider the arrangemen tatexc hange p oin t X
in whic h appro ximately half the BRs p eer with one RS denote this b y RS
and the other half p eer with a second
RS RS
Eac hRSmain tains a view for e ach of the the BRs on X not just those that directly p eer with it Eac hof

these views is p artial in that the view for BR
x
in RS
only con tains the con tributions of BRs p eering with RS
Supp ose nowthat BR
a
p eers with RS
RS
computes partial view
o R
a
using Equation o v er all BRs directly
connected to it In parallel RS
computes partial view
o R
a
using Equation for eac h of its p eers Then RS
transfers the set of routes b y some unsp ecied mec hanism
o R
a
to RS
whic h merges these t w o partial views to
get
o
R
a
This load splitting appro ximately halv es the storage requiremen ts at an RS In addition it also halv es RS
pro cessing requiremen ts This approac h easily generalizes to more than t w o RSs in the limit when the load is split
as manyw a ys as there are BRs the arrangemen t rev erts to the complete mesh Some in terRS sync hronization is
necessary for exc hanging partial views
Destination Splitting
A dieren t approac h to reducing RS storage requiremen ts strip es the space of address prexes across RSs F or
example eac h BR
a
at an exc hange p oin t X could p eer with t woRSs RS
and RS
but send routes to one half of
the address space to RS
and send routes to the other half of the address space to RS
Both RS
and RS
compute
strip ed views
o R
a
and
o R
a
resp ectiv ely and adv ertise these to BR
a
BR
a
then computes its set of selected routes
from the union of the t w o strip ed views
This solution also appro ximately halv es the computational and storage complexityat eac h RS The approac h
easily generalizes to more than t w o RSs No in terRS sync hronization is necessary but some additional conguration
ma y b e necessary at eachBR Related W ork
In terdomain P olicy Routing IDPR isanarc hitecture for sourcesp ecied p olicy routing When using IDPR to
send data to dieren t address prexes eac h domain uses a domainlev el source route satisfying its p olicy requiremen ts
An IDPR route serv er computes this source route on b ehalf of a clien t domain using global linkstate top ology
information Unlik e an IDPR route serv er our RS computes hopb yhop routing tables satisfying its clien t domains
p olicy requiremen ts
Lik e IDPR the Unied in terdomain routing arc hitecture also uses the term route serv er to denote an
en tit y that computes domainlev el source routes or fragmen ts thereof on b ehalf of domain BRs Unied has t w o
comp onen ts A hopb yhop routing comp onen t for realizing commonl y expressed domain p olicies using IDRP and A source routing comp onen t for realizing more sp ecialized p olicy using the Explicit Routing Proto col ERP
these sp ecialized p olicies are c haracterized b y not b eing shared across enough domains to justify computation
b y the hopb yhop comp onen t Our RS while clearly a part of the hopb yhop comp onen t can function as a Unied
route serv er to craft a domainlev el source route to an address prex a domain BR can query the RS for the path
v ectors asso ciated with IDRP routes to that address prex
The term route serv er is also used in a sligh tly dieren t sense in the OSPF in tradomain routing proto col sp ec
ication In OSPF domain BRs inject external routing information in to in tradomain routing Domain p olicies
usually congured in to eac h domain BR go v ern this dissemination of external routing information in to OSPF An
alternativ e mec hanism for injecting external routes in to OSPF uses a single route serv er whic h congured with
domain p olicy p erforms the same function This use of the route serv er simplies domain routing conguration
The RIPE Route Serv er is a precursor to our RS RIPEs Route Serv er is also designed to compute in ter
domain routing tables on b ehalf of domain BRs attac hed to an exc hange p oin t Ho w ev er their design is predicated
on the assumption that there exists a single preferred path to an address prex from the exc hange p ointatwhic h
the RS is deplo y ed With this assumption it suces for their RS to compute one view for all attac hed BRs at the
exc hange p oin t Our more general design allo ws dieren t domain BRs to use dieren t paths from the exc hange p oin t
to the same destination
Conclusions
In this pap er w e dev elop ed a formalism for describing the b eha vior of IDRP sp eaking BRs stated a condition for
functional equiv alence b et w een the mesh and the star arrangemen ts and used that to deriv e RS b eha vior in star

arrangemen ts W e also sho w ed that using tec hniques suc h as view decomp osition the storage and computational
requiremen ts of RSs can b e k ept within the limits of currentw orkstation tec hnologyBy sligh tly relaxing the condition
for functional equiv alence it is p ossible to extend the view decomp osition tec hniques to further reduce RS storage
requiremen ts the pap er do es not discuss suc h approac hes
The RS describ ed in this pap er is just one comp onentof the R outing A rbiter arc hitecture for In ternet in ter
domain routing Other complemen tary comp onen ts include an In ternetwide R outing R e gistrywhic h con tains con
nectivit y and p olicy information from all constituen t domains and an In ternet Network Op er ations Center The
Routing Arbiter arc hitecture ensures stable and easily analyzable In ternet routing without compromising domain
autonom y As describ ed in Section our RS can also b e used to compute sp ecialized domainlev el source routes or source
route fragmen ts in the Unied arc hitecture Apart from using the path v ectors con tained in IDRP routes for
this purp ose the RS can also compute these sp ecialized source routes directly from information main tained in the
Routing Arbiter Routing Registry Finally b ecause IDRP uses transp ortlev el connections for route exc hange an RS need not b e ph ysically lo cated
at the exc hange p oin t it serv es This feature ma y b e used to impro v e the failure tolerance of the complete star
arrangemen t More generally this enables a n um ber of v arian ts of the hopb yhop routing infrastructure for example
a single Route Serv er could remotely serv e more than one exc hange p oin t a hierarc h y of Route Serv ers could serv e
all in terdomain BRs in the In ternet and so on Suc h an arrangemen t requires stable connectivitybet w een a remote
RS and the exc hange p oin ts it serv es frequen t connectivit y failures can impair the abilityof in terdomain routing
to quic kly adapt to top ology c hanges
Ac kno wledgem en ts
Y ak o v Rekh ter IBM claried some asp ects of Route Serv er and IDRP op eration John Ch u and Jim Rubas IBM
implemen ted the Route Serv er Dale Johnson and Jessica Y u Merit Inc pro vided domain p olicy data for estimating
RS storage requiremen ts using view decomp osition Celeste Anderson Bill Manning and Jon P ostel ISI pro vided
v aluable suggestions and commen ts on earlier v ersions of this pap er
References
T Bates T ec hnical Implemen tation of the RIPE Route Serv er In Pr o c INET San F rancisco CA August
T Bates E Geric h L Jonc hera y JM Jouanigot D Karren b erg M T erpstra and J Y u Represen tation of
IP Routing P olicies in a Routing Registry T e chnic al R ep ort rip e RIPE NCC Amsterdam Netherlands
Octob er Proto col for Exc hange of In terdomain Routeing Information among In termediate Systems to Supp ort F or
w arding of ISO PDUs ISOIEC JTCSC CD D Estrin J P ostel and Y Rekh ter Routing Arbiter Arc hitecture In ConneXions pages v olno August D Estrin Y Rekh ter and S Hotz A Scalable In terDomain Routing Arc hitecture In Pr o c A CM SIGCOMM
pages Baltimore Maryland August P F ord T Li and Y Rekh ter Explicit Routing Proto col for IPv In ternetDraft w ork in progress Av ailable
as draftietfsdrperp t xt b y anon ymous ftp from dsinternicnet The Gated Routing Daemon Av ailable via anon ymous ftp from gatedcornelle du A Route Rep ository for Route Serv ers In preparation Jan uary MERIT Net w ork Inc NSFNET Net w ork Announcemen t Change Request v MERIT Net w ork Inc Ann Ar
b or Mic higan Av ailable from nicmeritedun sfnet anno unced netw orks temp late netR EADMEF ebru
ary
Peering sessions with
other BRs
Star peering at exchange point
Route Server
Peering sessions with
other BRs
IDRP peering session
Mesh peering at exchange point
AA B
CD
B
CD
Figure RS Behavior Derivation This gure is used to explain the pro of for the con v erse of the RS b eha vior deriv ation
of Section J Mo y OSPF V ersion R e quest for Comments DDN Net w ork Information Cen ter Marc h Net w ork Access P oin t Manager Routing Arbiter Regional Net w ork Pro viders and V ery HighSp eed Services
Pro vider for NSFNET and the NRENSM Program National ScienceF oundation Pr o gr am Solicitation Ma y NSFNET P olicy Routing Database PRDB Main tained b y MERIT Net w ork Inc Ann Arb or Mic higan
Con ten ts a v ailable from nicmeritedu nsfn etan nounc edne twork snet sta gnow b y anon ymous ftp
Y Rekh ter In terDomain Routing Proto col IDRP In IEEEA CM Journal of InternetworkingV ol Y Rekh ter and T Li A Border Gatew a y Proto col BGP R e quest for Comments DDN Net w ork
Information Cen ter July RIPE Net w ork Co ordination Cen ter Amsterdam RIPE P olicy Database Con ten ts a v ailable from
ftpripenetripe dbase ripe db byanon ymous ftp
M Steenstrup An Arc hitecture for In terDomain P olicy Routing R e quest for Comments Net w ork
Information Cen ter July TJ W atson ResearchCen ter IBM Corp
K V aradhan D Estrin S Hotz and Y Rekh ter SDRP Route Construction In ternetDraft w ork in progress
Av ailable as draftietfsdrprout econ stru ction t xt byanon ymous ftp from dsinternicnet Route Serv ers for IDRP In ternetDraft in preparation
App endix A RS Beha vior Deriv ation
This section sk etc hes a pro of for the follo wing claim If Route Serv er b eha vior at an exc hange p oin t X is dened b y
Equation and the condition on P
aRS
in Section and the external inputs ie those from p eers not on X to
the BRs at X are the same in b oth the mesh and the star arrangemen ts then the equiv alence condition of Section that is all BRs at X select the same routes in b oth arrangemen ts holds This claim is the con v erse of the deriv ation
describ ed in Section Supp ose that to some destination dBR A in Figure selects route r
in the mesh arrangemen t and route r
in the star arrangemen t Supp ose to the con trarythat r
is dieren t from r
Since all external inputs to A are
the same in b oth arrangemen ts A m ust ha v e selected r
from
o
R
a
This implies that at least one of the BRs sa y Bm ust b e adv ertising a dieren t route to d in the star than in
the mesh Equation Therefore B m ust ha v e selected dieren t routes to d in the t w o arrangemen ts Rep eating
the argumen t in the ab o v e paragraph at least one of A Cor D m ust ha v e selected dieren t routes to d in the t w o
arrangemen ts Clearly it cannot b e A otherwise w e arriv e at a circularit y th us B selects dieren t routes b ecause
one of C or D selects dieren t routes in the t w o arrangemen ts Pro ceeding th us w earriveatacon tradiction

Abstract (if available)

Linked assets

Computer Science Technical Report Archive

Conceptually similar

PDF

USC Computer Science Technical Reports, no. 631 (1996)

PDF

USC Computer Science Technical Reports, no. 669 (1998)

PDF

USC Computer Science Technical Reports, no. 605 (1995)

PDF

USC Computer Science Technical Reports, no. 642 (1996)

PDF

USC Computer Science Technical Reports, no. 706 (1999)

PDF

USC Computer Science Technical Reports, no. 677 (1998)

PDF

USC Computer Science Technical Reports, no. 723 (2000)

PDF

USC Computer Science Technical Reports, no. 774 (2002)

PDF

USC Computer Science Technical Reports, no. 745 (2001)

PDF

USC Computer Science Technical Reports, no. 672 (1998)

PDF

USC Computer Science Technical Reports, no. 732 (2000)

PDF

USC Computer Science Technical Reports, no. 697 (1999)

PDF

USC Computer Science Technical Reports, no. 750 (2001)

PDF

USC Computer Science Technical Reports, no. 704 (1999)

PDF

USC Computer Science Technical Reports, no. 731 (2000)

PDF

USC Computer Science Technical Reports, no. 692 (1999)

PDF

USC Computer Science Technical Reports, no. 613 (1995)

PDF

USC Computer Science Technical Reports, no. 702 (1999)

PDF

USC Computer Science Technical Reports, no. 608 (1995)

PDF

USC Computer Science Technical Reports, no. 565 (1994)

Description

Ramesh Govindan, Cengiz Alaettinoglu, Kannan Varadhan, Deborah Estrin. "A route server architecture for inter-domain routing." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 603 (1995).

Asset Metadata

Creator Alaettinoglu, Cengiz (author), Estrin, Deborah (author), Govindan, Ramesh (author), Varadhan, Kannan (author)

Core Title USC Computer Science Technical Reports, no. 603 (1995)

Alternative Title A route server architecture for inter-domain routing (title)

Publisher Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA (publisher)

Tag OAI-PMH Harvest

Format 18 pages (extent), technical reports (aat)

Language English

Unique identifier UC16269781

Identifier 95-603 A Route Server Architecture for Inter-Domain Routing (filename)

Legacy Identifier usc-cstr-95-603

Format 18 pages (extent),technical reports (aat)

Rights Department of Computer Science (University of Southern California) and the author(s).

Internet Media Type application/pdf

Source 20180426-rozan-cstechreports-shoaf (batch), Computer Science Technical Report Archive (collection), University of Southern California. Department of Computer Science. Technical Reports (series)

Access Conditions The author(s) retain rights to their work according to U.S. copyright law. Electronic access is being provided by the USC Libraries, but does not grant the reader permission to use the work if the desired use is covered by copyright. It is the author, as rights holder, who must provide use permission if such use is covered by copyright.

Repository Name USC Viterbi School of Engineering Department of Computer Science

Repository Location Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089

Repository Email csdept@usc.edu

Inherited Values

Title Computer Science Technical Report Archive

Coverage Temporal 1991/2017

Repository Email csdept@usc.edu

Repository Name USC Viterbi School of Engineering Department of Computer Science

Repository Location Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089

Publisher Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA (publisher)