Distributed Route Aggregation on the GlObal Network (DRAGON) Joo - - PowerPoint PPT Presentation

▶
distributed route aggregation
SMART_READER_LITE
LIVE PREVIEW

Distributed Route Aggregation on the GlObal Network (DRAGON) Joo - - PowerPoint PPT Presentation

Jan 19, 2024 230 likes •794 views

Distributed Route Aggregation on the GlObal Network (DRAGON) Joo Lus Sobrinho 1 Laurent Vanbever 2 , Franck Le 3 , Jennifer Rexford 4 ACM CoNEXT 2014, Sydney 1 Instituto de Telecomunicaes, 1 IST Universidade de Lisboa 2 ETH Zurich, 3 IBM

slide-1
SLIDE 1

Distributed Route Aggregation

  • n the GlObal Network

(DRAGON)

João Luís Sobrinho1

Laurent Vanbever2, Franck Le3, Jennifer Rexford4

1Instituto de Telecomunicações, 1IST Universidade de Lisboa 2ETH Zurich, 3IBM T. J. Watson Research, 4Princeton University

ACM CoNEXT 2014, Sydney

slide-2
SLIDE 2

Last year in the news (August 2014)

Some routers could not process the +512 K IPv4 prefixes they were learning about

2

slide-3
SLIDE 3

Not a scalable routing system

3

1.0.0.0/16

AS 1 AS 5 AS 2 AS 4 AS 3 AS 6

1.0.0.0/16 1.0.0.0/16 1.0.0.0/16 1.0.0.0/16 1.0.0.0/16 origin

Most of the originated prefixes are routed globally (by BGP)

slide-4
SLIDE 4

Not a scalable routing system

4

Most of the originated prefixes are routed globally (by BGP)

1.0.0.0/16 1.1.0.0/16 origin 1.0.0.0/16 origin 1.1.0.0/16 1.0.0.0/16 1.1.0.0/16 1.0.0.0/16 1.1.0.0/16 1.0.0.0/16 1.1.0.0/16 1.0.0.0/16 1.1.0.0/16

AS 1 AS 5 AS 2 AS 4 AS 3 AS 6

slide-5
SLIDE 5

Not a scalable routing system

5

Most of the originated prefixes are routed globally (by BGP)

1.0.0.0/16 1.1.0.0/16 origin 1.0.1.0/24 1.0.0.0/16 1.1.0.0/16 1.0.1.0/24 origin 1.0.0.0/16 origin 1.1.0.0/16 1.0.1.0/24 1.0.0.0/16 1.1.0.0/16 1.0.1.0/24 1.0.0.0/16 1.1.0.0/16 1.0.1.0/24 1.0.0.0/16 1.1.0.0/16 1.0.1.0/24

AS 1 AS 5 AS 2 AS 4 AS 3 AS 6

slide-6
SLIDE 6

No scalability: poor performance

  • Forwarding tables (FIBs) growth & address look-

up time increase

  • Routing tables (RIBs) growth
  • BGP session set-up time increase
  • Churn & convergence time increase

6

slide-7
SLIDE 7

Further scalability concerns

  • IPv6 prefixes can be formed in potentially larger

numbers than IPv4 prefixes

  • Secure BGP adds computational overhead to

routing processes

7

slide-8
SLIDE 8

DRAGON

8

Distributed solution to scale the Internet routing system Basic DRAGON: 49% savings on routing state Full DRAGON: 79% savings on routing state No changes to the BGP protocol No changes to the forwarding plane Readily implemented with updated router software

slide-9
SLIDE 9

Outline

  • Scalability: global view
  • DRAGON: filtering strategy
  • DRAGON: aggregation strategy
  • DRAGON: performance evaluation
  • Conclusions

9

slide-10
SLIDE 10

Outline

  • Scalability: global view
  • DRAGON: filtering strategy
  • DRAGON: aggregation strategy
  • DRAGON: performance evaluation
  • Conclusions

10

slide-11
SLIDE 11

Scalability: global view (routing)

11

1.0.0.0/16 1.0.1.0/24 origin 1.0.0.0/16 origin 1.0.1.0/24 1.0.0.0/16

Propagation of more specific prefixes only in a small vicinity of their origin ASs

AS 2

AS 1

AS 3

Specificity Prefix q is more specific than prefix p if the bits of p are the first bits of q

slide-12
SLIDE 12

Scalability: global view (forwarding)

12

