HDTenEightyP/NetNews huggingface dataset:
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Future of IP routers
Date: 31 Aug 92 13:41:45 GMT
Organization: Naval Research Laboratory, DC

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

>The point I am trying to make is that IP is 
>designed to route packets, and by route I mean
>direct the packet to the next router on it's 
>journey. Functionality of the ATM layer seems to
>perform the same function (substitute 'ATM' for 'IP', 
>'cells' for `packet` and 'switch' for 'router' 
>in the last sentence)
>and hence there is a wasteful overlap in 
>functionality when you have to reassemble 
>at each intervening router for router software to process. 

  Not at all the same function.  IP performs dynamic routing with the
path traversed (by packets from source A to destination B) changing
all the time based on loading, congestion, and whatever.  With ATM,
routing is done only once (from source A to destination B) -- only at
call setup time -- and so ATM does switching at switches rather than
routing at switches.  If the ATM path chosen at call setup time has a problem
(e.g. a switch fails) then connectivity is completely lost.  If an IP router
dies, the other routers will automatically and dynamically route around it
until it comes back up and connectivity is not lost.

The distinction is not a trivial one.
Newsgroups: comp.dcom.cell-relay
From: bantha.decnet.lockheed.com!young
Subject: Problem # 4
Reply-To: young@bantha.decnet.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Thu, 3 Sep 92 21:25:53 GMT


Try this problem:

I want to command a group of desktop computers distributed over
the enterprise, possible for performing some management utility
on all simultaneously.  So I build a directed graph from my desktop
to all the desktops for which I wish control.  I need to solve
the following problems:

Message Acknowledgement:

1-a) I have one entry point VCI, which then branches down into the leaves 
of the directed graphs.  For acknowledgment, can I execute a protocol 
within the network which collects the available acknowledgments at each 
node, then on collecting the proper amount passes it up the tree?

1-b) If a node requires an acknowledgment, can the control root pass
down a re-transmission which passes just to that branch?

Graph Building:

2) When building my directed graph, can I explore the total set of
desktops, perform some local test to see if this is the desktop I want,
then return either true or false to the network branch?  The network
branch then using this indicator to determine if the directed graph should
pass through its internal node, thus updating the VCI?

Topology Extraction:

3) Again, can I extract the topology of my directed graph, then just
slip messages down a sequence of logical hops to reach a particular
logical node, then possibly moving back into parallel transmission mode?
Matt Young
Lockheed
(408) 756-6789
From: finn@isi.edu (Greg Finn)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Future of IP routers
Date: 4 Sep 92 00:48:37 GMT
Reply-To: finn@dalek.isi.edu (Greg Finn)
Organization: USC-Information Sciences Institute

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
Newsgroups: comp.dcom.cell-relay
From: craig@sics.se (Craig Partridge)
Subject: re: Out of order messages
Organization: Swedish Institute of Computer Science, Kista
Date: Fri, 28 Aug 1992 16:08:48 GMT

> 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
Newsgroups: comp.dcom.cell-relay
From: tjs@uh.msc.edu (Tim Salo)
Subject: Re: Advertising Flame !
Organization: Minnesota Supercomputer Center, Minneapolis, MN
Date: Sun, 23 Aug 1992 21:13:33 GMT

In article <BtC347.Cuq@usenet.ucs.indiana.edu> robelr@mythos.ucs.indiana.edu writes:
>	[...]
>The original charter for this group DOES consider the posting
>of product announcements to be a legitimate topic of discussion.
>	[...]

I very much want to see ATM-related new product announcements in this
news group.

To the extent that an implicit part of the mission of this news group
is to help make ATM a success, this news group ought to help ensure 
that those with ATM products and those who need to acquire ATM products 
know about each other.

By the way, at the risk of being flamed for crass commercialism, we
are developing an RFI for ATM products which we would be happy to
share with the group.

