1 route control platform – ieee ccw 2004 route control platform making an as look and act like one...

Route Control Platform – IEEE CCW 2004

1

Route Control PlatformMaking an AS look and act like one router

Aman Shaikh

AT&T Labs - Research

IEEE CCW 2004

Matt Caesar (UC Berkeley)Don Caldwell (AT&T Labs – Research)

Nick Feamster (MIT)Jennifer Rexford (AT&T Labs – Research)

Kobus van der Merwe (AT&T Labs – Research)


2

BGP = “Broken” Gateway Protocol???• BGP is broken

– It converges slowly– At times it does not converge at all– It causes routing loops and deflections inside an AS– It’s misconfigured frequently– Traffic engineering is hard with BGP

• Fixing BGP is hard– Incremental fixes

• Makes BGP even more complicated

– New architectures and inter-domain protocols• Deployment is almost impossible


3

What are the Fundamental Problems?• AS is a logical entity for inter-domain routing

(i.e. BGP) and yet BGP state and logic are decomposed across routers inside an AS– No router has complete BGP state– Each router makes routing decision based on partial

and incomplete state

• BGP interacts in odd ways with other protocols– Most notably with the IGP (Interior Gateway

Protocol) running inside an AS


4

Fixing the Fundamental Problems• Treat the AS as a single logical entity

– Compute routes using AS-wide state

• Control routing protocol interactions

Principles for inter-domain routing!


5

Applying the Principles:Route Control Platform (RCP)

• Represents an AS as a single logical entity– Complete view of AS’s routes

– Computes routes for all routers inside an AS• Routers no longer have to compute routes

• Controls BGP-IGP interactions• Exchanges routing information with RCPs in other ASes

AS 3AS 2AS 1

iBGP

Physicalpeering

Inter-AS ProtocolRCP RCP RCP


6

The rest of this Talk: The Case for RCP• How current routing infrastructure violates the

principles of inter-domain routing– Treat the AS as a single logical entity– Control routing protocol interactions

• Potential deal-breakers for RCP– Backwards compatibility and deployment incentives– Scalability and reliability

• Related work (or…haven’t we seen this before?)– Route reflection and route servers– Overlay networks


7

Routing in the Internet• Internet is a collection of Autonomous Systems

(ASes)– BGP : routing between ASes– IGP (Interior Gateway Protocol): routing within AS

• Example: OSPF, IS-IS, RIP

AS1 AS2

AS3 AS4 AS5

OSPF

OSPFRIPOSPF

IS-ISBGP

BGPBGP

BGP

BGP BGP

BGP


8

BGP Route Distribution inside AS• Use of iBGP (internal BGP) for route distribution• Routers have to form a full mesh of iBGP sessions

– Full mesh does not scale beyond few tens of routers

• Use of “route reflectors” to solve scalability problem– Leads to information hiding

– Scalability at the expense of visibility

iBGP

iBGPRouteReflectors


9

d

11 10

A B

C

BGP-IGP Interaction• BGP route selection process uses IGP costs to tie-break

between equally good egress points– If multiple egress points, choose the one with shortest IGP

path (known as “hot potato” routing)

• Once egress-point is selected, BGP relies on IGP to reach the egress point

d

9 10

A B

C Path cost change due tofailure, traffic engineeringor maintenance


10

Example of a Forwarding Loop

RR1 RR2

C1 C2

3 3

1

1 1

d

C1 learns BGP route to destination from RR1C2 learns BGP route to destination from RR2

C1 sends packets to RR1 via its IGP shortest path which traverses C2

Persistent forwarding loop

C2 sends packets to RR2 via its IGP shortest path which traverses C1


11

Avoiding Forwarding Loops with RCP

• RCP learns all externally learned routes• Computes consistent router-level paths• Benefits:

– Intrinsic loop freedom and faster convergence– RCP does not have to stick to BGP decision process

• Can “pin” paths for traffic engineering and other purposes

RR1 RR2

C1 C23 3

1

1 1

d

“RR2”“RR2” RCP


12

Deployment in Three Steps

• Two key issues– Backward compatibility

– Deployment incentives

AS 3AS 2AS 1

iBGP

Physicalpeering


iBGP

eBGP


13

Phase 1: Control over Protocol Interactions

iBGP

eBGP

Before: conventional iBGP

iBGP

eBGP

After: RCP gets “best” iBGP routes (and IGP topology)

Only one AS has to change its architecture!

RCP


14

Phase 1 Application: Controlling Path Changes

BGP routes take “nearest exist” (shortest IGP path)Failures or maintenance can change IGP (path) weights

Exit point can also changeTraffic shifts, convergence delay, congestion

d

9 10 11 10A

A BB

C CPath cost change due tofailure, traffic engineeringor maintenance

d


15



RCP can “pin” exit points as IGP weights change

11 10

A B

