Traffic Engineering with
Traditional IP Routing Protocols
Aim of the Paper
Provides an overview of working with the
traditional IP routing protocols.
No modification to the routing protocols or the
How to adapt link weights, based on a network-
wide view of the traffic and topology within a
Summarizing the results of techniques for
optimizing OSPF/IS-IS weights to the prevailing
In some sense, IP networks manage themselves.
Adjusting sending rate depending on
Routers compute new paths
However these mechanisms do ensure efficiency.
Eg: Under-utilized links.
The focus of this paper would be traffic within a
single AS (company, ISP, etc).
Intradomain Traffic Engineering
Path selection based on Static Link Weights.
Limitations of static link weights, at the outset –
Limited routing scenarios.
No adaption of link weights, basically.
Expensive extensions have been proposed.
Can modify static link weights to do the job
A simple example.
Initial configuration: 3 units of load on (u,t)
Local change to the weight of the congested link,
increased to 2. => 2.5 units of load on (w,t).
Global optimization of the link weights. Most
Advantages of using traditional OSPF
Process of arriving at a good set of weights is
handled externally from the routers.
Modification of link weights is performed on a
relatively coarse time scale.
Centralized approach for setting routing
parameters. Has the following advantages:
Low protocol overhead.
Use link weights to express routing config:
Compatibility with traditional shortest path IGPs.
Traffic Engineering Framework.
Should have a timely and accurate view of the current
state of the network.
Estimate of the volume of traffic between each pair of
Appropriate commands to affected routers.
Router updates its link-state database & floods the new
value of the rest of the network.
Each router computes new shortest paths.
No frequent changes to link weights.
Quantifying how well we can engineer traffic flow
using traditional OSPF/IS-IS routing protocols.
Comparing solutions with OPT routing, and simple
configurations like InvCapOSPF and UnitOSPF.
Returning back to our original example.
UnitOSPF and InvCapOSPF, utilization = 150% (u,v).
Last diagram, utilization for u,v = 100%.
Performance comparison with a network –
Advanced OSPF, comes closest to OPT routing
(only 3% worse utilization than OPT)
Minimizing max link utilization might be too
specific and localized.
Unavoidable congested links.
No penalty to solutions that force traffic to traverse very
Advances OSPF has an additional objective.
The cost of using a link increases with the utilization,
with an explosive growth as the utilization exceeds 100%
Network wide cost of a routing solution is then the sum
of all link costs.
Link cost as a function of the load for a link capacity 1
Network-wide cost vs. demand for a proposed AT&T backbone
Max link utilization vs. demand with same weights as previous graph
Changing traffic demands
Optimizing the weights for a single topology and
traffic matrix is not sufficient.
Robustness was tested by changing traffic
matrices, fluctuations, errors, etc.
Previous weight settings (for the original TM)
continued to perform well.
Optimizing weights across traffic matrices!
Few changes to Link Weights
Changes to link weights are necessary in response
to large shifts in traffic and certain router or link
Fortunately, changing even a single link weight is
For an operational AT&T topology, increasing a single
weight from 1024 to 1025 could reduce max utilization
Also, existing IGP weights continued to do well even
after a single link failure.
An overview of how to modify existing IP protocols
to work efficiently in case of traffic fluctuations.
This approach treats traffic engineering as a
networks operation task, rather than a
responsibility of the underlying routing protocol.
As mentioned before, modifying traditional
protocols have many advantages over proposed
traffic engineering extensions to these protocols.