NIRA: A New Internet Routing Architecture

Transcription

1 NIRA: A New Internet Routing Architecture Xiaowei Yang MIT Computer Science and Artificial Intelligence Laboratory yxw@lcs.mit.edu 1

2 Why a New Internet Routing Architecture? Users have little control over routes. BGP chooses a default route. User choice fosters competition. Telephone system A small number of local ISPs Stagnation in introducing new services, e.g., lack of end to end QoS BGP has a number of problems. Slow convergence [Labovitz00], slow reaction to failures [Feamster03], path selection based on simple metrics [Spring03] User selected overlay routes have better quality. Detour [Savage99], RON [Andersen01] Xiaowei Yang, MIT 2

3 What's NIRA about? ``Dumb'' routers, intelligent users Routers selectively propagate topology information Forward or drop packets based on policy configurations. Route selection is done by end users. ``User'' is an abstract entity, e.g., a software agent ``Domain-level'' choices Domain-level choices encourage ISP competition. Individual domain's decision to offer ``router-level'' choices or not. NIRA is different from IP source routing. IP source routing does not address route discovery. Enable new services: QoS route selection, multipath routing (I-ATC) Xiaowei Yang, MIT 3

4 Outline Network Model Overview of design components and requirements Design details Related Work Conclusion Xiaowei Yang, MIT 4

5 NIRA's Network Model R1 R2 R3 b000:1::/32 a000:1:1::/48 X a000:2:1::/48 a000:3 :1::/48 N1 N2 N3 Customer Provider Peer Peer NIRA is optimized for the special structure of the Internet. Xiaowei Yang, MIT 5

6 Overview of Design Components and Requirements a000:1:1::/48 a000:2:1::/48 N1 R1 R2 N2 R3 b000:1::/32 N3 a000:3:1::/48 Design components Route discovery and selection Route representation Route failure handling Provider compensation Design requirements Scalability Efficiency Robustness Heterogeneous user choices Practical provider compensation Xiaowei Yang, MIT 6

7 Provider-rooted Hierarchical Addressing a000:1:1::/48 a000:2:1::/48 N1 R1 R2 N2 R3 b000:1::/32 N3 a000:3:1::/48 Fixed length addresses Distinct address prefixes for top-level providers Recursive subdivision for each customer Xiaowei Yang, MIT 7

8 Provider-rooted Hierarchical Addressing a000:1:1::/48 a000:2:1::/48 N1 R1 R2 R3 N2 b000:1::/32 N3 a000:3:1::/48 Fixed length addresses Distinct address prefixes for top-level providers Recursive subdivision for each customer Xiaowei Yang, MIT 8

9 Provider-rooted Hierarchical Addressing R2 a000:2 a000:1 :1::/48 :1::/48 a000:2::/32 N1 R1 N2 R3 b000:1::/32 N3 a000:3:1::/48 :1::/48 :1::/48 Fixed length addresses Distinct address prefixes for top-level providers Recursive subdivision for each customer Xiaowei Yang, MIT 9

10 Provider-rooted Hierarchical Addressing R1 R2 a000:2 a000:1 :1::/48 :1::/48 a000:2::/32 R3 N1 N2 N3 b000:1::/32 a000:3:1::/48 Fixed length addresses Distinct address prefixes for top-level providers Recursive subdivision for each customer Xiaowei Yang, MIT 10

11 Provider-rooted Hierarchical Addressing a000:1:1::6c1a a000:2:1:: 6c1a R1 R2 R3 a000:2 a000:1 :1::/48 :1::/48 a000:2::/32 N1 Fixed length addresses N2 b000:1::/32 N3 a000:3:1::/48 a000:3:1::2ec5 b000:1:1::2ec5 Distinct address prefixes for top-level providers Recursive subdivision for each customer Xiaowei Yang, MIT 11

12 Efficient Route Representation a000:1:1::/48 a000:2:1::/48 N1 R1 R2 N2 a000:2::/32 R3 b000:1::/32 N3 a000:3:1::/48 a000:1:1::6c1a a000:3:1:: 2ec5 a000:2:1:: 6c1a b000:1:1::2ec5 A ``valley-free'' route can be represented by two addresses. Route ``N1 R1 R3 N3'' can be represented as a000:1:1::6c1a and a000:3:1::2ec5 Source routing header for more complicated cases Xiaowei Yang, MIT 12

