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

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 2

Motivation 3

 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 4

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

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

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

Forwarding Mechanisms 8 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

Policy Support 9 Policy: Which neighbors to select? Customers, Peers, Providers How to distribute bTTL budget? More bTTL share for neighbors with better connectivity Structured Flooding ISPbTTL equal bTTL policy A24 D21 G21

Traffic Engineering 10 A D G 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 Path request NY Atlanta SF NY  SF, 40% util., A,D NY  Atlanta, 70% util., G All neighbors: {A,D,G} Selected neighbors: {A,D} Path request

Evaluation - I (Policy Support) CAIDA, AS-level, Internet Topology as of January 2011 (33,508 ISPs) Trial with 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) 11

Results – Path Exploration 12 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

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

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

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

Evaluation - II (Reliability) CAIDA, AS-level, Internet Topology as of January 2011 (33,508 ISPs) Trial with 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 16

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

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 18

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

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 20

Questions? Thank You For offline question: Google “Contract Switching” 21