Tim Salo
tjs@msc.edu
(612) 626-0347
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.cell-relay
Subject: Re: >>>>Future of IP routers
Date: 1 Sep 92 02:50:28 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <Btv855.11w@usenet.ucs.indiana.edu>, "Gary C. Kessler, +1 802-879-3375" <KUMQUAT%SMCVAX.BITNET@mitvma.mit.edu> writes:
> Vernon - Why does the TCP sender have to wait for two token circulations
> before it can recapture the token if it passes it on due to timer expiration.
>
> I am assuming that the TCP sender is an asynch application rather than a synch
> application (in FDDI terms), so there is no "guaranteed" bandwdith.  But
> even in that case, if the token arrives "early" during the next rotation,
> why can't the TCP sender seize it?

You can only capture the token when the Token Rotation Timer, TRT, has
not expired.  When the token first leaves the TCP sender and comes
back, the token will still be "late."  So the TCP sender will wait for
the next pass.  This also applies to the station immediately downstream
of the TCP sender.  On the first pass of the token, this 2nd station
will consult its own Token Rotation Timer, decide the token is late,
and be unable to grab it to transmit.  When the token leaves the TCP
sender the second time, this 2nd station will see the token is early,
can grab it, and can transmit.  This applies to all stations around the
ring until the token gets back to the TCP sender on its second
rotation.  If it is still early, the TCP sender can grab it and resume
sending.

That's a lot of confusing words to describe something that is obvious
with a few diagrams.  It is a surprising notion, that every TRT
expiration implies a "wasted, deadhead" rotation of the token around
the ring.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.dcom.cell-relay
From: craa85@ccsun.strath.ac.uk ( D.W.Stevenson)
Subject: Re: Future of IP routers
Organization: University of Strathclyde
Date: Fri, 28 Aug 1992 09:23:20 GMT

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

|> 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. 

The point I am trying to make is that IP is 
designed to route packets, and by route I mean
direct the packet to the next router on it's 
journey. Functionality of the ATM layer seems to
perform the same function (substitute 'ATM' for 'IP', 
'cells' for `packet` and 'switch' for 'router' 
in the last sentence)
and hence there is a wasteful overlap in 
functionality when you have to reassemble 
at each intervening router for router software to process. 