CPath cost change due tofailure, traffic engineeringor maintenance

RCP


16

Phase 2: AS-wide Selection and Policy

iBGP

eBGP

Before: RCP gets “best” iBGP routes (and IGP topology)

After: RCP gets all eBGP routes from neighbors

iBGP

eBGP

RCP

RCP


17

Phase 2 Application: Centralize Configuration

Sprint UUNet

A C10.0.0.1 192.168.0.1

Simple policy: “Don’t advertise routes learned from UUNet to Sprint”Configuration is decomposed, so routes must carry state

neighbor 192.168.0.1 route-map IMPORT-C inroute-map IMPORT-C permit 10 set community 0:1000

Assign routes “From UUNet” tag at router C

ip community-list 1 permit 0:1000neighbor 10.0.0.1 route-map EXPORT-A outroute-map EXPORT-A deny 10 match community 1

Don’t send route with “From UUNet” tag to Sprint at router A


18

• RCP implements policies for entire AS– Knows about sessions to all other ASes– Implements policies in terms of relationship with

Ases• Today’s router configuration cannot capture this

• Benefits– Simpler configuration– Do not have to tag routes with state

Sprint UUNet

A C10.0.0.1 192.168.0.1

RCP

Phase 2 Application: Centralize Configuration


19

Phase 3: All ASes have RCPsBefore: RCP gets all eBGP routes from neighbors

iBGP

eBGP

After: ASes exchange routes via RCP

RCP

AS 3AS 2AS 1

iBGP

Physicalpeering



20

Phase 3 Application: More Flexible Routing

• Better network management– Diagnostics and trouble-shooting

– Routing co-located with other information (e.g. traffic)

– Ability to reason about an AS as a single entity

• Protocol Improvements– Routing based on optimization of resources (or some other

criteria) instead of kludgy things like “hot-potato”

– Attaching prices to routes

– Inter-AS negotiation of exit points

– Overlay routing informed by IP-layer information

• Your application here…


21

Scalability and Robustness• Can RCP scale?

– We have a prototype implementation• Single-box RCP can handle AS-wide BGP load• OSPF changes can be troublesome!

– Centralized != unable to scale

• Is RCP a single point of failure?– RCP can be implemented using distributed system

insights– Consistency (mostly) a non-isssue

• Guarantee from OSPF/IS-IS operation:– “Either an RCP replica has a complete view of network

(partition) or no view; but never a partial view”


22

Is RCP basically a Route Reflector?• Yes, but it’s a better route reflector

• “Customized” routing decisions for clients– Route reflectors do not compute routes from client’s

perspective– Route reflectors do not emulate a “full mesh”

• Routing decisions based on complete visibility– Guaranteed correct routes

• Replication is dictated by system issues


23

RCP also looks a lot like…• A “route server”

– Route arbiter: looked at applying policy at exchange points

– AS agents• RCP can act as an AS agent; can answer queries for the AS

• An overlay network– Most previous work is in data overlays– RCP is a control overlay

• Hierarchical routing is about control overlays

– RCP could give more information and control to data overlays• RCP has AS-wide information and direct control over paths

taken through the AS


24

Conclusions• RCP embodies two principles for inter-domain

routing– Treat an AS as a single logical entity

• Compute consistent routes using complete AS-wide view

– Control routing protocol interactions

• Benefits– Simpler, more expressive configuration– Intrinsic robustness: no loops, faster convergence– Enable new applications and innovations

• Opportunity for new traffic engineering applications


25

More informationFDNA 04 paper“The Case for Separating Routing from Routers”Nick Feamster, Hari Balakrishnan, Jennifer Rexford, Aman Shaikh,

Kobus van der Merwe

http://www.research.att.com/~ashaikh/publications.html

Questions??


26

Backup


27

Phase 2 Application: Efficient Aggregation

192.168.0.0/23192.168.0.0/24

192.168.0.0/23192.168.1.0/24

192.168.0.0/23 (??) 192.168.0.0/23 (??)iBGP

eBGP

Aggregation curbs routing table growth

Routers can’t know which routers need more specific routes


28

Phase 2 Application: Efficient Aggregation

192.168.0.0/23192.168.0.0/24

192.168.0.0/23192.168.1.0/24

192.168.0.0/23 192.168.0.0/23

Aggregation curbs routing table growth

192.168.0.0/24 192.168.1.0/24

192.168.0.0/23192.168.0.0/23

RCP

RCP can determine which routers need more specific routesand which routers can do away with less specific routes


29



Exit point can also changeTraffic shifts, convergence delay, congestion

A B

C D


30



RCP can “pin” exit points as IGP weights change

RCPA B

C D

1 route control platform – ieee ccw 2004 route control platform making an as look and act like one...

Documents

bgp slide

bgp route distribution

route control platform

bgp state

complete bgp

route reflection

route distribution routers

ibgp internal bgp