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 –> 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 • > 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. Inside a POP Backbone Tier 1 Distribution AS D Distribution ISP C Tier 2 Tier 3 Access Access 1.1 2.1:1 2.1:2 3.1:1:1 3.1:1:2 Nested Clouds, Tiers, Addresses Nested Address 1.1{3.1:1:2} Nested Tiers

9. Contract Switching

10. Inter-domain Struggles… When crossing domains, all bets are off.. End-to-end reliability or performance-criticality requires assurance of single-domain performance, i.e., “contract”s 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 10

11. ISP B ISP A ISP B ISP C routable datagrams ISP A ISP C ISP B contracts overlaid on routable datagrams ISP A ISP C Contract-switching: A Paradigm Shift… e2e circuits Circuit-switching Packet-switching Contract-switching

12. Stations of the provider computing and advertising local prices for edge-to-edge contracts. Stations of the provider computing and advertising local prices for edge-to-edge contracts. Edge Router Edge Router Edge Router Customers Network Core accessed only by contracts Edge Router Edge Router Edge Router Basic Building Block: Intra-domain Dynamic Contracts • Contract components • performancecomponent, e.g., capacity • financialcomponent, e.g., price • timecomponent, 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 routingat macro time-scales • path-vector contract routingat 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 • Provider initiates… • ISP C wants to advertise availability of a short-term contract link [C-B-A, 5-4-2-1, 20Mb/s, 30mins, $7.3+$3] [C-B, 5-4-2, 20Mb/s, 45mins, $6+$5] [C, 5-4, 30Mb/s, 45mins, $9] ISP B path announcement path announcement 2 ISP A 1 4 User X 3 ISP C path announcement 5 [C, 5-3, 10Mb/s, 30mins, $5] [C-A, 5-3-1, 5Mb/s, 15mins, $1.25+$1.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 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. 18

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