120 likes | 221 Vues
This study examines the influence of architectural choices on BGP path diversity in large ISPs, evaluating perceptions and identifying key factors impacting diversity. Through data collection and simulation, it sheds light on route selection dynamics and proposes strategies for enhancing path diversity.
E N D
A Comparative Study of Architectural Impact on BGP Next-hop Diversity15th IEEE Global Symposium, March 2012 Jong Han Park1, Pei-chunCheng2, Shane Amante3, Dorian Kim4, Danny McPherson5, Lixia Zhang2 1AT&T Labs 2University of California, Los Angeles 3Level-3 Communications Inc. 4NTT Communications Inc. 5Verisign Inc.
Why this work? • Large ISPs have deployed i-BGP Route Reflections for scalability • Hierarchical Route Reflection has a common perception for reducing path diversity • Is the perception correct? • What factors have most impact on path diversity? • This measurement study aims to answer the above two questions
Next-Hop Diversity: Definitions POP1 • Next-hop POP: the city in which the next-hop router is located for a given destination prefix • Next-hop AS: the neighboring AS used to reach a given destination prefix NH Router1 ASX AS1 NH Router2 POP2 ASO Prefix p NH Router3 POP3 AS2 AS3
Data collection settings • Data collected from 2 large ISPs with different i-BGP architectures • ISPFM: full-mesh i-BGP backbone • ISPRR: hierarchical Route Reflection i-BGP backbone BGP data collection POPs ISPRR ISPFM Backbone sub-AS (full-mesh) sub-AS sub-AS sub-AS iBGP node type: iBGP router iBGP node type: 1st level reflector 2nd level reflector BGP confederation 3rd level reflector Peer Reflector to Client
Next-hop diversity of the 2 ISPs • Dataset: routing table snapshot on June 03, 2010 • ISPFM (ISPRR) has ~66% (50%) prefixes with next-hop POP diversity >=9 (7) • ISPFM (ISPRR) has ~10% (34%) of all prefixes with only one next-hop POP • ISPFM has higher overall next-hop diversity than ISPRR ISPFM ISPRR
Investigating the causes for the differences • Estimating available paths based on BGP dynamics [Oliveira’09] • Identify prefixes with at least one route flap (i.e., becoming completely unreachable from all routers and becoming reachable again) • Record all paths with associated BGP attribute values • Simulate BGP best path selection at the AS level • IN: available paths to reach a given prefix • OUT: amount of eliminated paths at each step of BGP best path selection **[Oliveira’09] Quantifying Path Exploration in the Internet by Oliveira et al, Transactions on Networking 2009
Examples of path elimination in simulation BGP best path selection 1. Highest Local preference PATH 1 AS1 2. Shortest AS_PATH length PATH 2 ASO Prefix p ASX 3. Lowest Origin PATH 3 4. Lowest MED PATH 4 5. Lowest IGP cost AS3 AS2 6. More … Path diversity loss due to Topology dependent factors -ASPathLen, Next-hop POP = 2 -Local_Pref, Next-hop POP = 3 Available Next-hop POP = 4 -Origin, Next-hop POP = 2 -MED, Next-hop POP = 1
Simulation results • Dataset: updates from all backbone routers during the 1st week of June 2010 • Both ISPs suffer a significant next-hop diversity reduction • The first 2 criteria reduces up to 42% • Only minor reduction (less than 2.9%) due to topology dependent factors
Well-engineered RR placement min. diversity loss Tier-1 backbone RRs (continent) • Not all regions (or mega-POPs) are equal • Place more backbone RRs in the regions with higher prefix injection density • In case of ISPRR • For more than 50% of prefixes, RRs exist in the nearest POPs • The current RR placement is nearest for more than 85% of prefixes after eliminating paths using the top 4 BGP path selection criteria Available Tier-2 backbone RRs (regions or mega-POPs) B1 B3 B2 Tier-3 RRs (POPs) PEs Prefix p
Summary • Engineering efforts going on aiming to increase path diversity • Lack of quantitative study on existing path diversity and impacting factors • Our measurement/simulation results based on iBGP data from 2 large ISPs shed new insights: • Routing policies: main factor • Impact of different iBGP architectures insignificant • Can be further mitigated by well-engineered i-BGP topology