HDTenEightyP/NetNews huggingface dataset:
From: miw@cc.uq.oz.au (Mark I. Williams)
Subject: Re: Future of IP routers
Organization: Prentice Centre, University of Queensland
Date: Thu, 27 Aug 1992 23:35:01 GMT

robelr@ucs.indiana.edu (Allen Robel) writes:

>OK, I can see how this would work.  But, how do you (or others)
>see segmenting the address space to reflect various service
>offerings (e.g. 900 calls, 800 calls in todays phone system).
>If services are not somehow reflected in addresses, and at
>a much higher granularity than that in the example I gave above,
>we will be faced with having to either build very large
>filters to accomodate every possible connection an end-user
>might want to make, or build smaller, more restrictive, filters 
>which say, in effect, "Allow connections to X, Y, Z but deny 
>everything else."  Much more useful would be the ability to
>wildcard parts of the address that represented specific service
>offerings (i.e. 1???1112222 might mean all interactive video services).
>This somehow seems unrealistic though. Someone please straighten me 
>out if I'm missing  something...

Not so much straightening you out as reminding you that ATM filtering
will not be carried out at the packet level, but at the virtual circuit
level. That is, it will not be the ATM layer that does the filtering,
but the management entities, and they will do it as part of call
acceptance.

Think of the ATM network as a link layer, like an Ethernet with bridges.
There is a routing function there, and there may even be some firewalls,
but there is no real "filtering" as such there.

If you want the functionality of a router, you will still need to have a
router, which will connect to other routers via Virtual Circuits.
Inter-router connections may even have several virtual circuits to provide 
different types of service depending on IP options or their equivalent.

If you think of ATM filters as only having to be activated at
call-setup instead of at every layer-3 packet, and having to function on
a timescale of perhaps 100 milliseconds instead of 100 microseconds, the
task seems somewhat less formidable. After all, current telco switches do this
all the time, and the first telco ATM switches will be present-day telco
switches, but with ATM switching fabrics.

The SMDS service is a horse of a different colour. It will be, in
effect, an ATM service where a virtual circuit is set up for each MAC
frame. I can see how this will work for MANS, but don't see how it can
hope to work well over a (possibly global) LAN. This may well be due to
lack of understanding on my part, however.

cheers,


--
Mark Williams         The University of Queensland       miw@cc.uq.edu.au
+61 7 36 54012   (w)  Prentice Centre
+61 7 36 54477  (fax) Qld 4072  Australia
Nullum magnum ingenium sine mixtura dementiae fuit.  -- Seneca
From: robelr@ucs.indiana.edu (Allen Robel)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Future of IP routers
Date: 26 Aug 92 00:03:09 GMT
Article-I.D.: usenet.BtKDH9.7M7
Reply-To: robelr@mythos.ucs.indiana.edu
Organization: Indiana University

In article <1992Aug25.123428.26295@ccsun.strath.ac.uk>  
craa85@ccsun.strath.ac.uk ( 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?  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...

--
Allen Robel                      robelr@mythos.ucs.indiana.edu
University Computing Services    ROBELR@IUJADE.BITNET
Network Research & Planning      voice: (812)855-7171
Indiana University               FAX:   (812)855-8299
Newsgroups: comp.dcom.cell-relay
From: bantha.decnet.lockheed.com!young
Subject: Re: Bare Bones Adaptation
Reply-To: young@bantha.decnet.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Thu, 3 Sep 92 14:51:26 GMT

In article <9224710.1007@mulga.cs.mu.OZ.AU>, gja@mullian.ee.mu.oz.au (Grenville Armitage) writes:
>In article <1992Sep2.222815.9025@infodev.cam.ac.uk> dm@cl.cam.ac.uk (Derek McAuley) writes:
>	[..]
>>Seriously, is AAL5 *the* bare bones adapt(at)ion layer, or did it
>>simply force the CCITT to realise they hadn't solved all the worlds
>>future networking problems with AAL1/2/3/4, .... ? (Rhetorical.)
>
>It's imprecise to refer to _any_ of the AALs as *the* AAL,
>since each one is considered to be the answer to a different service.
>AAL5 is the packet-peoples response when AAL3/4 was considered to be
>an inefficient answer to packet-peoples requirements.
>AAL1 and 2 are the proposed answers to the question at the start of 
>this thread (digitised audio). AAL5 is not aimed at providing a better 
>answer to this style of service.
>
>gja

I can understand that the CCITT standards groups will define some AAL
layers to help get the market moving, but technically, what is it inside
of the ATM network which requires knowledge of the users particular 
AAL usage?

The network just cares about quality of service:

1) Priority and discard status
2) Burst rates, average and deviation
3) Latency requirements

