HLP: A Next Generation Interdomain Routing 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

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.

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.

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.

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.

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

Hybrid Link-State Path-Vector

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

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.

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.

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

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

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

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

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

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

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

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

iHLP Maintain communicating group Maintain customer-route consistency Maintain link-cost consistency

Conclusion BGP Failures Scalability Fault Isolation Convergence HLP Successes Scalability Fault Isolation Convergence