Announcement
 Slides and reference materials available at
http://www.cs.purdue.edu/homes/yau/tsinghua-course2006
Stable Internet Routing Without
Global Coordination
(based on Gao and Rexford)
Application of materials learned in Lecture 1
Guaranteed Convergence by
Global Coordination
 Internet routing registry
 Require all routing policies be registered
 Check for consistency
 Problems
 ISPs not willing to reveal their policies
 Consistency check is NP complete
 Possible divergence after policy change or node / link
failure
Guaranteed Convergence by
Distributed Approach
 Prescription of set of guidelines for ASes to follow
 Certain policies are disallowed
 Observance of guidelines ensures convergence
 Independent of underlying network topology
 Guidelines based on
 Internet hierarchical structure
 Commercial relationships between ASes
AS Commercial Relationships
 Customer-provider
 Customer pays provider for service
 Peer-to-peer
 Agreement between ASes to exchange traffic between
their customers
 Frequently no exchange of money
 Relationship assumed equal usage
 Peering agreements usually treated as business secrets
 Backup
 Service in case of failures
Guidelines for Convergence
 Routing preferences
 Routing via customer link preferred over provider /
peer link
 Backup links always least preferred
 AS free to choose local policies within each
preference class
 Guidelines not in BGP, but agree with ISP routing
practice
 Registry can be simplified to check only
relationships between AS pairs
Internet Architecture
 ASes are autonomous
 Detailed knowledge of topology within AS
 Limited knowledge of topology about other ASes
 ASes interconnected at public IXPs or dedicated
point-to-point links
 Example IXPs: Mae-East, Mae-West
 Connectivity does not imply flow of traffic
 Routes must be established through BGP
BGP Route Maintenance
 Routes constructed by propagation of BGP
advertisements
 advertisement = prefix + attributes
 Upon receipt of advertisement, BGP speaker
decides whether to use path, and whether to
propagate path
 Routes removed by BGP withdrawals
 Withdrawal leads to sequence of withdrawals
by upstream ASes using path withdrawn
BGP Route Selection
 BGP allows many routing policies
 Local preference (reflecting AS relationships)
 Community attribute (hint to neighbor on
preference that should be given to a route)
 MED (control over how traffic from neighbors
enters AS)
 Otherwise, neighbors use hot potato routing
 AS path prepending (ingress traffic
engineering)
Advertisement Processing
 Import policies
 Which routes to consider for use
 Path selection
 Which imported route to use as best route
 Export policies
 Whether best route is advertised to a neighbor
 If so, what to advertise? (route can change since
their attributes can change)
BGP Protocol Dynamics
 Route convergence not guaranteed
 Group of ASes may continually advertise and
withdraw routes to a prefix because of policy
conflicts
 Convergence concepts
 Group of ASes in stable state when no AS
would change its routes
 Safe BGP system guarantees that group of ASes
will reach stable state
BGP Model
 Clustered graph G = (N, V, E)
eBGP
iBGP
BGP speaker
AS 1
AS 2
 a(i) denotes AS of BGP speaker i
AS 3
Route Update Notation
 For route update r






r.prefix: destination prefix
r.next_hop: next hop address
r.as_path: as path
r.local_pref: local preference
r.med: multiplex exit discriminator
r.c_set: community set
BGP Processing Notations
 BGP speaker v, eBGP session between two BGP
speakers
 Import
 For set of updates R, set of updates remaining after
applying implicit import policy of v on edge l:
im_import(l,v)[R]
 For explicit update policy: ex_import(l,v)[R]
 Overall import policy:
 import(l,v)[R] = ex_import(l,v)[im_import(l,v)[R]]
 Route selection
 For set of route updates S, best route for each prefix
picked from S: Select(S)
BGP Processing Notations (cont’d)
 Export
 BGP speaker u applies implicit export policy on
link l to neighbor v: im_export(l,u)
 For explicit export policy: ex_export(l,u)
 Overall export policy:
 export(l,u)[R] = ex_export(l,u)[im_export(l,u)[R]]
Distributed Path Selection
 Distributed and asynchronous process by all
BGP speakers, for a prefix d
 Triggered by advertisements / withdrawals
 Sufficient for BGP speaker to remember
only its own best route
 System state is vector s = (s1,…sn), where si
is route chosen by speaker i
Speaker Activation
 System state changes when BGP speaker(s) apply
route selection process
 Speaker is activated when it has considered
everything for triggering route s; i.e., it has
applied
 Export policies of all its neighbors
 Import policies of itself
 BGP route selection
 Activation order not deterministic due to
asynchronous execution of protocol
 At given time, a subset A of speakers are activated
Evolution of System State
 System state s changes into next state s’
 For i  A
 s’i = BestRoute(i,s) (best route chosen by i based on
routes chosen by each speaker)
 For i  A
 s’i = si
 s ->A s’ denotes state change from s to s’ based on
activation set A
 State s is stable iff s ->A s for any A
Activation Sequence
 (j) denotes j-th activation in activation sequence

 (Infinite) sequence is fair if it has infinitely many j s.t. i
 (j), for each speaker i
 BGP system converges for  and s0 if there is
finite j s.t. s0 ->(1) s1 … ->(j) sj and sj is stable
 BGP system may have a stable state but is not
