The MPLS WG Archive

[richard.crouch@vf.vodafone.co.uk]

Giles, 

your statement :-

"TE and fast-reroute however are a different story, since labels are
being pushed and popped in the middle of the path.  I can't see how this
can be done with ATM MPLS?"
confirms my *intuition* that in an IP-only (i.e. no ships-in-the-night going
on)MPLS network with a core built soley from ATM-LSRs, then the inability of
an ATM-LSR to be able to push and pop labels in the middle of the path
renders it incapable of performing fast-reroute in the core.

However, intuition is not always enough and I am interested if there are any
parts of the MPLS IDs/RFCs that contain mandatory requirements that would
specifically *prevent* ATM-LSRs from performing the fast-reroute.

Surely this renders the cell-based variant of MPLS as an inferior
implementation (compared to packet-based MPLS) if high survivability through
use of path recovery within the core is deemed a necessary requirement ?

Or, is there a method by which ATM-LSRs can achieve the path-recovery
function in an interoperable method ?


-----Original Message-----
From: Giles Heron [mailto:giles@level3.net]
Sent: 19 January 2001 17:01
To: richard.crouch@vf.vodafone.co.uk
Cc: mpls@UU.NET
Subject: Re: Implications of cell-based or frame-based MPLS


richard.crouch@vf.vodafone.co.uk wrote:
> 
> Given two homogenous carrier MPLS  networks providing only IP services :-
> 
> Network A : where "cell-based" MPLS is used (e.g. an ATM network got
> upgraded to include MPLS, -> label carried in the VPI/VCI) and
> Network B : where "frame/packet-based" MPLS is used (e.g. a router network
> got upgraded to include MPLS -> label shimmed between L2 and L3 headers)
> 
> then apart from the additional time to complete convergence in the event
of
> link failure for the cell-based MPLS network (due to additional
convergence
> time of LDP where conservative label retention mode is used by the
> "cell-based" MPLS network),

That's a pretty good reason to prefer frame-based for starters!

> (1) What are the other major differences in performance/capabilities as a
> consequence of these two different implementations of MPLS (cell versus
> packet-based) ?

Frame-based should be faster (no SAR bottlenecks, plus ready support for
trunk interfaces above OC-48), and more efficient (no "cell tax").  It's
also nice to be able to mix media types (e.g. GigE for the LAN and POS
for the WAN).

One major issue with cell-based MPLS is support for LSP-merge.  In a
frame-based MPLS network with LDP label distribution you require only
O(n) labels, where n is the number of PE devices.  With cell-based you
require O(n squared) - unless you have a VC-merge capable ATM switch
(where the switch buffers cells from different frames to ensure they
don't get interleaved).  So that's a major scalability issue for
cell-based MPLS.

With frame-based you'd also have the option of doing IP forwarding at
wire-speed if required, since most routers will forward IP and MPLS in
the same fast path.

> (2) In the area of MPLS applications such as MPLS-VPNs, MPLS
> traffic-engineering and fast-reroute, what impacts are caused by the
> inability of an ATM-LSR to pop/push labels in the label stack compared to
a
> "frame/packet-based" LSR (which can pop/push labels in the label stack) ?

I don't think VPN is impacted by this?  The VPN label should only be in
the AAL5 frame (and not in the cell header) since it is carried
unchanged from PE to PE?

TE and fast-reroute however are a different story, since labels are
being pushed and popped in the middle of the path.  I can't see how this
can be done with ATM MPLS?

> In a most crude form, I am asking the question "what's better : cell-mode
or
> frame/packet-mode MPLS"

I guess you can figure out my answer from the above? ;-)

Giles

-- 
===================================================
Giles Heron - IP Architect - Level 3 Communications
phone: +44 20 7864 0719     mobile: +44 7880 506185
===================================================