RAIDER: Responsive Architecture for Inter-Domain Economics and Routing

1
RAIDER Responsive Architecture for Inter-Domain
Economics and Routing

• Nirmala Shenoy, Rochester Institute of Technology
• Murat Yuksel, University of Nevada Reno
• Aparna Gupta, Koushik Kar, Rensselaer Polytechnic
  Inst
• Victor Perotti, Rochester Institute of Technology
• Manish Karir, Merit Networks
• National Science Foundation funded..

2
Outline

• Goals of RAIDER gt Future Internet
• Components of RAIDER
• Networking Component
• Floating Cloud Tiered Internetworking Model
• Service Provisioning Component
• Contract-Based Inter Domain Routing
• Economic Component
• Inter-Domain Economics and Risk Management
• Summary
• Position paper Individual results

3
Goals of RAIDER

• An internetworking architecture
• Highly Flexible and Scalable
• Technically and Economically -
• Respond to future needs of Network Users and
  Providers

4
RAIDER Technical and Economic Components
Inter-Domain Economics and Risk Management

• Floating Cloud Tiered Internetworking Model
• Contract Switching

5
Floating Cloud Tiered (FCT) Internetworking Model

• Technically Responsive Architecture
• Modularity
• Granularity
• Structure to leverage
• High Interconnections
• Address mechanism
• gt Implement structure, avoid logical address
  based routing

6
FCT Internetworking Model

• Building Blocks
• Network Clouds ISPs, POPs, Backbone routers
• Nested Clouds
• Tiers Global Level ISPs, AS backbone,
  distribution, access
• Nested Tiers

7
FCT Applied ISP Level
8
Nested Clouds, Tiers, Addresses
Nested Address 1.13.112
Nested Tiers
9
Contract Switching
10
Inter-domain Struggles
10

• When crossing domains, all bets are off..
• End-to-end reliability or performance-criticality
  requires
• assurance of single-domain performance, i.e.,
  contracts
• efficient concatenation of single-domain
  contracts
• Inter-domain routing needs to be aware of
  economic semantics
• contract routing risk management
• We address translation of these struggles to
  architectural problems

11
Contract-switching A Paradigm Shift
e2e circuits
Circuit-switching
Packet-switching
Contract-switching
12
Basic Building Block Intra-domain Dynamic
Contracts

• Contract components
• performance component, e.g., capacity
• financial component, e.g., price
• time component, e.g., term

13
Contract Link

• An ISP is abstracted as a set of contract links
• Contract link an advertisable contract
• between peering/edge points i and j of an ISP
• with flexibility of advertising different prices
  for edge-to-edge (g2g) intra-domain paths

capability of managing value flows at a finer
granularity than point-to-anywhere deals
14
How to Achieve e2e QoS?

• Contract Routing
• Compose e2e inter-domain contract paths over
  available contract links satisfying the QoS
  requirements
• Calculate the contract paths by shortest-path
  algos with metrics customized w.r.t. contract QoS
  metrics
• Two ways
• link-state contract routing at macro time-scales
• path-vector contract routing at micro time-scales
• Monitor and verify that each ISP involved in an
  e2e contract path is doing the job
• Punish the ISPs not doing their job, e.g. as a
  money-back guarantee to the others involved in
  the e2e contract path

15
Path-Vector Contract Routing Micro-level,
On-demand, Reactive
C-B-A, 5-4-2-1, 20Mb/s, 30mins, 7.33
C-B, 5-4-2, 20Mb/s, 45mins, 65
C, 5-4, 30Mb/s, 45mins, 9
ISP B
path announcement
path announcement
2
ISP A
1
4
User X

• Provider initiates
• ISP C wants to advertise availability of a
  short-term contract link

3
ISP C
path announcement
5
C, 5-3, 10Mb/s, 30mins, 5
C-A, 5-3-1, 5Mb/s, 15mins, 1.251.2
16
Path-Vector Contract Routing Micro-level,
On-demand, Reactive

• User initiates
• User X wants to know if it can reach 5 with
  10-30Mb/s for 15-45mins in a 10 budget

5, 10-30Mb/s, 15-45mins, 10
5, A, 1-2, 15-30Mb/s, 15-30mins, 8
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
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.
5
5, A, 1-3, 5-10Mb/s, 15-20mins, 7
A-C, 1-3-5, 10Mb/s, 15mins
17
Contract Routing over FCT Model
17
Contracting at tier-1 long time-scale
ISP A
ISP B
Tier 1
ISP C
ISP E
ISP D
Tier 2
Tier 3
Organization A
Organization B
Organization C
Contract between two tier-2 networks medium
time-scale
Contract between two tier-3 networks short
time-scale
18
Deployment Issues
18

• How to motivate ISPs to participate?
• ISPs are very protective of their contracting
  terms due to competition.
• But, BGP has similar risks too..
• Observation of opportunity costs
• PVCR can be done at will..
• Not much to loose if ISPs participate with their
  leftover bandwidth.
• Monitoring and verification of contracts
• Who is breaking the e2e performance?
• Active measurements can be OK for LSCR, but PVCR
  needs lightweight techniques.

19
Summary

• A Future Internet Architecture
• Technically responsive
• Tested on Emulab / ProtoGENI
• 21 node 3 tiers
• Economically responsive
• Presented some details
• Collaboration on Integration ongoing.

20
Questions