Path-Vector Contract Routing

Path-Vector Contract Routing

Hasan T. Karaoglu,Murat Yuksel

University of Nevada, RenoICC’12 NGNI, Toronto

June, 2012

MotivationCurrent 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

MotivationOur 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

2

3

5

ISP A

ISP C

ISP B

1 4

[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 path request

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.

replyreply

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

ISP bTTLequal

bTTLpolicy

A 2 4

D 2 1

G 2 1

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

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

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) BGP90 c) BGP120

d) CR50 e) 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

mechanisms20

Questions?

Thank YouFor offline question: karaoglu@cse.unr.eduGoogle “Contract Switching” http://www.cse.unr.edu/~yuksem/contract-switching.htm

21