In this section, we assume that each router
can select any
for each destination prefix
. However, this could conceivably
lead to long propagation delays if
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
exceeds a threshold could be removed from consideration for router
, 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
, 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
. 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
is known in
advance, so the network administrators can compute the optimal egress
selection in the modified topology
and adjust
and
to achieve the desired traffic-engineering goal.