Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Path-Vector Contract Routing Hasan T. Karaoglu, Murat Yuksel University of Nevada, Reno ICC’12 NGNI, Toronto June, 2012."— Presentation transcript:

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 2

3 Motivation 3

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

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

6 Opportunistic Path Vector Routing 6 User X 2 3 5 ISP A ISP C ISP B 14 [5, A-B, 1-2-4, 15- 20Mb/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, 1-2-4-5, 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]

7 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

8 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

9 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

10 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

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) 11

12 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

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

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

15 Results – Message Cost 15 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 16

17 Results – Diversity / Reliability 17 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 18

19 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

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 20

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


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

Similar presentations


Ads by Google