Background (contd.)

• The routing table entry in AS u for destination d is a route with empty AS path, denoted as e(u,d), if u originates prefix d

• Otherwise, it depends on the best route of its neighboring AS v, B(v,d), as well as the import policies of u from v and the export policies of v to u

Background (contd.)

Routing_Table(u,d)

e(u,d) if d O(u)

(u,v)Eimport(v,u)[export(u,v)[B(v,d)]] otherwise

=

For the sake of simplicity, we assume that the AS path in the BGP routing table entry is proprocessed so that no AS appears more than once - no additional information

AS Relationships

• The commercial agreements between pairs of administrative domains can be classified into:

– customer-provider relationship– peering relationship– mutual-transit relationship

AS Relationships

• We classify the relationship between a pair of Autonomous Systems into:

– customer-to-provider relationship– provider-to-customer relationship– peer-to-peer relationship– sibling-to-sibling relationship

AS Relationships

• An annotated AS graph is a partially directed graph whose nodes represent ASes and whose edges are classified into:– provider-to-customer– customer-to-provider– peer-to-peer– sibling-to-sibling

AS Relationships

AS1

AS3AS2

AS5AS4

AS7

AS6

provider-to-customer edge

peer-to-peer edge

sibling-to-sibling edge

Rules governing BGP export policy

OwnRoutes

Customer’sRoutes

Sibling’sRoute

Provider’sRoute

Peer’sRoute

Exporting toa Provider

Exporting toa CustomerExporting to

a PeerExporting to

a Sibling

× × ×

× × × × ×

× × ×

× × × × ×

Selective Export Rule

• An AS does not provide transit services between any two of its providers and peers

• The selective export rule indicates that a BGP routing table entry should have a certain pattern

Network Next hop AS Pathi4.2.24.0/21 134.24.127.3 1740 1 i

194.68.130.254 5459 5413 1 i158.43.133.48 1849 704 702 701 1 i193.0.0.242 3333 286 1 i144.228.240.93 1239 1 i

1849

704

701

702

Lemma

If u0’s BGP routing table contains an entry with AS path (u1,u2,…,un) for destination prefix d, then,

(a) any node ui selects a route with as_path (ui+1,…,un) as the best route to prefix d, and,

(b) ui exports its best route ui-1

Valley-free property

No V-shape possible


No Step possible


AS2

AS3AS1

AS5AS4

AS6


peer-to-peer edge


AS path (1,2,3) is valley-free


AS2

AS3AS1

AS5AS4

AS6


peer-to-peer edge


AS path (1,2,6,3) is valley-free


AS2

AS3AS1

AS5AS4

AS6


peer-to-peer edge


AS path (1,4,3) is not valley-free


AS2

AS3AS1

AS5AS4

AS6


peer-to-peer edge


AS path (2,1,3,6) is not valley-free


• After traversing a provider-to-customer or peer-to-peer edge, the AS path can not traverse a customer-to-provider or peer-to-peer edge.

• Formally, an AS path (u1,u2,…,un) is valley-free iff the following conditions hold true– A provider-to-customer edge can be followed by only provider-to-

customer or sibling-to-sibling edges

– A peer-to-peer edge can be followed by only provider-to-customer or sibling-to-sibling edges

Theorem

• If all ASes set their export policies according to the selective export rule, then the AS path in any BGP routing table entry is valley-free

• This basically shows that the selective export policy and the lemma ensures that the AS path of a BGP routing table entry has the valley-free property

Case(a) provider-to-customer edge that is followed by a customer-to-provider or peer-to-peer edge

u1

ui+1

uk

un-1

un

u2

ui

uk+1

Case(a) provider-to-customer edge that is followed by a customer-to-provider or peer-to-peer edge

• (ui,ui+1) is provider-to-customer

• (uj,uj+1) is the first customer-to-provider or peer-to-peer

• (uj-1,uj) is either provider-to-customer or sibling-to-sibling

• from lemma, the best route to destination d selected by uj is (uj+1,…,un) and it exports this route to uj-1

• contradiction since uj-1 and uj+1 are provider or peer of uj

Case(b) peer-to-peer edge is followed by a customer-to-provider or peer-to-peer edge

