HLP: A Next Generation Interdomain Routing Protocol

1. HLP: A Next Generation InterdomainRouting Protocol Lakshminarayanan Subramanian* Matthew Caesar* Cheng Tien Ee*, Mark Handley° Morley Maoª, Scott Shenker* Ion Stoica* *University of California at Berkeley °University College London ªUniversity of Michigan

2. Goals of the Paper • The goals of the paper is to present an alternative to BGP for Inter-AS routing. • Why an alternative is needed. • Present the basic idea of HLP • How HLP routes data. • How HLP compares to BGP • How HLP was tested. • How HLP is implemented with actual routers • Relate work. • Most importantly, this paper is not trying to present a finished product. Instead it is trying to help start debates about what the next generation inter-domain routing protocol should look like.

3. Background • Inter-Domain Routing • Routing Algorithm should scale, be robust and converge quickly if the state changes. • Should support Policy Routing, where ISPs can have a wide range of private routing policies. • These two attributes are in conflict.

4. Background • Boarder Gateway Protocol (BGP) • Extreme position that all routing policy must be private and reveals full path information. • However routing policy can easily be deduced, therefore making it illogical to hide the information. • Also, most AS’s don’t use the full path information to route data, so again there is little need to actually do this. • BGP suffers from algorithmic problems, such as poor scalability, minimal fault isolation and slow convergence due to uninformed path exploration.

5. Hybrid Link-State Path-Vector • HLP is designed following the knowledge that while many different configurations are possible, 99% of Internet routes follow Provider-Customer relationship. • Uses information hiding to limit the scope of routing events. • With HLP we achieve greatly improved churn rate, isolation and convergence.

6. Hybrid Link-State Path-Vector • HLP uses the hierarchical structure of AS’s to hide small events in one hierarchy from all others. • HLP publishes the provider-customer model and assumes that most AS’s follow it. • Do not forward routes advertised by one peer or provider to another peer or provider • Prefer customer routes over those from peers or providers • Those that don’t follow the model are handled as exceptions. • HLP routes based on AS’s and not on prefixes. • HLP uses Link-State routing within a hierarchy and path-vector between

7. Hybrid Link-State Path-Vector

8. How HLP handles routing • All of the AS’s have Link-State Information about their local hierarchies. • FPV’s include all the peering AS’s traversed, but not information about the path taken within local AS’s • All inter-AS links have a cost that is added to the cost of the FPV • HLP models indirect peering by forwarding route advertisement over multiple links

9. HLP Information Hiding • One of the key principles of HLP is that not all information needs to be shared among different AS’s. • Don’t forward minor cost changes between peering networks. • Don’t forward minor cost changes in peering links to customers. • Hide the failure of a link between two peering AS’s that have multiple parallel links.

10. Exceptions • HLP assumes that a connection will follow the provider-customer model. • While not always the case, is in most instances • HLP treats these rare non-standard cases as exceptions • Export policy exception: An AS prefers to forward advertisements from one provider/peer to another provider/peer • Prefer customer exception: An AS route over a customer route. • In the case where a provider forwards a link to a peer, the provider-customer link is treated as a peer link (that is FPV is sent and not an LSA.) • In the case where the provider chooses a non-customer route over a customer route, HLP first propagates an advertisement that says the customer route is dead and than forwards the FPV from the peer.

11. HLP Protocol Analysis Results • Decreased churn • Isolation of events to smaller regions • Multihoming increases benefits • Lower worst case convergence time

12. Emulation Parameters • ASes use prefer customer and export-rule guidelines • Results are the lower bound on potential improvement • Inter-As link failures • Causes the most churn

13. Definitions • Isolation • Number of AS’s that can potentially be affected by a routing event • Churn • Total number of updates generated by an event • Improvement in isolation • Ratio of BGP’s to HLP’s AS’s that are affected by events

14. Churn Improvement • HLP results in 2% of the churn that BGP causes • Use of AS-prefix mapping • Cost hiding of route updates

15. Isolation Improvement • HLP isolates fault region to area 100 times smaller than BGP can • 40% of events effected less than 10 AS’s • 80% of BGP events were globally visible

16. Multihoming Improvement • Churn reduction factor: 200 • Isolation factor: 1000 • Hides link failures when multiple paths are available

17. Convergence Time • Using proof shown in paper the convergence time of the system is at most linear

18. Traffic Engineering and Policy support • Supported Methods • Prefix level route selection • Cost-based inbound traffic engineering • Other methods can also be used with extended HLP • Not Supported • Regular expressions • Negation expressions

19. iHLP • Maintain communicating group • Maintain customer-route consistency • Maintain link-cost consistency

20. Conclusion • BGP Failures • Scalability • Fault Isolation • Convergence • HLP Successes • Scalability • Fault Isolation • Convergence