Subject: RE: Layer 3 Lookup in ATM LSR's

From: "Gray, Eric" <[email-masked]>
Date: Mon, 5 Aug 2002 15:19:55 -0400

Eric O.

	While none of the things said in this discussion
so far imply that an ATM LSR should be prepared to
forward unlabeled packets, there have been separate 
discussions on this topic before.

	It has been repeatedly asserted that the term 
'LSR' strictly implies the ability to forward plain
old IP packets as well as labeled packets.  There was 
an attempt in the MPLS Framework ID several years ago 
to define an 'MPLS node' as a device that is not capable 
of forwarding unlabeled packets.  Note the definition 
of LSR from RFC 3031:

label switching router    an MPLS node which is capable of
                          forwarding native L3 packets

	There is a boot-strap problem with the MPLS node
idea, however - particularly WRT Downstream on Demand, 
ordered control.

	It is technically wrong to advertise reachability
in a routing protocol for network destinations you are
unable to forward packets to.  If an LSR needs to get a 
label from a downstream neighbor before advertising a
route corresponding to the FEC for that label, then its
upstream neighbor might well be unaware that it should
request a label from the local LSR for that FEC (not
having received a corresponding route advertisement
itself).  In DoD, ordered control, this would mean the
local LSR could end up never asking for a label from a
downstream LSR and never advertising a route to an
upstream LSR.

	An implementation can fudge this by advertising
routes based on anticipation of LSP setup.  But this 
means that packets will be directed to use defective
forwarding paths during the time it takes to establish
the anticipated LSPs - unless the routing protocol is
setup to change the cost associated with routes it has
advertised .  Depending on the dynamics of the network, 
this could be very bad. 

	Note that this problem isn't an issue with DV or 
PV routing protocols if using DU label advertisement.
I believe the problem exists, however, for LS routing
protocols regardless of the label advertisement mode. 

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

-----Original Message-----
From: Eric Osborne [mailto:[email-masked]] 
Sent: Monday, August 05, 2002 2:19 PM
To: Gray, Eric
Cc: [email-masked]'; Mpls (E-mail)
Subject: Re: Layer 3 Lookup in ATM LSR's

On Mon, Aug 05, 2002 at 01:59:06PM -0400, Gray, Eric wrote:
> Mayank,
> 
> 	The standards say that an ATM LSR does have L3
> lookup capability.  Specifically, RFC 3035 says about
> ATM LSRs: 
> 
> " ... ATM switches run network layer routing algorithms 
>   (such as Open Shortest Path First (OSPF), Intermediate
>   System to Intermediate System (IS-IS), etc.), and their 
>   data forwarding is based on the results of these routing 
>   algorithms.  No ATM-specific routing or addressing is 
>   needed.  ATM switches used in this way are known as 
>   ATM-LSRs (Label Switching Routers)."

To me, that doesn't say L3 lookup capability.  I could certainly see
an ATM LSR implementation that used L3 for two things:
- maintaining IGP adjacencies
- deciding which interfaces to signal on-demand labels

...but none of that implies that an ATM LSR should be prepared to
forward received data packets.

> 
> I am not sure what standards you were referring to.
> 
> If an ATM Switch is to participate in label switching, it
> must be able to unambiguously determine how to forward 
> labeled packets.  It is possible to implement ATM switches
> that participates in label switching without themselves
> participating in routing by ensuring that the determination
> on how to forward labeled packets is made for them.  As an
> example, this might be done by always using strict explicit 
> routing relative to the ATM switch in question and immediate 
> downstream neighbors.  Such ATM switches are not ATM LSRs.

I disagree; I think there's a difference between "L3 lookup" (which to
me implies forwarding) and simply running a local IP stack for things
which originate/terminate on that router.

eric

> 
> Eric W. Gray
> Systems Architect
> Celox Networks, Inc.
> [email-masked]
> 508 305 7214
> 
> 
> -----Original Message-----
> From: Mayank Kumar [mailto:[email-masked]] 
> Sent: Monday, August 05, 2002 1:32 PM
> To: Mpls (E-mail)
> Subject: Layer 3 Lookup in ATM LSR's
> 
> hi
> i have a query which , you all might be able to answer:-
> 
> it is said that atm switches in the core atm networks do not have layer 3
> lookup capability.
> Now the standards say that when atm lsr's do not have a layer 3 lookup
> capability then they operate in Ordered control with down stream on demand
> mode of label distribution.
> 
> lets say that i have the following mpls domain :-
> 
> a--------b---------c-------d
>           |
>           |-------k
> 
> 'b' and 'c' are atm switches with no layer 3 lookup capabilities and are
> operating in Ordered Control with DownStream on Demand Label Distribution
> method.
> Suppose a lsp has to travel the path 'a'----'b'---'c'---'d'
> 
> 'a' requests a mapping for a particular fec from 'b'. 'b' upon receving a
> label request for a particular fec , sees that it has no downstream
mapping
> for that fec. Since 'b' is operating in ordered control , it further sends
a
> label request to c (and not to k) since it cannot allocate a label for the
> requested fec . 'c' would also further send the label request to 'd' and
> then 'd' would reply with a label mapping message.
> 
> I hope that it's correct till this point.
> 
> My question is, how does 'b' know , that in order to send a label request
> for a particular fec, what is the next hop for that fec when it does not
> have a layer 3 capability.
> why would 'b' send a label request to 'c' and not to 'k' ????
> 
> 
> i hope i have made my point  clear
> 
> 
> Please tell me where am i wrong
> 
> thanks and regards
> mayank
> 
> 
>

---

From: "Gray, Eric" <[email-masked]>
Date: Tue, 6 Aug 2002 09:17:08 -0400

Mayank,

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

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

-----Original Message-----
From: Mayank Kumar [mailto:[email-masked]] 
Sent: Tuesday, August 06, 2002 1:16 AM
To: 'David Charlap'
Cc: [email-masked]; 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: [email-masked] [mailto:[email-masked]]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

---

From: "Gray, Eric" <[email-masked]>
Date: Tue, 6 Aug 2002 10:01:52 -0400

Giles,

	I think your point is valid, however, I also
think David was making a reasonable simplification
- logically, if the ingress interface 'pops' the
label it would do so so that it can perform a new
lookup on either the next label, or the IP header
(if the popped label was the last label).

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

-----Original Message-----
From: Giles Heron [mailto:[email-masked]] 
Sent: Tuesday, August 06, 2002 10:50 AM
To: David Charlap
Cc: IETF MPLS List
Subject: Re: Layer 3 Lookup in ATM LSR's

just one nit...

On Mon, 2002-08-05 at 19:02, David Charlap wrote:
[snip]
> Lookup capability is also needed for a router (or interface) that must 
> pop the label stack.  It must do a label-lookup (which all switches can 
> do), but it must then pop the stack and then do an IP lookup on the 
> result before forwarding.  This is beyond the capability of most ATM 
> forwarding hardware.
[rest snipped]

this isn't strictly, true - is it?

in some cases you may pop the stack but then forward the IP payload
without actually performing an IP lookup (e.g. PHP).

Giles

-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================