Cell Relay Archive

Cell Relay Retreat>List Archive>month:2000-Nov> msg00002



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: N-square probelm in ATM&MPLS

  • From: albert.e.manfredi@boeing.com
  • Date: Wed, 01 Nov 2000 18:51:59 GMT
  • Organization: Boeing North American
  • X-Article-Creation-Date: Wed Nov 01 18:51:59 2000 GMT


In article <8tpia9$5lc$1@nnrp1.deja.com>,
  erze9119@my-deja.com wrote:
> Hi folks!
>
> Thank you for your comments on the N square problem.
>
> Now I understand that the N square problem concerns
> only networks with PVC connections and not SVC capable
> networks like PNNI for example.

No, I disagree with this. The n^2 problem affects any type of network
which must set up a mesh between switches, and in which the data paths
cannot be _merged_ at any physical merge point. So this problem
certainly applies to ATM SVC networks too, as long as SVC setup is slow
compared with packet flow.

For example, a network of IP routers interconnected by ATM switches
running RFC 2225 (CLIP), whether the PVC or SVC approach is used, would
have this problem.

If one source has to be able to reach n destination nodes, in a
connection-oriented scheme where the connections are _long term_
compared with the data flow, that source must set up n links (PVCs or
SVCs).

If every one of those nodes must also set up paths to all others, each
one must set up n outgoing paths. So, for example, any given node will
see n outgoing VCs and n incoming VCs. The total number of connections
PNNI will set up is going to be n^2. A manual PVC setup, or a PNNI-
based SPVC setup, would have exactly the same problem.

In ATM, if a VC carries AAL5 frames, the assumption is that the AAL5
frames on the VC all come from the same source. You can't merge packets
from many different sources onto a single VC, because if you do, the
ATM switches won't be able to allocate the cells flowing on that VC to
the correct packet. Cells from all sorts of packets will become
hopelessly mixed up.

Now sure, if ATM SVCs could be set up only for a single IP session,
then torn down, this n^2 problem wouldn't exist. But IP sessions are
sometimes one packet long.

Equally, if a single VC could keep cells of a given packet somehow
separate from cells of other packets, again the problem wouldn't exist.
But hell, if you can do that, you now wonder why bother with cells at
all. It kind of defeats the purpose of cells if you're going to keep
them neatly arranged sequentially, packet by packet. Just use packets.
Forget cells.

> BTW, in  the IP over ATM (overlay model) is the assumption
> PVC connected ATM network, or is it possible to use SVC
> connected network as well, and thus avoid the N square
> problem?

LANE (available at the ATM Forum web site) uses SVCs exclusively. CLIP
(RFC 2225) uses either SVCs or PVCs. Either scheme can carry IP over
ATM.

--
Bert
albert.e.manfredi@boeing.com


Sent via Deja.com http://www.deja.com/
Before you buy.