Transcript RCP - Princeton University

A Routing Control Platform
for Managing IP Networks
Jennifer Rexford
Computer Science Department
Princeton University
http://www.cs.princeton.edu/~jrex
Background and Interests
• Professional background
– Joined Princeton faculty in February 2005
– After 8.5 years at AT&T Labs—Research
• Work with AT&T’s backbone & large enterprises
• Tools in daily use in AT&T’s backbone
• Research interests: data networking
– Networks easier to design and operate
– IP routing and network measurement
– Division between routers and management
Today: Inside a Single Network
Shell scripts
Management Plane
• Figure out what is
Planning tools
Databases
happening in network
Configs SNMP
netflow modems • Decide how to change it
OSPF
Control Plane
Link
• Multiple routing processes
Routing
OSPF
metrics
on each router
policies
BGP
• Configuration on each router
• Many control knobs: link
OSPF
OSPF
weights, access lists, policy
BGP
BGP
FIB
FIB
Traffic Engin.
Data Plane
FIB
• Packet handling by routers
Packet • Forwarding, filtering, queuing
filters
How Did We Get in This Mess?
• Initial IP architecture
– Bundled packet handling and control
– Functionality distributed across routers
– Didn’t anticipate need for management
• Rapid growth in features
– Internet’s sudden popularity and growth
– Demands for new features
– Built as incremental extensions
• Challenges of distributed algorithms
– Some tasks are hard in a distributed fashion
Solution: Wafer-Thin Control Plane
• Decision plane: outside the routers
– All decision logic and state
– Network-wide view and objectives
– Direct control over the data plane
• Discovery plane: in the routers
– Monitors the topology
– Measures the traffic
• Data plane: in the routers
– Queues, filters, and forwards data packets
– Accepts instruction from decision plane
Achieving the New Architecture Today
• Deployability: getting from here to there
– Compatible with existing routers
– Incentives for deployment
• Speed: running fast enough
– Respond quickly to network events
• Reliability: avoiding single point of failure
– Replicate to tolerate failure
– Replicas must behave consistently
Can we do it? The short answer is… yes!
Deployability: Backwards Compatibility using BGP
• Border Gateway Protocol (BGP)
– Protocol: messages sent between routers
– Decision logic: route-selection process
– Policy: configurable rules
• The key point is
– Complex decision logic and policies
– Yet simple protocol and message format
Idea: Use BGP messages to tell the routers what to do
Deployability: Inside a Single Autonomous System (AS)
Before: conventional use of BGP in backbone network
eBGP
iBGP
After: RCP learns routes and sends answers to routers
eBGP
RCP
iBGP
Only one AS has to change its architecture!
Deployability: Across Multiple ASes
• Represents the AS to others
– Has complete view of all candidate routes
– Computes answers for the AS’s routers
• Communicates with other ASes
– Using BGP or a brand new protocol
– … while using BGP to talk to the routers
RCP
RCP
Inter-AS Protocol
RCP
iBGP
AS 1
Physical
peering
AS 2
AS 3
Routing Control Platform (RCP)
Routing Control
Platform (RCP)
Route Control
Server (RCS)
Options
Answers
BGP Engine
…
BGP
updates
…
BGP
updates
Network
Topology
OSPF Viewer
…
OSPF link-state
advertisements
Scalability: Standard Computing Platform
• Prototype on a high-end PC
– 3.2 GHz Pentium-4 with 8 GB of RAM
– Running the Linux 2.6.5 kernel
• Workload from the AT&T backbone
– Replay the BGP and OSPF messages
• Good RCP performance
– Memory usage: less than 2GB
– Speed, BGP changes: less than 40 msec
– Speed, topology changes: 0.1-0.8 seconds
Short answer: the system can keep up
Reliability: Replication and Consistency
• Replication: avoid single point of failure
– Multiple RCPs in a network
– Connected at different places
• Consistency: no explicit coordination
– Replica has full view of each partition
– Replicas perform the same algorithm on the
same data, and get the same answer
A
RCP A
A, B
B
RCP B
Example Applications
• Customer-driven route selection
– Customized load-balancing policies
– Geographic rules for route selection
• Blocking denial-of-service attacks
– “Blackhole” routes that drop traffic
– Only for routers carrying attack traffic
• Hitless maintenance
– Move traffic away from certain routers
– Before the operators bring down the routers
Project With Department of Homeland Security
• Border Gateway Protocol is important
– BGP is the glue that holds the Internet together
• BGP is extremely vulnerable
– Easy to inject false information
– Easy to trigger routing instability
• Vulnerabilities are being exploited
– Configuration errors and malicious attacks
– Route hijacking, blackholes, denial-of-service, …
• Changing to a secure protocol is hard
– Can’t have a flag day to reboot the Internet
Example: Route Hijacking
4
3
5
2
6
7
1
12.34.0.0/16
12.34.0.0/16
• Consequences for the data traffic
– Discarded: denial of service
– Snooped: violating the user’s privacy
– Redirected: identity theft, propagating false info, etc.
Solution: Incremental Deployability
• Backwards compatibility
– Work with existing routers and protocols
• Incentive compatibility
– Offer significant benefits, even to the first adopter
Routing
Control
Platform
tells
how
to forward
traffic
ASes
can
upgrade
to deploy
secure
interdomain
routing
protocol
Use
… Use
all
RCP
with
while
RCP
to
RCPs
simplify
still
to
can
using
cooperate
management
(and
BGP
avoid)
torouters
control
to detect
suspicious
and
the
enable
suspicious
legacy
routes
new
routers
services
routes
Use
Other
BGP
ASes
todetect
communicate
can
an
with
RCP
the
independently
legacy
routers
Distributed detection
Inter-AS Protocol
RCP
BGP
AS 1
RCP
RCP
AS 2
AS 3
Conclusion
• Network operations is too hard
– IP was not designed for management
– Complex, distributed operation of routers
• Must reduce complexity
– Network-wide views and objectives
– Direct control over the data plane
• New architecture is feasible
– RCP is deployable, scalable, and reliable
– RCP solves real, important problems
New opportunity to impact the future of IP networks.