Cell Relay Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Re: N-square probelm in ATM&MPLS
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.
|
|