next up previous
Next: Implementation Issues Up: Traffic Engineering Previous: Evaluation

Extensions

In this section, we assume that each router $ i$ can select any $ e\in
E(p)$ for each destination prefix $ p$. However, this could conceivably lead to long propagation delays if $ i$ selects a far-away egress point, or to unnecessary BGP update messages to neighboring domains. We can address these concerns simply by removing certain egress points from consideration if they have high propagation delay or a BGP route with a different AS path. For instance, egresses where $ d(G,i,e)$ exceeds a threshold could be removed from consideration for router $ i$, or we could consider only the egress points that have BGP routes with the same AS path. Our solution can also treat destination prefixes for sensitive applications (such as VoIP) separately. For instance, the egress selection for such prefixes can be done to minimize sensitivity and delay as discussed in Section IV, and the demands to these prefixes considered as immutable background load for the traffic-engineering problem.

The traffic-engineering optimization problem as defined in this section only considers the utilization of internal links. A natural extension is to use TIE to balance outbound load on the edge links. We can formulate this problem by adding an artificial node for each destination prefix $ p$, with each peering link connecting to it, and solve it using the same methodology presented here. In addition, our traffic-engineering optimization problem currently does not set the values of $ \alpha $. This prevents the egress selection to automatically adapt to changes in the network topology. We can combine our methodology for solving the problem presented in Section IV with the one presented here to find a solution to the robust traffic-engineering problem. In steps 1 and 3(a) in Figure 4, instead of identifying the best egress point according to the shortest distance, we can achieve robust traffic engineering by selecting the best egress according to the solution of the path-based multicommodity-flow problem specified in Section V-B. TIE can also be configured before planned maintenance activities to ensure low link utilizations during the event. In this case, the topology change $ \delta$ is known in advance, so the network administrators can compute the optimal egress selection in the modified topology $ \delta(G)$ and adjust $ \alpha $ and $ \beta $ to achieve the desired traffic-engineering goal.


next up previous
Next: Implementation Issues Up: Traffic Engineering Previous: Evaluation
Maurico Resende 2005-10-14