The Case for Separating Routing from Routers
Nick Feamster, Hari Balakrishnan Jennifer Rexford, Aman Shaikh, Jacobus van der Merwe
MIT Computer Science & AI Lab AT&T Labs Research
{feamster,hari}@csail.mit.edu {jrex,ashaikh,kobus}@research.att.com
ABSTRACT
Over the past decade, the complexity of the Internet s routing in-
frastructure has increased dramatically. This complexity and the
problems it causes stem not just from various new demands made
of the routing infrastructure, but also from fundamental limitations
in the ability of today s distributed infrastructure to scalably cope
with new requirements.
The limitations in today s routing system arise in large part from
the fully distributed path-selection computation that the IP routers
in an autonomous system (AS) must perform. To overcome this
weakness, interdomain routing should be separated from today s IP
routers, which should simply forward packets (for the most part).
Instead, a separate Routing Control Platform (RCP) should select
routes on behalf of the IP routers in each AS and exchange reacha-
bility information with other domains.
Our position is that an approach like RCP is a good way of cop-
ing with complexity while being responsive to new demands and
can lead to a routing system that is substantially easier to manage
than today. We present a design overview of RCP based on three
architectural principles path computation based on a consistent
view of network state, controlled interactions between routing pro-
tocol layers, and expressive speci cation of routing policies and
discuss the architectural strengths and weaknesses of our proposal.
Categories and Subject Descriptors
C.2.2 [Network Protocols]: Routing Protocols; C.2.6 [Computer-
Communication Networks]: Internetworking
General Terms
Algorithms, Design, Management, Performance, Reliability
Keywords
routing architecture, interdomain routing, BGP
1. Introduction
This paper posits that interdomain routing protocol functional-
ity should be separated from the routers. Stated somewhat glibly,
routing is too important and too complicated to be left to today s
routers! IP routers should be lookup-and-forward switches,
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for pro t or commercial advantage and that copies
bear this notice and the full citation on the rst page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior speci c
permission and/or a fee.
SIGCOMM 04 Workshops, Aug. 30-Sept. 3, 2004, Portland, Oregon, USA.
Copyright 2004 ACM 1-58113-942-X/04/0008 ...$5.00.
RCP
RCP
RCP
P
h
y
s
ic
a
l
P
e
e
r
in
g
AS 3
AS 1
AS 2
Inter-AS Protocol
iBGP
Figure 1: A Routing Control Platform (RCP) for the Internet. Circles
represent conventional routers.
forwarding packets as rapidly as possible without being concerned
about path selection. A separate entity should be responsible for
computing the best BGP
1
paths on behalf of all the routers in a do-
main and disseminating the results to the routers.
Separating interdomain routing from the individual routers is one
way to cope with the increasing complexity of the routing system.
The growth of the Internet has introduced considerable complexity
into interdomain routing, as features have been added to BGP to
support more exibility (e.g., new route attributes such as commu-
nities and MED) and larger scale (e.g., route re ectors and route
aggregation). This complexity has made routing protocol behav-
ior increasingly unpredictable and error prone [12]. Requiring the
routers to perform complex path computation introduces the poten-
tial for inconsistencies across routers, complicates the expression
of routing policy, and makes troubleshooting dif cult.
Instead, a separate Routing Control Platform (RCP) should have
the information needed to select routes for each router in a domain
(e.g., an AS) and exchange routing information with RCPs in other
domains.
2
Figure 1 illustrates this idea. Each RCP could use a new
way of selecting routes for each router (rather than using today s un-
wieldy BGP decision process); RCPs could even exchange routes
using an interdomain routing protocol other than BGP. By selecting
routes on behalf of all routers in a domain, RCP can avoid many
internal BGP-related complications (e.g., forwarding loops [9] and
signaling partitions [12]). This approach also facilitates traf c engi-
neering, simpler and less error-prone policy expression, more pow-
erful diagnosis and troubleshooting, more rapid deployment of pro-
tocol modi cations and features, enforceable consistency of routes,
and veri able correctness properties. In contrast to previous ap-
proaches for centralizing interdomain routes and policies at route
servers [19], RCP also preserves the autonomy of each AS for se-
lecting paths and applying policies.
3
1
The Border Gateway Protocol (BGP) [1] is the de facto standard interdo-
main routing protocol.
2
In this paper, we use the term RCP to refer to both the architecture as a
whole and to the speci c instance of RCP within a routing domain.
3
RCP more closely resembles the Network Control Point (NCP), introduced
in the telephone network in the early 1980s to simplify network manage-
ment and support the rapid introduction of new features (e.g., enhanced 1-
800 service) [24, 27].

