The MPLS WG Archive

[David Charlap <David.Charlap@marconi.com>]

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.

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

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

-- David