1 / 20

HLP: A Next Generation Interdomain Routing Protocol

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.

kmorey
Download Presentation

HLP: A Next Generation Interdomain Routing Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related