Flexibility for implementation of the complex BGP policies, based on pre-defined logical conditions is provided by route-maps. Route-maps are very useful in: controlling the import and export policies for incoming and outgoing routes, managing redistribution of routes between BGP and other protocols, and impact the selection of the best paths by modifying the BGP decision process parameters. By combining BGP-attributes, Route-maps, and access-lists one can implement rather complex logical expressions, capable of applying different types of policies.
In order to outline potential approaches for inter-domain traffic engineering via BGP, one must keep in mind that while the outbound traffic exit point is manageable, the interconnection point where inbound traffic is received from an EBGP peer usually is not, except the case, when there is a specific agreement with the peer sending the traffic. That is why individual networks must apply suitable traffic engineering strategies in order to improve the performance of the outbound traffic delivery from their end users to peering points. traffic engineering policy is mostly based on the “closest exit” strategy – offloading inter-domain traffic at the closest outbound peer point towards the destination AS. The majority of manipulation methods of the point where inbound traffic, coming from an EBGP peer, enters a network (sending MEDs, unreliable route announcements among peering points, AS pre-pending) are either unproductive, or not recognized by the peering community.
Although BGP-based Inter-domain traffic engineering is usually productive, it is still applied in an empirical mode, because a systematic approach for inter-domain traffic has not been developed yet.
Essentially, taking into account technical and administrative reasons, it is safe to conclude that given the current Internet architecture Inter-domain traffic engineering is more complex than intra-domain traffic engineering. Technical concern is that despite the fact that topology and link state information proved to be quite useful in effective traffic mapping, BGP does not spread such data across domain boundaries due to the scalability and stability concerns. Administrative concern lies in the differences in network capacities and operating costs that exist between domains. Therefore, one solution can be effective for one domain, but useless for another. Additionally, permitting one domain to manipulate routing and traffic management in another domain’s network is not recommended.
Selection flexibility of exit points for inter-domain routing can be significantly improved by using MPLS traffic engineering tunnels (explicit LSPs), based on the concept of relative and absolute metrics. The concept is that in case BGP attributes are modified in a way that forces BGP decision process of determining the exit points for inter-domain traffic to depend on IGP metrics, then certain amount of inter-domain traffic directed to a particular peer network will be forced to prefer a predefined exit point by establishing a traffic engineering tunnel between the “decision-making” router and the peering point and by assigning the traffic engineering tunnel a metric that is smaller than the IGP cost to all other peering points. In case peer accepts and processes MEDs, then one can apply an analogous MPLS traffic engineering tunnel based scheme so that it prefers certain entrance points. This can be achieved by setting MED to be an IGP cost, given that if has been altered by the tunnel metric.
Just like in case of the intra-domain traffic engineering, inter-domain traffic engineering is most successful if a traffic matrix is derived to show the volume of traffic, flowing from one AS to another.
Usually, in order to redistribute inter-domain traffic peering partners must coordinate with each other. An export policy in one domain can considerably impact the local traffic matrix inside the domain of the peering partner. In such case the intra-domain traffic engineering will be affected by the modifications in the spatial distribution of traffic. Thus, in order to maintain the stability of the inter-domain traffic, the peering partners must coordinate with each other prior to applying any policy modifications, which may cause considerable and undesirable shifts in inter-domain traffic. This coordination can certainly prove to be somewhat challenging due to the technical and non-technical concerns.
At Noction we have integrated complex inter-domain traffic engineering algorithms in one single product – the Intelligent Routing Platform (IRP). The system is designed to automatically evaluate all the available network routes and select the best-performing one in terms of latency, packet loss, provider capacity and usage, as well as the historical reliability of the route. Noction IRP evaluates these performance metrics by sending probes through each of the connected Internet Service Providers and applying a set of algorithms to compare their performance. After the best routes are calculated, IRP injects the announcements into the routing table as regular BGP updates. By manipulating various BGP attributes IRP assigns a higher priority to its announcements in order to override the existing ones.