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: [email protected] “Contract Switching” http://www.cse.unr.edu/~yuksem/contract-switching.htm
21
Top Related