NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/dcom/cellrel/385

Text File | 1992-08-25 | 3.7 KB | 75 lines

Newsgroups: comp.dcom.cell-relay
Path: sparky!uunet!pipex!warwick!str-ccsun!ccsun.strath.ac.uk!craa85
From: [e-mail] ( D.W.Stevenson)
Subject: Re: Future of IP routers
Message-ID: <[e-mail]>
Sender: [e-mail] (News account )
Nntp-Posting-Host: coll
Organization: University of Strathclyde
References: <[e-mail]> <[e-mail]>
Date: Wed, 26 Aug 1992 09:29:45 GMT
Lines: 62

In article <[e-mail]>, [e-mail] (Allen Robel) writes:
|> In article <[e-mail]>
|> [e-mail] ( D.W.Stevenson) writes:
|> > The requirement of each packet to be placed in memory is a feature of an
|> IP
|> > router, which is a 'store and forward' device. 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.
|> >
|> > However, the
|> > installed base of IP equipment means that this is not going to happen in
|> the near
|> > future. In addition, ATM is being pushed by the telcos for their own
|> commercial
|> >
|>
|> There may be another reason why this will not happen for a while.
|> The routers we have installed now allow for very flexible security
|> filters (TCP port #, network or host address, protocol, etc). These
|> features are not an inherent part of the design of ATM switches.
|> Features such as these will certainly need CPU support (as opposed to
|> CPU-less switching in silicon).  Anyone have an idea how this
|> functionality would map onto ATM?

In the telco scheme of things, security is a problem which handled by the network,
when a call connection is set up. This is at odds with the way IP works. IP is
designed to be processed in software, not in silicon, and this may mean there
is no easy way of carrying out the filtering you suggest. Certainly, some means
of associating different segments of the same packet would be required, possibly
requiring reassembly of the packet before filtering can be carried out. This
may not be strictly necessary though since the ATM netowrk will guarantee that the
cells will travel through the network in the order in which they are
transmitted. It may therefore be possible to use a FIFO mechanism to store
contiguous cells of one packet and filter on the payload in hardware,
discarding cells of a packet which does not pass filtering. Each packet is
delimited by the SDU-type field of each cell. This does not explicitly
require store and forward operation of the whole packet, since cells up
to the point where filtering fails can be forwarded and the rest dropped, and
the receiving AAL entity will receive the forwarded cells but drop the
whole packet when it realises some of the cells are missing, possibly
indicating an error to the recieving device though.

I know that this can be done at the
|> traditiional network/transport layers in routers that live at the edges
|> of the ATM cloud, so this function is taken care of for data traffic,

|> but routers currently don't handle video/voice traffic that well...

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.


--
Dave Stevenson                 [e-mail]
Computer Centre                Tel : [phone] x3461
University of Strathclyde
Glasgow, U.K.