What is it about the network which requires knowledge of the user's
messaging format?  The network only needs to decipher set up and control
messages.  Otherwise the network need not define, impose, control, or 
otherwise interfere with the process of defining adaption layer message 
formats. What am I missing?
Newsgroups: comp.dcom.cell-relay
From: bantha.decnet.lockheed.com!young
Subject: Re: Future of IP routers
Reply-To: young@bantha.decnet.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Fri, 4 Sep 92 13:02:26 GMT

In article <22332@venera.isi.edu>, finn@isi.edu (Greg Finn) writes:
>In article <1992Sep3.094148.21738@ccsun.strath.ac.uk> craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:
>
>>|>     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.
>
>>You are right in saying ATM has nothing to do with this. I'm just pointing out
>>the current limitations of high end commercial routers, which use time division
>>backplanes whereas in the future, in order to get the increased backplane
>>throughput required to match the increase in packet processing power of each
>>interface, they will use switch fabric backplanes instead. ATM is the most likely
>>candidate because ATM silicon will soon be available, in quantity and at low cost.
>
>	Hmmm, you seem to have your time-line reversed ... non-ATM
>variable length packet switching fabric chips have existed in silicon
>for some time.  You can order such animals from Intel.  Their
>point-to-point channel speeds are 1.2 Gb/s.  Each chip manages and
>routes several channels simultaneously.  They form a 2-D mesh and are
>the basis for large-scale multicomputing.
>
>	They aren't cheap ... but then again they are 10 times faster
>than ATM chips.  The non-existence of high-speed routers seems to
>reflect a lack of market and not a lack of high-speed routing logic.
>A highly regarded engineer at Cisco said that recently.
>
>--
>Gregory Finn	(310) 822-1511
>Information Sciences Institute, Marina Del Rey, CA 90292

In fact some of these existing fabric switches are currently being used in
new ATM designs, as well as ethernet switch desings.  Especially the
matrix switch chips made by a number of vendors.
Matt Young
Lockheed
(408) 756-6789
Newsgroups: comp.dcom.cell-relay,comp.dcom.lans.fddi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: >>>>Future of IP routers
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Wed, 2 Sep 1992 13:06:06 GMT

In article <Btx5JH.2t7@usenet.ucs.indiana.edu>, KUMQUAT%SMCVAX.BITNET@mitvma.mit.edu (Gary C. Kessler, +1 802-879-3375) writes:
> If a station on an FDDI ring releases the token because its own TRT has
> expired, it does NOT necessarily follow that anyone else who follows that
> station will also see a "late" token.  Since we all have the same target
> token rotation time (many feel that 8 ms. is an ideal value) and independent
> TRTs, it really depends upon the amount of synchronous bandwidth that is
> allocated and used.  Thus, it is possible that I will see an "early" token,
> use up my entire TRT time (i.e., the entire amount of the earlyness), pass
> it on to you, where you will also see an "early" token.
> 
> Yeah, this is hard to do in just prose...


I don't see how any synchronous bandwidth allocation can make the
token appear to arrive earlier with respect to the local TRT than
otherwise.

