The MPLS WG Archive

["Gray, Eric" <egray@celoxnetworks.com>]

Mayank,

	Please see below.  My comments are prefixed with "EG >"...

Eric W. Gray
Systems Architect
Celox Networks, Inc.
egray@celoxnetworks.com
508 305 7214


-----Original Message-----
From: Mayank Kumar [mailto:mkumar@aplion.stpn.soft.net] 
Sent: Tuesday, August 06, 2002 1:16 AM
To: 'David Charlap'
Cc: egray@celoxnetworks.com; Mpls (E-mail)
Subject: RE: Layer 3 Lookup in ATM LSR's

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 ).

EG > Assembly, and subsequent re-segmentation, is not absolutely
EG > needed however likely it is that it will be done in practice.

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 ????

EG > Only in a practical sense and then only for some ATM LSRs.
EG > That may seem to be enough, but the facts do not support
EG > such a sweeping statement.
EG >
EG > What you say is true for ATM LSRs which cannot forward IP
EG > packets, either because they are not prepared to forward 
EG > them or because their downstream neighbor is not prepared
EG > to receive them.
EG >
EG > There is nothing in the world to prevent a box which is a
EG > purely ATM switch for all external appearances from being
EG > essentially frame-based internally - particularly if it is
EG > built to provide a limited set of AAL services.  Such a
EG > box can forward IP packets at the same rate that it can
EG > forward the corresponding ATM Cells.  Even if not actually
EG > frame based, an ATM switch that is VC-Merge capable (with
EG > out necessarily requiring assembly and re-segmentation)
EG > may easily be capable of forwarding IP packets to its
EG > downstream neighbor - provided it has an IP-in-ATM VC to
EG > that neighbor.


> 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

EG > I think you meant "first two and not the third one."

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

EG > You cannot generalize this to apply to all ATM switches.
EG > We also need to stop trying to blur distinctions between
EG > ATM switches and ATM LSRs.  There are certain requirements
EG > that apply to ATM LSRs and - if the only way you can see 
EG > to satisfy those requirements is to make the ATM LSR frame
EG > based, then that is what you have to do.


> --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