In the future, it should be possible to open a data 
connection from my workstation to another workstation
in another country directly over the ATM network, 
without going near an IP (or OSI equivalent) router and
hence will the IP routing layer (or it's OSI equivalent) 
really be necessary? 

To achieve interoperability
with other non ATM workstations it certainly will be, but 
functionally, I suspect not. Studying the ISO
IP protocol I see "When the source and destination stations 
are connected to the same network, an
internet protocol is not needed. In that case, the internet layer 
is null and the (internet) header consists
of the single protocol identifier of 8 bits." 
(taken from "Handbook of Computer Communications Standards"
Vol 1 by Stallings). Surely once I can open an ATM connection 
from my workstation to your workstation, 
passing across the world, through the global ATM network of switches, 
we then become connected to the same network
and so no internet layer is needed and IP routers or equivalent 
will no longer be required for data transfer over the ATM network. 

The use of a null internet layer is a more accurate way of describing
the use of AAL as a network level protocol.

The original subject of this posting was whether IP routers would be
required in the future, or did I miss the point of the original posting?

If I've missed something, or I'm talking rubbish, please tell me. I'm 
a relative newcomer to the ATM field.

-- 
Dave Stevenson 				d.w.stevenson@strath.ac.uk
Computer Centre Communications		Tel : 041-552 4400 x3461
University of Strathclyde
Glasgow, Scotland, U.K.
From: de@fokus.gmd.de (Dirk Elias)
Newsgroups: comp.dcom.cell-relay
Subject: AAL5-CRC32
Date: 3 Sep 92 16:07:26 GMT
Organization: GMD-Fokus (Berlin)

I've got some questions and comments concerning AAL5-CRC32 calculation.
Everybody is welcome for answers and comments!

1. Does anybody know something of fast software algorithms to compute CRC32?
The fastest I know is based on look-up tables and will take 16 instructions
per 32 bit. This results in about 70 MIPS for a bitrate of 150 Mbps!
Definitely to slow. 

So, if there is no possible software solution, let's take a look on the hardware,
exclusively for AAL5-CRC32. You will need a CRC-chip and glue-logic, consuming
"lots" of board space and wasting power for almost nothing!

Say you have different VC's using AAL5, then you will receive cells from different
VC's in any interleaved order. As already mentioned by Craig P., Rob W. and
Brian C. (followup to reordering thread), there are two major ways to calculate
CRC by hardware. One is "on-the-fly" while receiving a cell from the ATM layer,
the other is "fly-by" upon transmitting a reassembled packet from the AAL layer
to the next higher layer.


-- 
------------------------------------------------------------------------------
From: Dirk Elias                     Tel. ++49-30-25499-245
      c/o GMD-Fokus                  FAX  ++49-30-25499-202
      Hardenbergplatz 2              e-mail: elias@fokus.berlin.gmd.dbp.de
      1000 Berlin 12
      F.R.G.
-----------------------------------------------------------------------------
Newsgroups: comp.dcom.cell-relay
From: craa85@ccsun.strath.ac.uk ( D.W.Stevenson)
Subject: Re: Future of IP routers
Organization: University of Strathclyde
Date: Mon, 31 Aug 1992 15:15:29 GMT

In article <3476@ra.nrl.navy.mil>, atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
|> 
|>   Not at all the same function.  IP performs dynamic routing with the
|> path traversed (by packets from source A to destination B) changing
|> all the time based on loading, congestion, and whatever.  With ATM,
|> routing is done only once (from source A to destination B) -- only at
|> call setup time -- and so ATM does switching at switches rather than
|> routing at switches.  If the ATM path chosen at call setup time has a problem
|> (e.g. a switch fails) then connectivity is completely lost.  If an IP router
|> dies, the other routers will automatically and dynamically route around it
|> until it comes back up and connectivity is not lost.

I agree with what you say except IP is not responsible for providing
a guaranteed delivery. It is the responsibility of the transport layer to ensure
delivery. Therefore even if an ATM connection dies, the transport layer
will request a retransmission and hence a new connection, 
perhaps via a different switch, 
and retransmit up to the point where the connection died. 

The public ATM network will presumably have the same level of 
switch and route redundancy as current telco networks
and so an alternate route should be available if a switch fails. The overhead 
in re-establishing a connection will be small and I presume the rate
of switch failure will be small also. These are the sort of things that
only experience will show.

One feature of the ATM network is that it has very low error rates 
since it's running over fibre all the 
way. Congestion will hopefully not be too much of a problem (but don't
quote me on that!) since bandwidth is requested at call set-up time.

I do understand what you are saying though - routers separate
a huge connection orientated network into a number of smaller 'connection
domains' (my words) which will increase fault tolerance in large internetworks.

-- 
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.
From: craig@sics.se (Craig Partridge)
Newsgroups: comp.dcom.cell-relay
Subject: followup to reordering thread
Date: 30 Aug 92 16:42:36 GMT
Organization: Swedish Institute of Computer Science, Kista

> 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).
 
Yes.  You receive cells and store them sequentially in a buffer.  When
you have a complete PDU, you do the AAL CRC, and pass the packet up to
higher layers.  
 
> 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?

Yes.  That's what AAL 5 is all about.

Craig
From: finn@isi.edu (Greg Finn)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Future of IP routers
Date: 28 Aug 92 21:57:31 GMT
Reply-To: finn@dalek.isi.edu (Greg Finn)
Organization: USC-Information Sciences Institute

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.  I don't think that this will be the
>ultimate protocol performance for high speed networks.

	TCP/IP is an internetwork protocol suite.  Packets are just
data.  I send packets across my 600 Mb/s network at 400 Mb/s to hosts.
Operating system architecture, processor speed, and workstation
hardware architecture are currently the strong limits to
communications performance and they have little if anything to do with
protocols.  They exist no matter what protocols you pick.

	To give you a concrete example, for a typical Sun workstation