The Token Rotation Timer of all stations downstream of the station that
is currently transmitting and about to have its own TRT expire are
"earlier" and closer to expiring than the transmitting station.  That
is because the transmitting station saw the token most recently (it was
the last station to see the token) and so reset its own TRT most
recently.  All other stations on the ring are certain to think the
token is even more "late" than the transmitting station whose on TRT
expired.

Some of us do not think much of an 8 ms.  For example, an 8 ms TTRT on
a ring with 1 ms latency limits the maximum possible bandwidth between
any pair of stations to about 77Mbit/sec.  I think maximum bandwidth
goes something like (TTRT-latency)/(TTRT+latency) with a correction for
the frame being transmitted when TRT expires.  A maximum sized ring
with a 1.67 ms latency and 8 ms TTRT permits only 65 Mbit/sec between
any pair of stations even when the rest of the ring is completely
idle.  That is just plain silly!


Vernon Schryver,  vjs@sgi.com
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Future of IP routers
Date: 27 Aug 92 22:27:10 GMT
Organization: Naval Research Laboratory, DC

In article <1992Aug27.174448.28143@fokus.gmd.de> icarus!mbu@fokus.gmd.de (M. Burak) writes:

>Do you really think that TCP/IP over B-ISDN will be the real challenge? As far
>as I know, TCP/IP allows you a throughput of 28 Mbit/s over a 140 Mbit/s 
>network.

Gee!  You must have seen a very badly designed or tuned or implemented
network.  I've seen experimental results MUCH MUCH better than that
for IP over ATM.

> I don't think that this will be the ultimate protocol performance for
> high speed networks.  Isn't it better to use faster and probably new
> protocols on top of the B-ISDN protocol stack?

	I myself fully expect to live in a multiprotocol world.  IP
will not go away soon and neither will CLNP.  There are proposals
afloat in the IETF right now for an IP-followon and it is far from
clear where that will end up heading.  There is a lot of evidence that
IP isn't intrinsically slow.  Certainly implementing IP in silicon is
both fast and feasible and not overly expensive.

> Another point is that I don't understand the whole discussion about IP
> Routers. Nobody writes that in the B-ISDN there will be Connectionless
> Servers, taking care of routing *and* security and address screening
> and all other management related stuff. 

	CCITT ain't published how they plan to do that.  Until they
do, claims that it will be done right cannot possibly be supported.
Exploring alternative approaches seems like The Right Thing to do at
the present time.


Ran
atkinson@itd.nrl.navy.mil
working for, but not speaking for, the Naval Research Laboratory
Newsgroups: comp.dcom.cell-relay
From: bantha.decnet.lockheed.com!young
Subject: Re-order
Reply-To: young@bantha.decnet.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Fri, 28 Aug 92 18:14:36 GMT

More on the Cell Re-ordering Thread

>> This is a simple question, but I can't seem to track down
>> a definitive answer:  Is it possible for ATM cells when
>> providing a connection based service to become out of order
>> after traversing multiple switches?  Some specifications
>> start from either answer in their development of protocols.

>I've yet to see an ATM spec that says cells can be re-ordered.

>I have seen a number of papers on cell network design that argue that
>permitting cell-reordering would be nice.

>The reason is that (at least with current state of the art),
>*ensuring* that no reordering occurs is rather expensive, and
>one can build cheaper switches (and more flexible LANs) if one
>does not have to ensure that no reordering occurs.
>Craig

OK, then as a follow up:

1) On the other thread concerning routing over ATM, are the numbers
quoted (20-1,000 Mbps for TCP/IP forwarding rates) assuming no cell 
re-ordering occurs?

2) If no re-ordering occurs, does that mean that all I have to do
is collect the sequence of cells that have arrived on a VCI/VPI pair,
perform some application (TCP,TP4 etc) dependent error control on the
assembled packet, then just use the data (if re-transmission not needed).

If the adaption layer is that simple under the no-reordering rule, then
why not pay the price in additional switch sophistication and get the
huge return in having a much simpler adaption layer?