RCP s deployment path is as interesting as the envisioned end
state. The deployment of RCP can proceed in three stages, offering
the following bene ts to network operators as RCP becomes more
widely deployed:
1. Control over protocol interactions: RCP customizes the
distribution of BGP routes within an AS by replacing inter-
nal BGP route re ectors. This stage does not require coop-
eration from neighboring domains. Because RCP has a com-
plete view of the intra-AS topology and selects routes on be-
half of all routers in the domain, it can prevent internal BGP
routing anomalies and control traf c ow more directly.
2. Network-wide path selection and policy: By establishing
BGP sessions directly with the routers in neighboring ASes,
RCP can perform all routing decisions for an AS, bypassing
the BGP decision process on the routers. This approach sim-
pli es con guration and allows an AS to select routes based
on high-level goals, rather than obscure manipulation of BGP
route attributes.
3. Rede nition of inter-AS routing: Using RCPs, rather than
routers, to exchange routes between ASes (as shown in Fig-
ure 1) enables the design of a new routing protocol because
interdomain routing is now separated from IP routers. For
example, RCP can be used to implement a control overlay
that selects paths based on prices or performance statistics.
In addition to providing substantial improvements over today s
routing architecture, RCP has a compelling deployment incentive
(i.e.,a tipping point ), so that an individual AS could deploy RCP
and still realize signi cant bene ts. Because the rst two stages of
deployment substantially reduce management complexity for BGP
routing within a single AS, network operators have a compelling
incentive to deploy RCP regardless of whether other ASes do so.
Managing routing con guration requires constant vigilance from
network operators. Although network management systems can of-
ten automate the most frequent tasks, working around and within
the constraints of the existing routing protocols makes these sys-
tems much more complicated than necessary. Additionally, the
complexity of modeling and managing the distributed con guration
state in today s routers has itself impeded the evolution of auto-
mated management systems. In addition, because it communicates
routes to each router in the AS using BGP, RCP is backwards com-
patible with existing routers; deploying RCP requires no changes to
router hardware and software, only to router con guration.
The rest of the paper proceeds as follows. Section 2 presents
background on today s interdomain routing infrastructure. In Sec-
tion 3, we propose three architectural principles and explain how
the existing routing infrastructure fails to meet them. Building on
these insights, Section 4 describes the RCP architecture in detail,
focusing on how each stage of deployment simpli es router con-
guration and management. In Section 5, we discuss the risks and
challenges of having the RCP in the critical path of IP routing deci-
sions. Section 6 reviews related work, and Section 7 concludes.
2. BGP Routing in an Autonomous System
An AS uses external BGP (eBGP) to exchange reachability in-
formation with neighboring domains and internal BGP (iBGP) to
distribute routes inside the AS, as shown in Figure 2. Each router
invokes the BGP decision process to select a single best route
for each destination pre x from the candidate routes learned from
eBGP and iBGP. The router combines the best BGP route with
information about the internal network topology from the Interior
Physical
Peering
iBGP
eBGP
Figure 2: Operation of BGP routing inside an AS. Most small networks
use a full mesh iBGP con guration, where every router in the AS has
an iBGP session to every other router.
A
C
RR
B
1
1
1
2
Figure 3: An example of where iBGP with route re ection does not em-
ulate full-mesh iBGP; numbers represent IGP path costs, and arrows
indicate an iBGP session from a route re ector to its client. In a full-
mesh, router C would prefer routes learned from B over routes learned
from A because its IGP path cost to B is smaller. However, in the ex-
ample shown, RR prefers A, and, thus, C must also select A.
Gateway Protocol (IGP) to construct a forwarding table that maps
destination pre xes to outgoing links. Most of the exibility and
complexity of BGP routing comes from the following three areas:
Path selection: A route to a destination pre x includes attributes
such as the AS path, local preference, origin type, and multi-exit
discriminator (MED). Each router applies a decision process [1]
that consists of a sequence of rules that ranks the routes. After
preferring routes with highest local preference, smallest AS path
length, lowest origin type, and smallest MED, the decision process
favors eBGP-learned routes over iBGP-learned routes. If multiple
equally-good routes remain, the router favors the BGP route learned
from the nearest border router the egress point with the small-
est IGP path cost following the common practice of hot-potato
routing. The nal tiebreak is vendor-dependent and may depend on
the age of the routes or an arbitrary router ID.
Intra-AS route distribution: Network operators can propagate
eBGP-learned routes throughout an AS in many different ways.
4
Small networks typically have a full mesh of iBGP sessions, as
shown in Figure 2. To avoid the n
2
scaling problem, a large AS
may have a more complex iBGP topology. For example, although
a router does not normally forward iBGP-learned routes to its other
iBGP neighbors, it can be con gured as a route re ector, which
forwards routes learned from one route-re ector client to another.
A router forwards only its best route to its iBGP neighbors, making
the choices available at one router depend on decisions made by its
iBGP neighbors, as shown in Figure 3.
Routing policy: Network operators in uence path selection by
con guring import and export policies on the eBGP sessions to
neighboring domains. An import policy lters unwanted routes and
4
In most IP backbone networks, every router needs to receive BGP routing
information to construct a complete forwarding table. In a Multi-Protocol
Label Switching (MPLS) network, only the border routers need to send and
receive the BGP routes; the internal routers would simply forward packets
on label-switched paths from the ingress router to the egress point.