The MPLS WG Archive

["Mayank Kumar" <mkumar@aplion.stpn.soft.net>]

Hi
Thanks David for ur comments. They seem correct.  About my last line that
only frame based lsr's are capable of ip forwarding  in the data plane, when
u are talking  about atm interfaces capable of doing ip packet forwarding ,
then they are actually not operating in the cell mode but in frame mode.
Thus frame based lsr's include atm swicthes operating in frame mode (ie
receiving an ip packet as cells , reassembling it into a ip packet, doing a
routing table lookup and then forwarding it as cells ).

Also please see inline with prefix MAY for more :-

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David
Charlap
Sent: Tuesday, August 06, 2002 1:59 AM
To: IETF MPLS List
Subject: Re: Layer 3 Lookup in ATM LSR's


Mayank Kumar wrote:
> hi david
> u have been repeatedly talking about the resource exhaustion problem. I
> think that is taken care off by the Down stream on demand mode. What does
> the Ordered control do here.

I think Eric put it best.  You don't want to advertise a label mapping
if you can't forward traffic arriving on that label.  If you don't have
a downstream label yet, then you can't forward it as labeled traffic.
If you're lookup capable, you can pop the label and forward based on the
IP header.  If you're not, then you have no choice but to drop traffic
until the downstream label arrives.

It isn't nice to your ingress nodes to give them labels that will result
in dropped traffic.  Those nodes would probably prefer to forward the
packet through some other means until the LSP is completely up.

MAY:does all the above amount to a good reason that why Atm lsr's shouldnt
respond to a label allocation request unless they have a corresponding
downstream mapping ????


> Do u agree with the author of the Book when he says
> " this action would require the downstream
>  lsr to have layer 3 lookup capability (such as if the downstream lsr
would
>  have no further downstream label for the requested destination).
Therefore,
>  the atm swicthes never respond to a label allocation request unless they
>  already have a corresponding downstream label allocated"

I think that's a roundabout way of saying what I (and Eric) just said.

> I think , that all these discussions conclude to the following:-
>
> --all lsr 's whether atm lsr's or frame lsr's , have layer 3 lookup
> capability , which means to be able to determine the reachability of a
> particular destination prefix by looking into a routing table (to
determine
> the next hop and output interface) . This also means that all lsr's have a
> routing table too.
> --all lsr's are able to orginate ip packets in the control plane (routing
> protocol packets and Signalling protocol packets)
> --all lsr's are able to receive ip packets in the control plane (routing
> protocol packets and Signalling protocol packets)

Absolutely.  You couldn't run a signaling protocol without these three
capabilities (a routing table of some form, and the ability to transmit
and receive unlabeled packets.)

MAY: can we differentiate between the following . I mean are these three
capabilities different:-
-- ability to orginate ip packets
-- ability to receive ip packets
-- ability to forward ip packets

can an implementation  only have the first two and not the second one.I
think that if its possible then we can say that atm swicthes do not have
layer 3 forwarding capability in either the control plane or the data plane.
Because in the data plane they do cell swicthing and in the control plane
they either receive routing protocols packets destined locally or signalling
protocol packets destined locally., or they orginate one but never forward
any. But then i doubt how do targetted hellos would get forwarded  ???

cisco routers allow u to configure an atm interface as either operating in
cell mode or frame mode. however cisco switches do not allow an atm
interface to operate in frame mode and cisco routers any way have layer 3
lookup and forwarding capability in the data plane.
What i want to say that atm swicthes do not have layer 3 forwarding
capability in the data plane because they alsways swicth cells and never
operate in frame mode


> --some lsr's might be able to forward ip packets in the control plane (for
> eg an atm lsr might forward ip packets using its control vc by
reassembling
> an ip packet doing a routing table lookup and then determining the
outgoing
> interface and then further segmenting the cells again back when sending
out
> the outgoing interface determined using the routing table.)

That would be correct.  But it would be unreasonable to expect such
forwarding capability to be robust enough to use for the data plane.
Especially when people are selling switches with dozens of high-speed
(like OC-12 and higher) interfaces.  No software-based forwarder could
keep up with a load like that.

> --only edge lsr's are able to receive ip packets in the data plane.

Yes.  But "edge" can be a fuzzy term.

If a transit router should pop a label (perhaps an LDP-signaled LSP ends
in the middle of the cloud), the next router will receive an unlabeld
packet.  It may choose to encapsulate that packet in another label
header and forward it through a second LSP.  From the standpoint of
those two routers where this happened, they are edges.

> --only frame based lsr 's are able to forward ip packets in the data plane

I wouldn't go that far.  There are hop-by-hop routers with ATM
interfaces.  And there are intelligent lookup-capable interfaces for
some ATM switches.

Don't blur the lines between legacy implementations, current
implementations, future implementations, and theoretical possibility.

It is true that legacy ATM switches can't do the kind of IP lookup
necessary for data-plane forwarding.  But it is also true that there are
modern switches with cell-based backplanes that can do IP lookup and
forwarding.  Your use of the word "only" sounds like you're trying to
draw a line in the sand somewhere, when in reality, that line is always
in motion.

MAY:  u are write . Ok i agree that's true ;-)
thanks

-- David