Preselection Algorithm for BGP-4 Update Sequences

The overall objective of my work is to propose an architecture that decouples routing policies from the global BGP-4 routing infrastructure. By doing so, the main routing infrastructure uses a policy-free and, therefore, stable and deterministic BGP-4 [54]. My study of BGP-4 update sequences was aimed at sequences that can be linked to different mechanisms used to implement Traffic Engineering using BGP-4. Once identified, I could integrate these techniques into the architecture in a way that does not affect the stability of the Internet’s BGP-4 routing plane.

I started by examining sequences of BGP-4 updates referring to a specific prefix that arrive at the RIPE RR and always follow the same path. In order to simplify, I use the term Canonical AS_PATH for the sequence of ASes traversed by an update:

5. BGP-4 UPDATE SEQUENCES

Definition 8 The Canonical AS_PATH is the sequence of ASes traversed by an advertisement. It can be derived from the AS_PATH attribute by removing all duplicated ASes from it (see Figure 5.2).

100 100 100 321 808 808

100 321 808

AS_PATH

Canonical AS_PATH

Figure 5.2: Relationship between AS_PATH and Canonical AS_PATH

The sequences of advertisements I studied share the same

Canonical AS_PATH but have fluctuating AS_PATH. These sequences show what prepending policies are used by the ASes during the lifespan of the sequence. As Fig- ure 5.3 shows in a simple example, sequences where AS_PATH Prepending cause a change in the Canonical AS_PATH do not yield any information regarding the routing policies. AS1 AS2 AS3 AS4 AS5 Policy in link AS1-AS4 no prepend prepend by 2 AS_PATH in Route Repository AS1-AS4-AS5 AS1-AS2-AS3-AS5 Policy in link AS1-AS2 no prepend no prepend Route Repository

Figure 5.3: Change in AS_PATH Prepending policy that is not reflected in the AS_PATH stored in a route repository

In order to fulfil the requirement of arriving through the same path to the RIPE RR, the sequences of BGP-4 updates I filtered out for study have the following characteristics:

• they refer to the same prefix

• they are contributed by the peer to the RIPE RR,

5.2. AS_PATH Prepend Sequence Analysis

• they are consecutive in time, and • they are

– advertisements with the same Canonical AS_PATH, or – withdraws

The advertisements contain information about the different policies applied by the ASes along the path. The withdraws are originated by events like:

• routes that were manually withdrawn

• oscillating routes that were put on hold by route flap dampening as defined in RFC 2439.

• policy changes that were applied to the network and activated by the soft recon- figuration mechanism [61]

All these events are significant when trying to understand the mechanisms involved in network management and their impact on the Internet’s routing tables. In order to make the new architecture more likely to be accepted by the network management community, these mechanisms need to be mapped into my proposal.

Figure 5.4 shows the sequence detector I used. It is implemented by a BGP-4 up- date sequencer shown in Algorithm 1 followed by an evaluator, that narrows down the characteristics of the BGP-4 sequences kept for further analysis.

Filtering &

sorting Sequencing Evalutator BGP-4

Update files

Trial & Error candidate sequences

Figure 5.4: Sequence detector: logical blocks

The evaluator I have used for all my published work is shown in Algorithm 2. It flags BGP-4 update sequences that have two or more advertisements with different AS_PATH length. With this evaluator, I get rid of sequences where the AS_PATH does not fluctuate, because no information of the AS_PATH Prepending policies can be obtained from them. Additionally, it includes an inter-arrival time threshold. This threshold helps filtering out different phenomena. For instance, implementations of the Route Refresh Capability [60] are based on sending a withdraw and a new advertisement for the routes that need to be refreshed in the same BGP-4 update or very close in time; when a route oscillates, the interval between routing updates is influenced by the protocol timers; finally, when an operator or a machine applies policies, the time between two consecutive updates tends to be several times the BGP-4 protocol timers. Table 5.1 shows the threshold values used depending on which phenomenon needs to be analysed.

5. BGP-4 UPDATE SEQUENCES

Table 5.1: Threshold ranges used to analyse different phenomena

Threshold interval Phenomenon under study

0 s to 5 s Route refresh capability

15 s to 1 min BGP-4 protocol timers

5 min or more Network maintenance or network man- agement (e.g., traffic engineering, etc.)

Data: all updates collected by a specific device during a time window [t0,t1] Sort by prefix, peer and time in this order;

foreach prefix do foreach peer do

canonical_as_path ← ∅; collector ← ∅;

foreach update do

/* skip all withdraws at the beginning */

if canonical_as_path == ∅ then if IsAdvertisement(update) then

canonical_as_path ← getCano(update); if collector == ∅ ∥

/* get all withdraws and updates sharing the canonical path */

IsWithdraw(update) ∥

getCano(update) == canonical_as_path then collector ← collector ∪ update;

else

/* when the canonical path changes, evaluate what you

collected */

evaluate(collector);

/* and start all over again */

collector ← update;

canonical_as_path ← getCano(update);

Algorithm 1: The AS_PATH Prepending sequencer

5.2. TE with BGP-4

Data: a candidate update sequence Data: ∆tmin

Result: true if candidate is Trial and Error Traffic Engineering (Trial and Error TE)

f luctuated ← f alse; adv_counter ← 0; last_aspath ← ∅; last_T S ← 0;

foreach update in candidate do if IsAdvertisement(update) then

adv_counter ← adv_counter + 1; if last_aspath ̸= ∅ then

if last_aspath ̸=getASPath(update) then f luctuated ← true;

last_aspath ←getASPath(update); if ∆tmin > 0 then

/* Take into account a minimum threshold for the sequence interarrival time. If the Route Refresh Capability is activated, a withdraw and an advertisement might arrive

at the same time. */

if last_T S ̸= 0 and last_T S ̸=TimeStamp(update) then if TimeStamp(update)−last_T S < ∆tmin then

/* Inter-arrival time out of range. */

return false

last_T S ← TimeStamp(update);

return f luctuated == true and adv_counter > 2

Algorithm 2: The basic AS_PATH Prepending evaluator