• can apply similar argument as in case(a)

• The valley-free property enables us to identify patterns for BGP routing table entries

Routing Table Entry Patterns

• Downhill Path: a sequence of edges that are either provider-to-customer or sibling-to-sibling

• Uphill Path: a sequence of edges that are either customer-to-provider or sibling-to-sibling


• An AS path of a BGP routing table entry has one of the following patterns:– an uphill path

– a downhill path

– an uphill path followed by a downhill path

– an uphill path followed by a peer-to-peer edge

– a peer-to-peer edge followed by a downhill path

– an uphill path followed by a peer-to-peer edge followed by a downhill path


• This can be classified into:

– maximal uphill path, peer-to-peer edge and maximal downhill path in order, or

– maximal uphill path and the maximal downhill path in order


u2

u1

ui+1

un-1

un

ui

uphill top provider downhill top provider

Heuristic Algorithms

• The Algorithm for inferring AS relationships is based on the fact that ASes set up their export policies according to the relationships and on the resulting patterns on BGP routing table entries

• It is also based on the intuition that a provider typically has a larger size than its customer and the size of an AS is typically proportional to its degree in the AS graph

Heuristic Algorithms

• top provider of an AS path is the AS that has the highest degree among all ASes in the path

• we can infer that consecutive AS pairs on the left of the top provider are customer-to-provider or sibling-to-sibling edges and on the right are provider-to-customer or sibling-to-sibling edges

Algorithms for Inferring Provider-Customer and

Sibling-to-Sibling Relationships

Basic Algorithm

• Input: BGP routing table RT

• Output: Annotated AS graph G

• Phase 1: Compute the degree for each AS

• Phase 2: Parse AS path to initialize consecutive AS pair relationship

• Phase 3: Assign relationship to AS pairs

Phase 1 (Compute the degree for each AS)

u2

u1

uj+1

un-1

un

uj

when i = 1,

neighbor[ui] = neighbor[ui] {ui+1}

neighbor[ui+1] = neighbor[ui+1] {ui}

Phase 1 (Compute the degree for each AS)

u2

u1

un-1

un

degree[u1] = |neighbor[u1]|

uj+1

uj

Phase 2 (Parse AS path to initialize consecutive AS pair relationship)

u2

u1

un-1

un

Smallest j such that

degree[uj] = max1i ndegree[ui]

uj+1

uj

Phase 2 (Parse AS path to initialize consecutive AS pair relationship)

u2

u1

un-1

un

uj+1

uj

transient[u1,u2] = 1

transient[uj+1,uj] = 1

transient[un,un-1] = 1

u2

u1

un-1

un

uj+1

uj

ub

uc

ud

ua

u2

u1

ub

uc

ud

ua

transient[ua,ub] = 1

transient[ud,u2] = 1


u2

u1

un-1

un

uj+1

uj



ub

uc

ud

ua





Phase 3 (Assign relationship to AS pairs)

if transient[ui,ui+1] = 1 and transient[ui+1,ui] = 1

relationship[ui,ui+1] = sibling-to-sibling

else if transient[ui+1,ui] = 1

relationship[ui,ui+1] = provider-to-customer

else if transient[ui,ui+1] = 1

relationship [ui,ui+1] = customer-to-provider

u2

u1

un-1

un

uj+1

uj

ub

uc

ua








peer-to-peer edge


• Top provider may not have the highest degree - possibility of incorrect inference of relationships

• let each routing table entry vote on the relationship of an AS pair

• if a sibling-to-sibling relationship is concluded by only one entry, we ignore it

Refined Algorithm

• If all routing table entries agree that an AS pair has a provider-to-customer (or customer-to-provider) relationship, then the AS has that relationship

• If only one routing table entry infers that an AS pair has a provider-to-customer (or customer-to-provider) relationship and more than one entry infer that an AS pair has a customer-to-provider (provider-to-customer) relationship, then the AS pair has a customer-to-provider (provider-to-customer) relationship

Refined Algorithm

Refined Algorithm

• For all other cases, the AS pair has a sibling-to-sibling relationship

• Unlike the basic algorithm, the refined algorithm ignores some routing table entries

