From: jtw@lcs.mit.edu (John Wroclawski)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Future of IP routers
Date: 27 Aug 92 01:34:49 GMT
	<1992Aug25.123428.26295@ccsun.strath.ac.uk>
Organization: MIT Home for Wayward Triumphs


In article <1992Aug25.123428.26295@ccsun.strath.ac.uk> craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:

    Currently available commercial [IP] routers can only
    handle a fraction of the full packet processing rate of FDDI...
    At faster speeds, the backplane over which all packets pass
    between incoming and outgoing ports soon becomes the bottleneck.

    This problem will be overcome when people start using ATM based
    backplanes internal to the router.

I don't understand this point. You appear to be describing the
difference between a time-division "bus" backplane and a parallel or
"switch-fabric" backplane. ATM has nothing to do with this; either
design can be used to switch either IP or ATM.

    The requirement of each packet to be placed in memory is a feature of
    an IP router, which is a 'store and forward' device. 

There is no particular reason you can't build a cut-through IP router;
I believe (but am not positive) that cisco's current high-end product
works this way. You need only to look at the first few bytes of the
packet before you start sending it; this is the same as looking at the
VCI of an ATM cell.

    An ATM switch does not require to store cells and this suggests that
    the most efficient method is to use ATM equipment to perform routing
    (in silicon) as you suggest.

This is true only in the simplest case. Any switch which can
adequately handle congested links will have queues; cells stored in
memory. Switches which support prioritized traffic or bandwidth
reservation will likely want to process these queues out-of-order,
changing them from FIFO's to random access. Bellcore's Sunshine is an
example of such a switch.

   The ATM switch advantage is that the ATM switch will not require
   the intervention of a processor to route a cell, unlike an IP
   router which is a 'store and forward' device. IP routing requires
   the flexibility and processing power of software to process the
   header, even without IP fragmentation. 

This distinction seems rather artificial. IP routing and ATM switching
require exactly the same fast-path operations: classify packet/cell
(IP, based on dest address; ATM based on VCI), look up next hop
information, send packet/cell to correct output port. Store-and-
forward vs passthrough doesn't affect this. Implementation of even a
minimal queue management scheme requires adding decision-making power
to the ATM switch; in a pure ATM scheme queueing decisions are likely
made per-cell, which takes more processing power than making the
equivalent decision in an IP router because ATM cells are smaller. 
In both cases the actual route calculation is done out-of-band.

[From a different article]

   Because routers are store and forward, I would have thought that time
   critical traffic such as video/audio traffic would be very difficult
   to pass across a router at high speed. Since the telcos are billing
   ATM as ideal to carry multimedia traffic, this implies that the idea
   of using ATM routing at the network level is more suitable for high
   speed multi media traffic than IP.

Several issues interact here. First, one has to compare the latency
allowable in a system against the latency introduced by various
components. On a 1GB link, a 1000 byte IP packet occupies roughly 8
microseconds, meaning that an optimal store-and-forward introduces
about 16 microseconds of delay over optimal pass-through. Queueing
delay in the presence of loaded links is likely to be a more
significant issue. Here ATM has an advantage because the minimum delay
is smaller (since cells are shorter), but IP may have an advantage
because the larger packet size gives you more time to run a management
algorithm. The question of what sort of quality-of-service (queue
management) to provide in a switch is open, but there seems to be
general agreement that -something- is required.

				-john

John Wroclawski
jtw@lcs.mit.edu
Newsgroups: comp.dcom.cell-relay