The MPLS WG Archive

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

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.
egray@celoxnetworks.com
508 305 7214


-----Original Message-----
From: Eric Osborne [mailto:eosborne@cisco.com] 
Sent: Monday, August 05, 2002 2:19 PM
To: Gray, Eric
Cc: 'mkumar@aplion.stpn.soft.net'; 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.
> egray@celoxnetworks.com
> 508 305 7214
> 
> 
> -----Original Message-----
> From: Mayank Kumar [mailto:mkumar@aplion.stpn.soft.net] 
> 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
> 
> 
>