1.0.0.0/16 1.0.1.0/24 origin 1.0.0.0/16 origin 1.0.1.0/24 1.0.0.0/16

Most ASs forward data-packets on the (aggregated) less specific prefixes

1.0.1.1

data-packet

  • dest. addr.

AS 2

AS 1

AS 3

slide-13
SLIDE 13

13

1.0.0.0/16 1.0.1.0/24 origin 1.0.0.0/16 origin 1.0.1.0/24 1.0.0.0/16

data-packet

1.0.1.1

Scalability: global view (forwarding)

  • dest. addr.

AS 2

AS 1

AS 3

slide-14
SLIDE 14

Hope for scalability? Hierarchies

14

AS 1 AS 2 provider customer

1.0.0.0/16 1.0.1.0/24

AS-hierarchy aligned with prefix hierarchy

Prefix hierarchy AS hierarchy

slide-15
SLIDE 15

Hope for scalability? Clustering

15

Geography roughly clusters together ASs with aggregatable address space

AS 6

1.0.0.0/24 1.0.1.0/24 1.0.2.0/23

Routing Information Registry (RIR) AS 3 AS 5 AS 4

1.0.0.0/24 1.0.1.0/24

1.0.0.0/24 + 1.0.1.0/24 + 1.0.2.0/23 = 1.0.0.0/22

1.0.2.0/23

AS 1 AS 3 AS 2

slide-16
SLIDE 16

Challenge: global vs. local

  • each AS decides where to connect
  • each AS decides where to acquire address space
  • each AS sets its own routing policies

16

How to realize the global view through automated local routing decisions? especially, given that the Internet routing system is as decentralized as it can be:

slide-17
SLIDE 17

Outline

  • Scalability: global view
  • DRAGON: filtering strategy
  • DRAGON: aggregation strategy
  • DRAGON: performance evaluation
  • Conclusions

17

slide-18
SLIDE 18

Filtering strategy

  • Locally filter the more specific prefixes when

possible

– no black holes – respect routing policies

  • Use built-in incentives to filter locally

– save on forwarding state – forward along best route

  • Exchange routing information with standard BGP

18

slide-19
SLIDE 19

Providers, customers, and peers

19

#1 #2 #3 #4 #5 #6 peer peer provider customer

slide-20
SLIDE 20

Prefixes

20

p: origin

#6 originates q (1.0.0.0/24); #4 originates p (1.0.0.0/16)

q: origin

q more specific than p #1 #2 #3 #4 #5 #6

slide-21
SLIDE 21

Routes

21

p: origin q: origin

#1 #2 #3 #4 #5 #6 q-route (route pertaining to q) Route Association between a prefix and an attribute, from a totally ordered set of attributes

slide-22
SLIDE 22

Gao-Rexford routing policies

22

p: origin q: origin

route attributes: “customer” “provider” “peer” #1 #2 #3 #4 #5 #6 preferences: customer then peer then provider exportations: all routes from customers; all routes to customers q-route

slide-23
SLIDE 23

Gao-Rexford routing policies

23

p: origin q: cust. q: origin

route attributes: “customer” “provider” “peer” #1 #2 #3 #4 #5 #6 preferences: customer then peer then provider exportations: all routes from customers; all routes to customers

q: cust.

q-route

slide-24
SLIDE 24

Gao-Rexford routing policies

24

p: origin q: cust. q: origin

route attributes: “customer” “provider” “peer” #1 #2 #3 #4 #5 #6 preferences: customer then peer then provider exportations: all routes from customers; all routes to customers

q: cust. q: cust. q: prov.

q-route

slide-25
SLIDE 25

Gao-Rexford routing policies

25

p: origin q: cust. q: origin

route attributes: “customer” “provider” “peer” #1 #2 #3 #4 #5 #6 preferences: customer then peer then provider exportations: all routes from customers; all routes to customers

q: cust. q: cust. q: prov. q: peer

q-route

slide-26
SLIDE 26

Final state for prefix q

26

p: origin q: cust. q: origin

route attributes: “customer” “provider” “peer” #1 #2 #3 #4 #5 #6

q: cust. q: cust. q: prov. q: peer

slide-27
SLIDE 27

Final state for prefixes q and p

27

p: origin q: cust. p: prov. q: origin

route attributes: “customer” “provider” “peer” #1 #2 #3 #4 #5 #6

p: prov. q: cust. p: cust. q: cust. p: prov. q: prov. p: peer q: peer

