Path-Vector Contract Routing

1. Path-Vector Contract Routing Hasan T. Karaoglu, Murat Yuksel University of Nevada, Reno ICC’12 NGNI, Toronto June, 2012

2. Motivation • Current Architectural Problems • Rigid SLA structure • bureaucracy, contract term , i.e. duration • Lack of expression capability in routing • user demand, service description, topology representation • Implications • Workarounds for Multi-domain QoS • CDN, Overlay Networking, Aggressive Traffic Engineering • Sub-optimal Routing and Loss-of Market for ISPs • Best-effort Service, Commoditization ,and Revenue Stagnation

3. Motivation

4. Motivation • Our previous work • “On the Scalability of Path Exploration Using Opportunistic Path-Vector Routing”, ICC NGN 2011, Kyoto • “set-of-links” representation of an ISP • “end-to-end path” by concatenating contract links • “multi-domain, multi-metric” negotiation of paths • scalable (control traffic, state) and high performance • In this work, we show: • Policy support and policy aspects • Traffic Engineering Capabilities and Reliability

5. Outline • Motivation • Opportunistic Path Vector Routing • Evaluation • Policy Support • Reliability • Traffic Engineering • Conclusion

6. Opportunistic Path Vector Routing [5, A, 1-2, 15-30Mb/s, 15-30mins, $8] [5, 10-30Mb/s, 15-45mins, $10] [5, A-B, 1-2-4, 15-20Mb/s, 20-30mins, $4] ISP B path request path request 2 reply reply [A-B-C, 1-2-4-5, 20Mb/s, 30mins] 1 4 ISP A User X reply 3 ISP C path request 5 [5, A, 1-3, 5-10Mb/s, 15-20mins, $7] Paths to 5 are found and ISP C sends replies to the user with two specific contract-path-vectors. Paths to 5 are found and ISP C sends replies to the user with two specific contract-path-vectors. [A-C, 1-3-5, 10Mb/s, 15mins]

7. Forwarding Mechanisms YES Destination in Local Neighborhood Bloom Filter Based Recursive Route Resolution NEXT HOP PATH INQUIRY NO • Parametric Gossiping • Select a subset of neighbors • ISP Policy • Traffic Engineering • Pure Random • Forward Path Inquiry Smart Randomized Forwarding

8. Forwarding Mechanisms bTTL: How many copies of discovery packet will be made and forwarded? Provides caps on messaging cost. dTTL: Time to Live, Hop-Count Limit MAXFWD: Max. number of neighbors to be forwarded

9. Policy Support Policy: Which neighbors to select? Customers, Peers, Providers How to distribute bTTL budget? More bTTL share for neighbors with better connectivity Structured Flooding

10. Traffic Engineering A SF NY  SF, 40% util., A,D NY Atlanta, 70% util., G All neighbors: {A,D,G} Selected neighbors: {A,D} Path request D Path request NY G Atlanta Traffic Engineering: Which neighbors to select? Traffic levels for virtual links connecting ingress and egress routers of PoPs Combined intra- and inter- domain traffic engineering Choose neighbors at egress end as next hop for path exploration

11. Evaluation - I (Policy Support) • CAIDA, AS-level, Internet Topology as of January 2011 (33,508 ISPs) • Trial with 10000 ISP Pair (src,dest), 101 times • With various ISP cooperation / participation and packet filtering levels • NL: No local information used • L: Local information used (with various filtering) • bTTL budget distributed over centrality (roughly how well connected neighbors are)

12. Results – Path Exploration As budget increases with BTTL and MAXFWD, PVCR becomes robust to filtering Simple policy of favoring well connected neighbors significantly increase path exploration success under filtering

13. Results - Diversity Tens of paths discovered favoring multi-path routing and reliability schemes. Policy forwarding decrease randomness and path diversity consequently

14. Results – Path Stretch Betweenness Centrality Policy does not have significant effect on path stretch

15. Results – Message Cost Structured Flooding of Path Inquiry Packets thanks to Centrality Policy significantly reduces control traffic.

16. Evaluation - II (Reliability) • CAIDA, AS-level, Internet Topology as of January 2011 (33,508 ISPs) • Trial with 10000 ISP Pair (src,dest), 101 times • Total Graph Diversity (TGD) indicator [0,1] • Defined by J. Rohrer et al., IEEE DRCN’09 • Considers both edge and vertex disjointness • Calculate TGD on all discovered paths between source and destination ISPs

17. Results – Diversity / Reliability PVCR provides high reliability for multi-path routing by exploring many disjoint paths

18. Evaluation - III (TE) • Packet-level simulation on SSFNet Simulator • Overlay implementation on BGP • 10x10 Grid Topology • 9900 flows, paths torn down every 30 mins. • Volume of traffic at various link utilization levels • MAXFWD=2, bTTL=128 • Congestion pricing • Average price of bw displayed on maps for BGP managed and PVCR managed scenarios

19. Results - TE Multi-hop negotiation with PVCR provides coordinated TE mechanisms eliminating hot-spots a) BGP50 b) BGP90 c) BGP120 Smart random forwarding provides an inherent load-balancing mechanism f) CR120 d) CR50 e) CR90

20. Conclusion • PVCR depends on: • Set of link abstraction of ISPs • Enables multi-hop, multi-metric negotiation of paths with path inquiries • Limited local state • Smart randomized forwarding of path inquiries • PVCR provides: • Flexible policy tools • Multi-hop coordinated Traffic Engineering mechanisms

21. Questions? Thank You For offline question: karaoglu@cse.unr.edu Google “Contract Switching” http://www.cse.unr.edu/~yuksem/contract-switching.htm