The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] MPLS Performance analysis.....
Martin Cooper <mjc@cooper.org.uk> writes:
> the de-coupling of end-to-end path-selection from the
> extremely dynamic hop-by-hop routing information
MPLS is a condensation of a GRE-like data-in-IP
encapsulation header, plus some related control planes to
lay out an SSR (strict source route) across a routed,
packet-switched network.
Perhaps it would be more precise to describe it as an
encapsulation header which is regenerated at each hop,
rather like a GRE-like packet whose header on the "head
end" (or ingress) router has an destination address of a
loopback address on an immediate neighbour router. This
second router in the path removes the encapsulation header
and then re-encapsulates the data in a new GRE-like header
with a loopback address of the next router towards the
"tail end" (or egress) router, which will actually process
the data part.
Now use RSVP to coordinate the choice from a number of
loopback addresses to build a path out of a concatenation
of these tunnels, and tadah, you get a nastygram from one
of the high priests of MPLS that you have just reinvented
MPLS only with alot of extra bytes of overhead per packet.
When you point that the IP overhead lets one choose
between doing SSR ER and two different modes of LSR ER
(both of which require router cooperation -- one mode
requires the decap-reencap dance above, the other merely
processing of the LSRR option), you may end up in a nasty
fight, being reminded that one of the reasons people don't
like ATM is that there is lots of overhead.
Of course, the model for VPNs is relatively little traffic
at much higher than normal cost compared to best-efforts
Internet transit connectivity, so the overhead doesn't
seem to matter much. Also, not everyone needs to do
heavy duty TE on huge-volume traffic, and thus can choose
the operational overhead of deploying MPLS versus the
per-packet overhead of a GRE-like encapsulation header.
Another neat detail that annoys MPLS folks is that
if you do not keep your encapsulation header's IP ttl
tiny, you don't have to do an RSVP song and dance or
play the pre-provisioned-back-up-path game, and suchlike.
Great for VPNs, where you don't really need to do ER at
all, you just want to isolate the inside data from the
routers in the "core".
> the more stable re-routing of end-to-end
> constraint-based paths thus enabled
You are emulating a circuit-switched network on a
packet-switched one, no matter how you slice things;
if your underlying logical layer in a hybrid MPLS/IP
core changes, both MPLS and IP have to reconverge,
and this is generally not so ships-in-the-night (i.e.,
typically MPLS is reliant upon the topology discovery
protocol IP uses). Extra stability here can only come
through a time-to-converge trade-off.
As some else said: MPLS is L3, not L2.
> On the other hand, destination-prefix based IP routing
> is quintessentially a hop-by-hop algorithm
How is MPLS any different?
>(but without ATMs slow-moving standardisation
> process and bandwidth-overhead related baggage).
Ah, you're new to the IETF, too? Welcome!
Sean.
|
|