Control of the Incoming Traffic

The control of incoming traffic is based on a careful tuning of advertisements sent by the AS. Inbound traffic engineering is generally thought as more difficult than outbound traffic engi- neering because an AS cannot control the routing decisions of other ASes directly [6].

The first method is to divide the AS’s address space in dis- tinct prefixes and announce different route advertisements on different links. However, this selective advertisements method suffers from an important drawback: if a link fails, the prefixes that were announced on the failed link will not be reachable anymore. It makes this method not desirable because the AS cannot exploit the resilience of multihoming.

A variant of the selective advertisements is the advertisement of more specific prefixes. This technique relies on the fact that an IP router will always select in its forwarding table the most specific route for each packet (i.e. the matching route with the longest prefix). For example, if a forwarding table contains both a route toward 16.0.0.0/8 and a route toward 16.1.2.0/24, then a packet whose destination is 16.1.2.200 would be forwarded along the second route. Therefore one AS can control its incoming traffic by advertising a large aggregate on all links for fault- tolerance reason and advertising specific prefixes on some links at the same time.

This variant improves the resilience of the network, however, two methods share the same drawback that the AS will adver- tise a number of prefixes larger than required. All these prefixes will be propagated throughout the global Internet and will in- crease the size of BGP routing tables of potentially all ASes in the Internet. [3] reports that more specific routes constitute more than half of the entries in a BGP table. Faced with this increase of routing table size, several large ISPs have started to implement filters to reject BGP advertisements corresponding

to more specific prefixes. It implies that the more specific pre- fixes will not be announced by those large ISPs and thus the technique will become much less effective.

The length of the AS Path is utilized as the third criteria in the BGP decision process, therefore a possible way to influence the selection of routes by a distant AS is to artificially increase the length of the AS Path attribute by including multiple of its own AS number. This method allows an AS to indicate a ranking among the various route advertisements that it sends. It is referred to as AS Path Prepending (ASPP) approach, which will be described in more detail in Chapter 3.

The ASPP approach does not introduce longer prefixes, and at the same time takes the advantage of resilience protection from multihomed connections. However, the ASPP approach is often performed in a trial-and-error basis. Many operators believe that it is prone to surprise changes and it is difficult to predict the impact of a prepending behavior given the limited knowledge of the Internet topology and routing policies used by distant ASes.

The last method is to rely on the multi-exit-discriminator (MED) attribute. This optional attribute can only be used by an AS multi-connected to another AS to influence the link that should be used by other ASes to send packets toward a specific destination. It should however be noted that this method can only be utilized to select one link from multiple links to the same AS. Moreover, the utilization of the MED attribute is usually subject to a negotiation between the two peering ASes and some ASes do not accept to take the MED attribute into account in their decision process.

In addition to the above techniques, several ISPs have been using the community attribute to give their customers a finer control on the redistribution of their routes. The community attribute is an optional attribute which can contain several 32

CHAPTER 2. BACKGROUND STUDY 28

bits wide community values. When the community attribute is used for traffic engineering purposes, predefined community val- ues can be attached to routes in order to request remote routers to perform some actions, such as not announcing the route to a specified set of peers, or prepending the AS Path when an- nouncing the route to a specified set of peers etc..

The communities allow an AS to flexibly influence the re- distribution of its routes toward non-directly connected ISPs. Unfortunately, not all ISPs support all communities, and this technique relies on an ad hoc definition of community values and on manual configurations of BGP filters. It makes the tech- nique difficult to use and subject to errors. An extension to BGP community attribute called redistribution community is proposed within IETF to solve these problems [7]. However, even this extension still suffers from some important drawbacks. For example, this technique requires changes to the attributes of BGP advertisements and any small change to an attribute will force the route advertisement to be redistributed to potentially the entire Internet.

Remarks: Using BGP policies to shift traffic requires ex-

treme care because the influence of policy changes on traffic flows is difficult to predict. In [32], the authors suggest some guidelines on how to perform traffic engineering properly. For example, operators should make policy changes based on large groups of prefixes (e.g., groups of prefixes that have a common origin AS, or other common attributes), limit policy sensitivity to AS path changes by assigning policies based on AS path reg- ular expression matches and assigning local preference based on ranges of AS path lengths, rather than using AS path length as an absolute metric.