If re-ordering is then not allowed, then doesn't it make sense to have
a end-of-message, begin-of-message bit in the cell header?
Newsgroups: comp.dcom.cell-relay
From: jsims@uswest.com (John Sims)
Subject: Re: Future of IP routers
Organization: U S WEST Advanced Technologies
Date: Fri, 28 Aug 1992 15:17:02 GMT

In article <3466@ra.nrl.navy.mil>, atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
> In article <1992Aug27.174448.28143@fokus.gmd.de> icarus!mbu@fokus.gmd.de (M. Burak) writes:
> 
> >Do you really think that TCP/IP over B-ISDN will be the real challenge? As far
> >as I know, TCP/IP allows you a throughput of 28 Mbit/s over a 140 Mbit/s 
> >network.
> 
> Gee!  You must have seen a very badly designed or tuned or implemented
> network.  I've seen experimental results MUCH MUCH better than that
> for IP over ATM.

Could you be more specific about the environment in which these results
were acheived and exactly what IP over ATM results  you expect?
I have one of the early implementations of ATM for Suns and I see
throughput (Sparc2 to Sparc2) of 19.5Mbps TCP/IP over a 100 Mbps ATM interface.
So  the results reported by M. Burak seem in-line with my observations.
Not that someone couldn't produce a better implementation, so I'm asking if
anyone out there knows of one?

In article <p42ogng@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> 
> I do not understand the overall debate, nor the relevance of
> this point.  However, 28Mbit/se through TCP is a poor showing for anyone.
> 
> It has been about a year (maybe more) since T. Skibo reported
> 32Mbit/sec (33?) over a 300 mile TCP/IP link using FDDI and T3 IP routers
> between UNIX workstations.
> 
> Loacl TCP/IP speeds over FDDI (100 Mb/s) are 2 or more times faster
> in reasonable systems.  (Measured with `ttcp ... -s -l32768`)
> 
> 
> Vernon Schryver,  vjs@sgi.com

It seems obvious to me that (all other factors being equal) TCP/IP throughput
on an FDDI would be better than throughput on a 100Mbps ATM.   And of course
I'm talking about just having 2 stations on the FDDI, etc...  The overhead
that ATM adds to be able to support voice and video would make it less
efficient at carrying TCP/IP than an  FDDI.  Anyone disagree?


John Sims
U S WEST Advanced Technologies
jsims@advtech.uswest.com
Newsgroups: comp.dcom.cell-relay
From: berry@athos.pei.com (Berry Kercheval)
Subject: Re: High speed protocols
Reply-To: berry@pei.com
Organization: Protocol Engines, Inc., Mt. View, California
Date: Tue, 25 Aug 1992 14:17:34 GMT

>>>>> On Tue, 25 Aug 1992 12:08:00 GMT, "Gary C. Kessler, +1 802-879-3375" <KUMQUAT%SMCVAX.BITNET@mitvma.mit.edu> said:

Gary> XTP info. can be had from Protocol Engines, Inc.  I beleive you
Gary> can contact them at info@pei.com.  Alf Weaver
Gary> (weaver@virginia.edu) has co-authored a book on XTP and will be
Gary> happy, I know, to fax you an order form!

You can FTP the 3.6 version of the XTP spec from sgi.com.  It's in
directory 'xtp' and named something like  'xtp3.6.ps.Z'.

You can get on the xtp mailing list by sending a request to
xtp-request@pei.com.  As near as I can determine, 'info@pei.com' is
not a valid address.

  --berry

