announcement slides and reference materials available at slides and reference materials available
TRANSCRIPT
AnnouncementAnnouncement
Slides and reference materials available at
http://www.cs.purdue.edu/homes/yau/tsinghua-course2006
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)
Stable Internet Routing Without Global Coordination
(based on Gao and Rexford)
Application of materials learned in Lecture 1
Guaranteed Convergence by Global Coordination
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
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
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
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 RelationshipsAS 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
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 ConvergenceGuidelines 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
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 ArchitectureInternet 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
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 MaintenanceBGP 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
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 SelectionBGP 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)
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 ProcessingAdvertisement 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)
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 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
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 ModelBGP Model
Clustered graph G = (N, V, E)
a(i) denotes AS of BGP speaker i
Clustered graph G = (N, V, E)
a(i) denotes AS of BGP speaker i
AS 1
AS 2 AS 3
eBGP
iBGP
BGP speaker
Route Update NotationRoute 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
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 NotationsBGP 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 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)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]]
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 SelectionDistributed 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
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 ActivationSpeaker 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
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 StateEvolution 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
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 SequenceActivation 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
(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
(2,0)(0)
(1,0)(0)
AS 0
AS 1
AS 2
originatesprefix d
Stable state: AS 1 (2,0); AS 2 (0)
Safe BGP SystemSafe 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
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 RelationshipsAS 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))
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 PoliciesRules 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
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 RelationshipsHierarchical 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
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 AGuideline 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
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 stateLemma 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
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
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
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)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
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
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
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)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
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
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 *)
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 1Proof of Theorem 1
Follows from Lemmas 1 and 2, and Lemmas 1 and 2 are not affected by either
node or link removals
Follows from Lemmas 1 and 2, and Lemmas 1 and 2 are not affected by either
node or link removals
Guideline BGuideline 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
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?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
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 GuidelinesRobustness 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
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
DiscussionsDiscussions
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
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