Refined Algorithm


• Output: Annotated AS graph G

• Phase 1: Compute the degree for each AS

• Phase 2: Count the number of routes that infers an AS pair as having a provider-to-customer or customer-to-provider relationship

• Phase 3: Assign relationship to AS pairs

Algorithm for Inferring Peer-to-Peer Relationships

Final Algorithm

• Peer-to-peer edge between top provider and one of its neighbors only

• If the top provider has sibling-to-sibling relationship with one of its neighbors, then it has a peer-to-peer relationship with the other neighbor

• We use the heuristic that peer-to-peer edge is between the top provider and its neighboring AS that has a higher degree because such edges are between ASes of comparable sizes

• We also use the heuristic that the degrees of two peers do not differ significantly - ASes having peer-to-peer relationship do not differ by more than R times

Final Algorithm


• Output: Annotated AS graph

• Phase 1: Use either Basic or Refined algorithm to coarsely classify AS pairs into having provider-to-customer or sibling-to-sibling relationships

• Phase 2: Identify AS pairs that can not have a peer-to-peer relationship

• Phase 3: Assign peer-to-peer relationships from rest of the connected AS pairs as long as the pair degrees do not differ by more than R times

Phase 2

u2

u1

uj+1

un-1

un

uj

Uj-1

u3 Un-2

degree[uj-1] < degree[uj+1]

Phase 3

u2

u1

uj+1

un-1

un

uj

Uj-1

u3 Un-2

degree[uj] / degree[uj+1] < R and

degree[uj] / degree[uj+1] > 1/R

Experimental Results

Inference Results

TOTALROUTINGENTRIES

TOTALEDGES

SIBLING-TO-SIBLINGEDGESINFERREDBY BASIC(PERCENTAGE)

SIBLING-TO-SIBLINGEDGESINFERREDBYREFINED(IGNOREDENTRIES)

PEER-TO-PEEREDGESINFERREDBY FINAL[R= ](PERCENTAGE)

PEER-TO-PEEREDGESINFERREDBY FINAL[R=60](PERCENTAGE)

1999/9/27 968674 11288 149 (1.3%) 124 (25) 884 (7.8%) 733 (6.5%)2000/1/2 936058 12571 186 (1.47%) 135 (51) 838 (6.7%) 668 (5.3%)2000/3/9 1227596 13800 203 (1.47%) 157 (46) 857 (6.2%) 713 (5.7%)

Verification of Inferred Relationships by AT&T

OUR INFERENCE AT&T INFORMATION PERCENTAGE OF ASCustomer Customer 99.8%

Peer 0.2%Peer Peer 76.5%

Customer 23.5%Sibling Sibling 20%

Peer 60%Customer 20%

Nonexistent Customer 95.6%Peer 4.4%

Comparing inference results from Basic and Final(R= ) with AT&T internal information8


Comparing inference results from Refined and Final(R= ) with AT&T internal information


Peer 0.5%Peer Peer 76.5%

Customer 23.5%Sibling Sibling 25%



8


Comparing inference results from Basic and Final(R=60) with AT&T internal information


Peer 0.2%Peer Peer 100%Sibling Sibling 20%



WHOIS lookup Service

• supplies the name and address of the company that owns an AS

• we can confirm that an AS pair has sibling-to-sibling relationship if they belong to the same company or two merging companies

• we also confirm that two AS pairs have sibling-to-sibling relationship if they belong to two small companies that are located in the same city

WHOIS lookup Service

• 101 of the 186 inferred sibling-to-sibling relationships were confirmed (more than 50%)

• unconfirmed sibling-to-sibling can attribute to the fact that WHOIS service is not up to date

Applications of AS Relationships

• can help in the construction of distance map and the placement of the proxy or mirror site servers

• can help ISPs or domain administrators to achieve load balancing and congestion avoidance

• can help ISPs or companies to plan for future contractual agreements

• can help ISPs to reduce the effect of the misconfiguration and to debug router configuration files

• can potentially avoid route divergence problem

• can verify the consistency of information in the Internet Routing Registry (IRR)

Thank You

Contents

Documents

Transcript of Contents