(Please don't mail *me* for XTP info.  I am not an XTP guru...)

--
Berry Kercheval :: berry@pei.com :: Protocol Engines, Inc.  Mt. View, CA
"Car pool fatigue: it's like shell shock, but you don't get any VA benefits.
They just fill your gas tank and send you back to the front."
Newsgroups: comp.dcom.cell-relay
From: bantha.decnet.lockheed.com!young
Subject: Re: AAL 5 query
Reply-To: young@bantha.decnet.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Thu, 3 Sep 92 13:03:21 GMT

In article <1992Sep2.121122.15112@ccsun.strath.ac.uk>, craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:
>Can somebody perhaps clarify my understanding of certain parts of AAL5:
>
>I'm looking at the situation where a host requires to have more than one 
>VC open at one time. In this case, one AAL entity is required for each
>connection. ATM-SDUs from each AAL are multiplexed/demux'd by a single
>ATM layer entity in the interface. This gives the following structure for 
>the interface:
>
>			 ATM physical connection
>				    |
>				    |  
>				ATM entity 
>				|   |   |
>			       AAL AAL  AAL
>				
>				   CPU
>
>
>
>In order to transfer information across a virtual connection, the user layer
>passes a MAAL-CREATE.request primitive (with the far end ATM_CEI and
>AAL_CEI as parameters) to initialise new AAL state machines for a new AAL 
>entity. 
>
>There is no primitive that is passed from the MAAL (or AAL) entity to the ATM
>layer which says "a new connection is being created, please assign a new
>VCI/VPI pair for use with this AAL and associate cells to/from this 
>VCI/VPI pair with this newly created AAL entity.". 
>
>As far as I can see, this means that the ATM layer is unable to demultiplex
>cells to the correct AAL entity, since firstly, the ATM layer doesn't know
>which VCI/VPI corresponds to which AAL and secondly, there is no parameter
>in the ATM-DATA.indicate primitive to identify a unique AAL entity to 
>which each ATM-SDU should be passed.
>
>A similar problem occurs when multiplexing outgoing cells at the ATM layer,
>because multiple AAL entities will pass cells to the ATM layer, but without
>any parameter to say which AAL they are from.
>
>This seems to mean that	without some
>method of identifying which AAL entity a VCI/VPI pair's incoming cells should 
>be sent to, only one connection i.e. one VCI/VPI pair can be supported on any
>interface using this scheme. 
>
>Was this deliberate in order to simplify the document, and such an association 
>is left for the reader to infer, or am I missing something very basic?
>
>Help would be appreciated.
>
>-- 
>Dave Stevenson 				d.w.stevenson@strath.ac.uk
>Computer Centre Communications		Tel : 44 41-552 4400 ext 3461
>University of Strathclyde
>Glasgow, Scotland, U.K. 

This seems like a basic question.  Can we have any answer posted to this,
please?
From: gja@mullian.ee.mu.oz.au (Grenville Armitage)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Future of IP routers
Date: 31 Aug 92 01:49:17 GMT
Organization: Basket Weavers, Inc.

In article <1992Aug30.021454.29795@u.washington.edu> gray@cac.washington.edu (Terry Gray) writes:
	[..]
>I believe --somebody correct me if this is incorrect-- that the same 
>issues will apply to ATM switches living in an IP environment.  For example,
>if an ARP packet (or any other broadcast packet) appears at one port 
>of an ATM switch, does it not appear on all other ports of the switch,
>assuming the appropriate AAL for handling the IP world?  

An ATM switch operates at the ATM cell level (once a virtual connection
has been established through it), no AAL level processing occurs, and 
switching occurs purely on the basis of the virtual connection
identifiers - the VPI and VCI in the cell headers. The closest you
might get to a broadcast retransmission of a cell out many (or all)
ports of a switch is on a VPI/VCI that has been marked as being a 
multicast channel. And this assumes the switch fabric supports multicast.

If your campus, or whatever, is completely connected by ATM then logical
IP subnets might be constructed using restricted multicast groups.
Logical IP routers would then exist to connect the subnets at the IP
level. However I suspect issues such as ARPing may be sufficiently
different in such scenarios that I wouldn't want to comment on whether
the IP router is needed for 'storm protection'.

gja
Newsgroups: comp.dcom.cell-relay