forwarding: longest prefix match rule

slide-28
SLIDE 28

Filtering code (FC)

28

p: origin q: cust. p: prov. q: origin

#1 #2 #3 #4 #5 #6

p: prov. q: cust. p: cust. q: cust. p: prov. q: prov. p: peer q: peer

Filtering Code (FC) Other than origin of p, in the presence of p, filter q if only if: attribute of p-route same or preferred to attribute of q-route ASs that filter q upon execution of FC

slide-29
SLIDE 29

AS 2 applies FC

29

p: origin q: cust. p: prov. q: origin

#1 #2 #3 #4 #5 #6

p: prov. q: cust. p: cust. q: cust. p: prov. q: prov. p: peer

AS 2 filters q

  • AS 2 saves on forwarding state
  • AS 1 is oblivious of q; it saves on

forwarding and routing state AS forgoes q filtered prefix

slide-30
SLIDE 30

All ASs apply FC

30

p: origin q: cust. p: prov. q: origin

#1 #2 #3 #4 #5 #6

p: prov. q: cust. p: cust. q: cust. p: prov. q: prov. p: peer

AS 1, AS 2, and AS 3 forgo q forwarding to q using less specific p AS forgoes q filtered prefix

slide-31
SLIDE 31

Global property: correctness

31

p: origin q: cust. p: prov. q: origin

#1 #2 #3 #4 #5 #6

p: prov. q: cust. p: cust. q: cust. p: prov. q: prov. p: peer

Correctness: no routing anomalies (no black holes) forwarding data-packets with destination in q

slide-32
SLIDE 32

Global property: route consistency

32

p: origin q: cust. p: prov. q: origin

#1 #2 #3 #4 #5 #6

p: prov. q: cust. p: cust. q: cust. p: prov. q: prov. p: peer

Route consistency: attribute of route used to forward data- packets is preserved Optimal route consistency: set of ASs that forgo q is maximal forwarding data-packets with destination in q

slide-33
SLIDE 33

Partial deployment

33

p: peer q: cust. p: origin q: cust. p: prov. q: origin p: cust. q: cust. p: cust. q: cust. p: peer q: peer

#1 #2 #3 #4 #5 #6 forwarding data-packets with destination in q ASs that filter q upon execution of FC

slide-34
SLIDE 34

Partial deployment: incentives

34

p: peer q: cust. p: origin q: cust. p: prov. q: origin p: cust. q: cust. p: cust. q: peer p: peer q: prov.

#1 #2 #3 #4 #5 #6 forwarding data-packets with destination in q AS 2 (and AS 3) has a double incentive to apply the FC:

  • saves on forwarding state
  • improves attribute of route used to forward data-packets
slide-35
SLIDE 35

Partial deployment: incentives

35

p: peer q: cust. p: origin q: cust. p: prov. q: origin p: cust. q: cust. p: cust. q: peer p: peer q: prov.

#1 #2 #3 #4 #5 #6 forwarding data-packets with destination in q AS 2 reverts to forwarding data-packets with address in q to AS 4 AS 2 applies FC

slide-36
SLIDE 36

Partial deployment: route consistency

36

p: peer q: cust. p: origin q: cust. p: prov. q: origin p: cust. q: cust. p: cust. q: cust. p: peer q: peer

#1 #2 #3 #4 #5 #6 forwarding data-packets with destination in q

slide-37
SLIDE 37

Partial deployment: route consistency

37

p: peer q: cust. p: origin q: cust. p: prov. q: origin p: cust. q: cust. p: cust. q: cust. p: peer q: peer

#1 #2 #3 #4 #5 #6 forwarding data-packets with destination in q First to apply FC are ASs that elect a peer or provider q-route

slide-38
SLIDE 38

Partial deployment: route consistency

38

p: peer q: cust. p: origin q: cust. p: prov. q: origin p: cust. q: cust. p: cust. q: cust. p: peer q: prov.

#1 #2 #3 #4 #5 #6 forwarding data-packets with destination in q Next to apply FC are ASs for which providers have already applied FC

slide-39
SLIDE 39

Partial deployment: route consistency

39

p: peer q: cust. p: origin q: cust. p: prov. q: origin p: cust. q: cust. p: cust. q: peer p: peer q: prov.

#1 #2 #3 #4 #5 #6 forwarding data-packets with destination in q Next to apply FC are ASs for which providers have already applied FC

slide-40
SLIDE 40