it is difficult to make programmed-loop memory transfer exceed 60
Mb/s.  You find out very quickly when you build high-speed LANs that
the inefficiency of protocol implementation ranks well down the list,
behind operating system architecture, interface architecture, memory
architecture, bus speed, and finally, processor speed.  After you fix
those problems, a particular internet protocol suite may become an
important limitation, but not before.
--
Gregory Finn	(310) 822-1511
Information Sciences Institute, Marina Del Rey, CA 90292
Newsgroups: comp.dcom.cell-relay
From: gja@mullian.ee.mu.oz.au (Grenville Armitage)
Subject: Re: Future of IP routers
Organization: Basket Weavers, Inc.
Date: Tue, 1 Sep 1992 00:41:05 GMT

In article <1992Aug31.133020.10227@dxcern.cern.ch> brian@dxcern.cern.ch (Brian Carpenter   CERN-CN) writes:
	[...]
>Then the procedure to establish an IP
>based session to foo@bar.sna.fu would be
> - issue DNS request for that address
> - if reply indicates a specific VCI/VPI pair, use it immediately
> - if reply indicates an E.164 address/subaddress, invoke Q.93B
>   to establish VC/VP (unless already open)
> - else go to non-ATM processing

I've some concerns with the way you use VCI/VPIs here. They are not
world-wide unique addresses, and they are not even world-wide unique
connection identifiers. A given virtual circuit/connection (I'm a
little uncertain of my terms here :) traversing multiple ATM switches
and physical fibres from point A to B will probably change VCI at each
switch, and possibly VPI too (depending on actual implementations
and how VPIs are mapped to service qualities, if at all, on each
switch-fibre-switch segment).

For a user connected to an arbitrary local ATM switch it is unlikely
the DNS will be able to return a VCI/VPI pair having any meaningful
value. The VCI/VPI which finally carries IP packets into foo@bar.sna.fu
will be different to the the VCI (and/or VPI) that any given user
needs to send packets to their local ATM switch on.

Yes, it may be possible to request fixed VCI/VPI pairs be mapped to
known endpoints - and by association be mapped to known IP addresses.
But with only 2^16 VCIs and 2^8 or 2^12 VPIs (depending on your
perspective) available, fixed mappings are not likely to be supported
on a large scale when we are competing with all the other telco services
on B-ISDN.

Just my observations.

gja
Newsgroups: comp.dcom.cell-relay
From: "Gary C. Kessler, +1 802-879-3375" <KUMQUAT%SMCVAX.BITNET@mitvma.mit.edu>
Subject: RE: frame relay specs?
Organization: Indiana University
Date: Fri, 28 Aug 1992 14:04:00 GMT
X-Vms-To: IN%"comp.dcom.cell-relay@ucs.indiana.edu"

Are you looking for the standards?
 If so, check out ANSI T1.606, 617, and 618, as well as CCITT Rec. Q.922.
 Also, Sprint has their own specification, and more information can be had
 from the Frame Relay Forum (contact aferris@interop.com for FRF info)

Netrix, Sprint, WilTel, and some others have put out some nice overviews
of frame relay, how it works and why.

Hopefully this gets you started in the right direction...

/gary kessler
MAN Technology Corp.
802-879-3375
kumquat@smcvax.bitnet
Newsgroups: comp.dcom.cell-relay
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: The Priority Bit
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 28 Aug 1992 10:29:16 GMT

[Sorry this is so late. Somehow comp.dcom.cell-relay fell out of my .newsrc
when I wasn't watching... ;-}  ]

walvdrk_r@research.ptt.nl (Kees van der Wal) writes:
+---------------
| However there's no agreement whatsoever on how this bit should be used,
| so any comments on this issue are welcome.
+---------------

In AAL5 discussions, there had been the suggestion that when a station is
deliberately overdriving the bandwidth allocation (somewhat like frame relay
gets used in off-hours) that the host should set CLP on all cells *except* the
AAL5 end-of-frame cell, to lessen the probability of losing the end-of-frame
cell and so to make packet-loss detection easier.

I don't know if that's still being considered or not...


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Newsgroups: comp.dcom.cell-relay