13 Scalable Route Discovery Route discovery is divided into two halves. R1 R2 R3 b000:1::/32 a000:1:1::/48 a000:2:1::/48 a000:3:1::/48 N1 N2 N3 a000:3:1::2ec5 b000:1:1::2ec5 Topology Information Propagation Protocol (TIPP) tells his ``uphill'' routes. Tell me s addresses NRRS Server s addresses are a000:1:1:: 6c1a a000:2:1::6c1a Name-to-Route-Resolution service (NRRS) tells the addresses of. Xiaowei Yang, MIT 13

14 Topology Information Propagation Protocol (TIPP) R1 R2 R3 b000:1::/32 a000:1:1::/48 a000:2:1::/48 a000:3:1::/48 N1 N2 N3 a000:3:1::2ec5 b000:1:1::2ec5 Policy-based, link-state like protocol Routers selectively propagate topology information. Messages do not propagate globally. An average user has less than 20 address prefixes. Xiaowei Yang, MIT 14

15 Topology Information Propagation Protocol (TIPP) R1 R2 R3 b000:1::/32 a000:1:1::/48 a000:2:1::/48 a000:3:1::/48 N1 N2 a000:3:1::2ec5 b000:1:1::2ec5 Policy-based, link-state like protocol N3 Routers selectively propagate topology information. Messages do not propagate globally. An average user has less than 20 address prefixes. Xiaowei Yang, MIT 15

16 Topology Information Propagation Protocol (TIPP) R1 R2 R3 b000:1::/32 a000:1:1::/48 a000:2:1::/48 a000:3:1::/48 N1 N2 a000:3:1::2ec5 b000:1:1::2ec5 Policy-based, link-state like protocol N3 Routers selectively propagate topology information. Messages do not propagate globally. An average user has less than 20 address prefixes. Xiaowei Yang, MIT 16

17 Route information associated with addresses is optional. Name-to-Route Resolution Service (NRRS) NRRS Server A fundamental tradeoff: topology change will cause address change Tell me s addresses s addresses are a000:1:1:: 6c1a a000:2:1::6c1a Hierarchical namespace Hard-coded addresses for bootstrapping Root servers reside in toplevel providers. TIPP propagates address allocation information Route record updates are likely to be manageable AS birth and death rate < 15 per day AS-level link birth and death rate < 50 per day [Chen02] Xiaowei Yang, MIT 17

18 Failure Handling A combination of proactive notification and reactive feedback a000:1:1::/48 a000:2:1::/48 N1 R1 R2 N2 X R3 ``Uphill routes'' b000:1::/32 N3 a000:3:1::/48 Proactive notification via TIPP Tell me s addresses NRRS Server s addresses are a000:1:1:: 6c1a a000:2:1::6c1a ``Downhill routes'' Reactive discovery via router feedback or timeout Xiaowei Yang, MIT 18

19 Failure Handling A combination of proactive notification and reactive feedback a000:1:1::/48 a000:2:1::/48 N1 R1 R2 N2 X R3 ``Uphill routes'' b000:1::/32 N3 a000:3:1::/48 Proactive notification via TIPP Tell me s addresses NRRS Server s addresses are a000:1:1:: 6c1a a000:2:1::6c1a ``Downhill routes'' Reactive discovery via router feedback or timeout Xiaowei Yang, MIT 19

20 Contractual agreements Practical Provider Compensation Providers use policy checking to prevent illegitimate route usage. Direct business relationships Common cases: verify source address General cases: match source routing header against policy filters Indirect business relationships: end users pay remote providers Policy is made upon the originator or consumer of a packet. An open and general question: how to tell who sends a packet? e.g, overlay providers, second hop provider sells QoS service Various billing schemes are possible. Flat fee, usage-based billing Some routes are more expensive. Xiaowei Yang, MIT 20

21 NIMROD IDPR, SIDRA PIP, SIPP TRIAD Related Work Feedback Based Routing [Zhu02] Our work is different: Scalable route discovery Efficient route representation Heterogeneous user choices Xiaowei Yang, MIT 21

22 Conclusion The design of NIRA Scalability Divide the task of route discovery into two halves Topology Information Propagation Protocol Name-to-Route Resolution Protocol Efficiency Provider-rooted hierarchical addressing for efficient route representation Robustness A combination of proactive notification and reactive feedback for failure discovery Heterogeneous user choices Scalable route discovery Practical provider compensation Contractual agreements Xiaowei Yang, MIT 22