converging
Stable state: AS 1 (2,0); AS 2 (0)
AS 1
(2,0)
(0)
AS 0
originates
prefix d
AS 2
(1,0)
(0)
Safe BGP System
 BGP system is safe if it has a stable state
and converges under any fair activation
sequence and any initial state
 BGP system is inherently safe it it is safe
and remains safe after removing any nodes /
edges
AS Relationships
 Customers, providers, and peers of AS a:
customer(a), provider(a), peer(a)
 Route r is customer (provider, peer) route of
a if next hop AS in r.as_path is in
customer(a) (provider(a), peer(a))
Rules for BGP Export Policies
 Export to provider
 Can export own routes and routes of customers, but not
routes from providers / peers
 AS does not provide transit for its provider
 Export to customer
 Can export own routes, and routes from providers /
peers
 AS provides transit for its cusomers
 Export to peer
 Same as for provider
Hierarchical Relationships
 Customer-provider relationship assumed
hierarchical
 In practice, AS chooses a larger AS as provider
 Any direct / indirect provider of u cannot be a
customer of u
 Provider-to-customer graph is a DAG
Guideline A
 AS prefers a route via a customer to a route
via a provider / peer
 Set by r.loc_pref
 Theorem 1: For a BGP system that has only
customer-provider and peer-peer
relationshps, if all ASes follow A, the
system is inherently safe
Lemma 1: The BGP system has a stable state
 Activate ASes in a two phase activation sequence
*
 In phase 1, AS selects a customer route if one is
available, following guideline A; accomplished by
activating ASes by customer-provider partial order
 In phase 2, ASes that do not have a customer route after
Phase 1 get provider or peer routes; accomplished by
activating ASes in provider-customer partial order
Claim 1 for Lemma 1: A Phase 1 BGP speaker
reaches a stable state after its activation in phase 1
 Proof by induction on the order that Phase 1
speakers are activated in phase 1
 Let Phase 1 BGP speaker i belong to ASn
 Suppose all Phase 1 speakers that belong to an AS
preceding ASn in Phase 1 reach a stable state after
activation (induction hypothesis)
 Speaker i selects best route from amongst its
customer routes
 Each such customer precedes ASn in *; either has
reached a stable state or does not get a customer route
in Phase 1
Claim 1 (cont’d)
 A customer that does not get a customer
route in Phase 1 does not export its route to
i (by export policy rule)
 Such a customer’s routing decisions do not
affect i’s decisions
Claim 2 for Lemma 1: A Phase 2 speaker reaches a
stable state after its activation in Phase 2
 Let AS0 be first Phase 2 speaker activated in Phase
2
 Since AS0 is in Phase 2, its BGP speakers can only
get routes from its peers / providers
 For the peers, they are either stable after Phase 1 (if
they got a customer route), or they do not export their
routes to AS0 (if their best route is a provider / peer
route)
 For the providers, they must be phase 1 providers, and
hence already stable when AS0 is activated
Claim 2 (cont’d)
 Let Phase 2 speaker i belong to ASn
 Suppose all BGP speakers that belong to an AS
preceding ASn in Phase 2 reach a stable state after
their activation in Phase 2 (induction hypothesis)
 Since no customer route was learned in Phase 1, i
must select route from its providers / peers
 Each provider has already reached stable state (by *)
 Each peer is either Phase 1 AS or Phase 2 AS
 If phase 1, peer’s route is already available to i when i is
activated
 If phase 2, peer selects route from its providers / peers; such a
route will not be announced to i
Lemma 2: The BGP System Converges to Stable State for
Any Initial State and Fair Activation Sequence
 Given any fair activation sequence , proof by
induction on ASes, in same order of ASes in *
 Originating AS stable after first activation
 Suppose all speakers stable for ASes preceding ASn
after (t)
 Find t’ s.t. all speakers in ASn activated at least once
between t and t’; these speakers all become stable after
(t’) (received all updates as in *)
Proof of Theorem 1
 Follows from Lemmas 1 and 2, and
 Lemmas 1 and 2 are not affected by either
node or link removals
Guideline B
 Assumption P (constrained peer-peer
relationships)
 Peering only between similar ASes; therefore …
 ASes do not peer with their direct / indirect providers
 Guideline A can be relaxed to Guideline B:
 Peer route never more preferred than customer route
 Provider route always less preferred than customer
route
 Under Assumption P, BGP system inherently safe
if all ASes follow Guideline B
What About Backup Links?
 If route does not have a backup link, follow
Guidelines A and B, and give them higher local
preferences than the backup local preference
 If route has a backup link, give it the backup local
preference
 All backup links have the same local preference
 Shortest paths first routing among the backup paths
 Restriction can be relaxed
Robustness of Guidelines
 Safety guidelines are independent of
underlying network topology
 Node / link failures
 Relationship changes
 Failures / changes trigger exchanges of
route information, but guidelines ensure
convergence after the changes
Discussions
 AS relationships between different destination
prefixes do not interact
 Possible to have different policies for different prefixes
(as long as guidelines are obeyed)
 Approach avoids instability
 Peace of mind; effective despite dynamic operating
conditions; but
 Can be overly conservative; prevents otherwise useful
policies
 Alternative dynamic approach possible to detect
and resolve conflicts when necessary