Filtering strategy: general case

  • Trees of prefixes learned from BGP

– FC for a prefix in relation to the parent prefix

  • Correctness

– for the routing policies for which BGP is correct

  • Route consistency (optimal and through partial

deployment)

– for isotone routing policies (includes Gao-Rexford) Optimal route consistency is not synonymous with efficiency (think shortest paths)

40

slide-41
SLIDE 41

Outline

  • Scalability: global view
  • DRAGON: filtering strategy
  • DRAGON: aggregation strategy
  • DRAGON: performance evaluation
  • Conclusions

41

slide-42
SLIDE 42

Aggregation strategy

  • Locally originate aggregation prefixes when

beneficial

– new address space is not created – allow filtering of provider-independent prefixes – self-organization when more than one AS

  • riginates the same aggregation prefix
  • Again, exchange routing information with

standard BGP

42

slide-43
SLIDE 43

Aggregation prefix

43

#1 #4 #6 Aggregation prefix

  • 1. no routable address

space is created

  • 2. at least two covered

prefixes

  • 3. customer route is

elected for each of the covered prefixes #2 #3 #5

p0: origin p10: prov. p11: prov. p0: prov. p10: origin p11: prov. p0: prov. p10: prov. p11: origin p0: cust. p10: cust. p11: cust.

p0 + p10 + p11= p; p is an aggregation prefix at AS 3

slide-44
SLIDE 44

AS 3 originates p

44

#1 #4 #6 #2 #3 #5

p: prov. p0: origin p10: prov. p11: prov. p: prov. p0: prov. p10: origin p11: prov. p: prov. p0: prov. p10: prov. p11: origin p: cust. p0: cust. p10: cust. p11: cust. p: cust. p: origin p0: cust. p10: cust. p11: cust.

AS 2 filters p0, p10, and p11 AS 4 filters p10 and p11 AS 5 filters p0 and p11 AS 6 filters p0 and p10 AS 1 is oblivious of p0, p10, and p11

slide-45
SLIDE 45

Aggregation strategy: general case

  • Trees of prefixes learned from BGP

– aggregation prefixes cover parentless prefixes

  • Self-organization

– for the routing policies for which BGP is correct

  • Optimal origins

– for isotone routing policies (includes Gao-Rexford)

45

slide-46
SLIDE 46

Outline

  • Scalability: global view
  • DRAGON: filtering strategy
  • DRAGON: aggregation strategy
  • DRAGON: performance evaluation
  • Conclusions

46

slide-47
SLIDE 47

Data-sets

  • Annotated topology (CAIDA, Feb. 2015)

– ~50K ASs; ~42K stub ASs – ~94K provider links; ~94K customer links; 180K peer links

  • IPv4-prefixes-to-ASs mapping (CAIDA, Feb.

2015)

– ~530K prefixes – ~270K parentless prefixes – ~210K prefixes have same origin AS as parent

47

slide-48
SLIDE 48

FIB filtering efficiency: definition

# (FIB entries BGP) – # (FIB entries DRAGON) # (FIB entries BGP)

48

Normalized amount of reduction brought by DRAGON to the forwarding tables of an AS

FilterEff =

slide-49
SLIDE 49

FIB filtering efficiency: results

49

Basic DRAGON Full DRAGON

filtering filtering & aggregation

  • Min. FilterEff

47% % of ASs with at least

  • Min. FilterEff

100%

  • Max. FilterEff

49% % of ASs attaining

  • Max. FilterEff

87%

slide-50
SLIDE 50

FIB filtering efficiency: results

50

Basic DRAGON Full DRAGON

filtering filtering & aggregation

  • Min. FilterEff

47% 69% % of ASs with at least

  • Min. FilterEff

100% 100%

  • Max. FilterEff

49% 79% % of ASs attaining

  • Max. FilterEff

87% 87%

slide-51
SLIDE 51

Outline

  • Scalability: global view
  • DRAGON: filtering strategy
  • DRAGON: aggregation strategy
  • DRAGON: performance evaluation
  • Conclusions

51

slide-52
SLIDE 52

Conclusions

  • DRAGON is a BGP add-on to scale the Internet

routing system

  • DRAGON can be deployed incrementally
  • DRAGON reduces the amount of forwarding

state by approximately 80%

  • DRAGON is – more fundamentally – a solid

framework to reason about route aggregation

52

slide-53
SLIDE 53

Thank you! Visit us at www.route-aggregation.net

53