At 12:22
PM 7/9/2002 -0500, Christopher Lewis wrote:
Matthew,
I don't understand what you're saying here. We may be talking at
cross purposes.
I'm not sure. The ideas that
go into offline TE are fairly radical to many people because the way that
routes have been computed in the Internet hasn't changed for the last 25
years or so. Cheap computing power and the software sophistication to make
it simple to implement these alternative schemes also has not existed until
relatively recently.
Traffic engineering (to me at least) is about
controlling how traffic flows on your network. OSPF and IS-IS extensions
allow those protocols to communicate resource reservations made on a router.
Yes, the *extensions* communicate the resource reservations. But
they are extensions to protocols that mandate the use of a single algorithm
-- Dijkstra's -- to compute the paths in the first place. You can't separate
the communication of the reservations from the path computation of OSPF
and IS-IS.
At 08:25 PM 7/8/2002, you wrote:
At 08:25 AM 7/5/2002 -0500, Christopher Lewis
wrote:
Plain MPLS or MPLS VPN will work fine with distance
vector protocols like EIGRP, but as mentioned a link state routing protocol
is needed for MPLS traffic engineering, as each node needs the topology
information those protocols provide and OSPF and IS-IS have the opaque
LSA extensions necessary for traffic engineering.
To add to Chris' comments, note that this is for online "on the
router" traffic engineering only. If you're doing off-line traffic engineering,
any routing protocol that allows the control plane to operate will do.
Three benefits that offline TE offers vs. OSPF/IS-IS TE:
1) You can implement a routing algorithm that does a lot better than
Dijkstra shortest path. For example, you can minimize overall network utilization
and avoid bottlenecks.
MPLS TE using OSPF or IS-IS to communicate reserved resources does
not rely on the Dijkstra algorthim to compute a path.
No, they do force the use of Dijkstra's algorithm. OSPF and IS-IS
construct the reachability graph for the network and compute the shortest
path using Dijkstra's algorithm. The protocol messages allow the flooding
of the network reachability information to all participating routers so
that the graph can be constructed in the first place. In the "-TE" versions,
resource reservations piggyback on the protocol messages. So, the process
of computing the paths and communicating the reservations are intertwined
in OSPF-TE and IS-IS-TE, and you can't just get the reservation capability
without also getting Dijkstra's algorithm.
RSVP-TE is an example of a protocol that *just* communicates reserved
resources. In offline TE, you figure out the path (using whatever algorithm
you want), and then install it using the RSVP-TE explicit route object.
In OSPF and IS-IS, there is no way to use some other algorithm for determining
the best path. All you can do are set constraints such as resource class
affinity, or tinker with path metrics. Constraints merely eliminate some
number of paths from the input set to the Dijkstra algorithm -- they do
not change the algorithm. Path metrics are summed by the Dijkstra algorithm
for the purpose of determining which one is "shortest" -- they do not change
the algorithm.
2) You can pre-calculate and install backup
LSPs and ensure that there are no single points of failure, thereby dramatically
improving LSP restoration time and guaranteeing resiliency.
As you can with MPLS TE and have fast re-route handle swap overs
in less than 50 ms without operator intervention.
Yes, offline TE should support both since fast re-route and backup
paths are complimentary technologies. You can view fast re-route as a fast
"band aid" around a failure, with the backup path as the preferred longer
term solution. Fast re-route is very fast but hard to control. Backup LSPs
are slower to turn on (the failure needs to be signaled back to the head
of the LSP before traffic can be switched over) but offer more control.
The problem with fast re-route is the lack of control. If you don't
reserve the FRR paths in advance, there's no guarantee that FRR is going
to keep your network running. You don't know if there will be enough bandwidth
on the re-route path to carry the traffic, so you may end up dropping that
traffic, as well as impacting other traffic carried by neighboring nodes.
If you reserve all of the fast re-route paths in advance, you're going
to waste a lot of bandwidth in backup paths that overlap and aren't used
most of the time. The sub-50ms requirement comes from SONET's protection
scheme, which is criticized because it wastes 50% of bandwidth for protection
purposes. Pre-reserved FRR would be more wasteful than that because of
the overlapping re-route paths.
Clearly, the solution lies with careful FRR path selection and reservation
based on network demands and revenues, failure group information, and integration
with a backup LSP scheme. You want management software to compute what
that is based on your network design, operational and financial criteria
-- i.e. an easy to understand application that doesn't demand manual calculations
and/or hand configuring data into every router in your network.
3) You can support LSP constraints that are
non-additive in nature -- since shortest path works by adding hop metrics.
As you can with MPLS TE using OSPF or IS-IS extensions, things like
affinity allow you to have the path include or exclude specified types
of links in the path selection process for example.
Resource class affinities are an example of a constraint that can
be expressed in additive fashion. They result in the raising of some hop
metrics to infinity. A counter example might help: what if you wanted to
select the most reliable path, where you have to multiply reliability factors
for each hop to calculate end-to-end reliability? You can't do that with
an algorithm that insists on adding hop metrics.
Cheers,
Mathew
| Mathew Lodge
| mathew@cplane.com |
| Director, Product Management | Ph: +1 408 789 4068 |
| CPLANE, Inc.
|
http://www.cplane.com
|