HDTenEightyP/NetNews huggingface dataset:
From: giddy@trl.oz.au (David Giddy)
Subject: B-ISDN technical workshop date ?
Reply-To: giddy@trl.oz.au
Organization: Telecom Research Laboratories
Date: Mon, 23 Nov 1992 04:24:37 GMT

Does anyone know when the 3rd B-ISDN Technical Workshop is to be held ?

The 2nd was held in Miazaki (sp?) in Japan in April this year. I gather the 3rd
will be held in France around the same time next year. Does anyone have any firm
dates and location ?

Thanks,

David.
______________________________________________________________________________
David Giddy,			                 |    Voice: +61 3 253 6388
Telecom Research Laboratories,                   |      Fax: +61 3 253 6144
P.O. Box 249, Clayton, Victoria 3168, AUSTRALIA  |      Net: d.giddy@trl.oz.au
X400: g=david s=giddy ou=trl o=telecom prmd=telecom006 admd=telememo c=au
------------------------------------------------------------------------------

Newsgroups: comp.dcom.cell-relay
From: David_Murphy@Novell.COM (David Murphy)
Subject: Re: Voice Applications
Organization: Novell, Inc.
Date: Mon, 16 Nov 1992 15:06:31 GMT

I would appriceate it if some kind person could e-mail me some information on
"wave", "wave route discovery", etc., places where I could FTP the information
or some References I could obtain.

Any help welcome, 
Thanks in advance

All comments my own, not my employers.


Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: 100 Base T
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Wed, 18 Nov 92 14:05:41 GMT

The 100 Base-T Challenge:

A couple of America companies have challenged the cell relay industry
with a 100 Mbps ethernet LAN technology.  Here is my opinion on how to
beat back the challenge:

1) Strong switched ethernet product

  The 10 Base-T customers need a lower speed (320 Mbps) cell relay
hub outfitted with 10 Base-T line cards for the switched ethernet
market.  Give this group an dual upgrade path, allowing them to defer
their high bandwidth decision, and then choose between a full cell
relay, FDDI, or 100 Base-T at a later date.

2) 10,20,40,80,100 Mbps line standards

  Settle on an asynchronous framing format for shielded and unshielded
twisted pair at all of the above speeds.  If possible utilize the
existing data transmission schemes, and the existing industry for
physical connectivity.

  Also settle on an asynchronous T1,T2 and T3 framing standard.

3) Continued Simplification of Adaptation Layer

   The adaptation layer is a market negative, and the 100 Base T folks
will beat us over the head with it.  Make sure only the bare essentials
are defined at this layer, defer the rest to the upper layers.  Then
drop the term adaptation layer, replace it with intelligent DMA. If
this technology is boiled down to a single chip, as suggested by Dan,
then the entire cell size issue goes away.

4) Simple Path Control

  Give the upper layers access to the path tables.  Do not get involved
in an addressing battle, let the network operating system folks fight
that one.

  
  Cell relay will win the battle provided the industry does not turn off 
the enormous army of software developers ready to develop path based
applications.


By the way:

  Great job Telematics on the super frame relay switch you've developed.

Newsgroups: comp.dcom.cell-relay
From: myoung@nebula.ssd.lmsc.lockheed.com
Subject: Re: fat cells (was Re: Computers dont like ATM?)
Reply-To: myoung@nebula.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Mon, 23 Nov 92 18:58:45 GMT

>
>Mark.Hayter@cl.cam.ac.uk (Mark Hayter) writes:
>>We have been using a system similar to this to allow interworking between
>>our ATM networks and the Ethernet for several years. The ethernet packet
>>contains the headers for all of the cells followed by the data - thus the data
>>is contiguous at the host. This system works well, and the router forwarding
>>code is efficient (since it is basically just doing cell forwarding).


  How far does the virtual path extend?

  In the data center, point to point optical links, with small windows,
and variable length packets will be the norm.  The model here is that high 
performance risc machines will be connected into a single loosely coupled 
system for data base operations mainly, but also for some finite element 
compute problems.

  If all the desktops do utilize ATM interfaces, then their interface
to the data center may be serving hundreds of users, each having up to
10-40 circuits open.  Each of the (up to 4000) messages will have to
be constructed from cells, and then sent to into the data center as
variable lenght packets.

Extending the virtual path:

  If the virtual path is carried into the data center, then this
interface does not have to be an address gateway.  Each user would
build connections directly to some end point. The data center would 
need to use the same virtual path structures for its internal 
communications, to provide uniform user access to distributed processes.

Result:

  Then doesn't this argue for "fat cells" being the variable packet 
equivalent for the fixed cell?  If we have sold the virtual path as a 
desktop interface; then the imperative is that it be continued into the 
data center. 

  Also, the fat cell definition would simplify the mapping to
traditional MAC layers.
Newsgroups: comp.dcom.cell-relay
From: walvdrk_r@research.ptt.nl (Kees van der Wal)
Subject: Re: B-ISDN technical workshop date ?
Organization: PTT Research, The Netherlands
Date: Mon, 23 Nov 1992 12:21:18 GMT

In article <1992Nov23.042437.29757@trl.oz.au>, giddy@trl.oz.au (David Giddy)
writes: 

> Does anyone know when the 3rd B-ISDN Technical Workshop is to be held ?
>
> The 2nd was held in Miyazaki in Japan in April this year. I gather the
> 3rd will be held in France around the same time next year. Does anyone have
> any firm dates and location ? 

If date and placed have been fixed already, Mme. Helga Seguin should know.
Fax: + 33 1 4629 3370, phone: +33 1 4529 4564.

Regards, <kees>

Kees  van der Wal                      e-mail: J.C.vanderWal@research.ptt.nl
Newsgroups: comp.dcom.cell-relay
From: jstone@netcom.com (Jeffrey Stone)
Subject: ATM adaptor boards - prototypes and sources
Organization: info/mation
Date: Sat, 21 Nov 1992 14:16:20 GMT

There are at least 7 organizations preparing ATM silicon for use in
LAN products.

Who is working on ATM adaptor boards for workstations or PCs?

I know only of Fore's boards.

Jeff Stone
info/mation   (no disclaimers ...  not yet anyway)

-- 

Jeffrey Stone		jstone@netcom.com		415.324.0443

Newsgroups: comp.dcom.cell-relay
From: mdh@cl.cam.ac.uk (Mark Hayter)
Subject: Re: fat cells (was Re: Computers dont like ATM?)
Organization: U of Cambridge Computer Lab, UK
Date: Fri, 20 Nov 1992 12:22:27 GMT

rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:
> Especially when end-to-end "ATM compatibility" can be achieved *without*
> ATM-sized cells in the LAN! I have been harping on an idea I call "fat cells",
> which is basically that you switch AAL_PDU-sized packets in the LAN, with
> exactly one ATM header on the front of the AAL PDU. When the packet is to be
> routed out of the LAN via "real ATM", as it chops it up into real ATM-sized
> 53-byte cells, the gateway switch can replicate the prototype header onto the
> front of each cell. (For AAL5, it must also set the "end-of-frame" indication
> in the header of the last cell in the PDU.) Naturally, it is also the respon-
> sibility of the gateway switch to reassemble incoming cells into PDUs (leaving
> a prototype ATM header on the front), and switch these "fat cells" (complete
> AAL PDUs) into the LAN.

We have been using a system similar to this to allow interworking between 
our ATM networks and the Ethernet for several years. The ethernet packet
contains the headers for all of the cells followed by the data - thus the data
is contiguous at the host. This system works well, and the router forwarding
code is efficient (since it is basically just doing cell forwarding).
 Data going from ATM->ethernet can be formed quickly into "fat cells",
being transmitted when a full ethernet packet has been formed or the AAL-5
"end-of-frame" indication is seen.

Mark

------------------------------------
Mark Hayter
Cambridge University Computer Lab
Mark.Hayter@cl.cam.ac.uk
Tel +44 223 334645
Newsgroups: comp.dcom.cell-relay
From: dgr@RODIN (Daniel Robinson)
Subject: Re: Computers dont like ATM?
Organization: Vitalink Communications, Fremont, California
Date: Wed, 18 Nov 1992 16:26:27 GMT

In article <1992Nov18.025754.14749@trl.oz.au> lampard@titan.trl.OZ.AU (Greg Lampard) writes:
+His claim was that small
+packets are good for delay-sensitive applications, but they make a lot
+of unnecessary work for the computer that has to receive them, since it
+has to process a header every 53 bytes,

Much of that processing will be done in silicon, not by a stored
instruction processor.

+He also seemed to be suggesting that this storage and retrieval process
+could become a bottleneck (at 100s of Mbit/s?) because of the limitations 
+of memory bandwidth.

This is the right number for a stored instruction processor that is
not a Cray.

+He was advocating variable length packets (an idea
+called PTM - packet transfer mode - that IBM has proposed), because it
+puts the complexity in the switch rather than in the receiving
+terminal. 

It is hard to see where a variable length packet will put the complexity
in the network mesh node, not the terminal node.  Remember that this
the company that brought us source routing.

Daniel Robinson
Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: UB
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Mon, 16 Nov 92 16:07:18 GMT

UB Business Plans:

Ungermann-Bass, one of the local hub vendors, is placing employment
ads asking for product managers to build third party support
for some product, but I cannot figure out what.  They are also 
asking for ATM designers, but its not clear whether this is not 
related to their previous announcement about supporting ATM on their
access one product line.

Has UB released any framework for a multi-vendor network architecture?
Is it on-line somewhere?  Any information on what we can expect from them?
Newsgroups: comp.dcom.cell-relay
From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
Subject: Re: fat cells (was Re: Computers dont like ATM?)
Organization: Motorola Codex, Canton, Massachusetts
Date: Mon, 23 Nov 1992 13:52:58 GMT

rjb17@cl.cam.ac.uk (Richard Black) writes:
>--
>In article <1992Nov20.150333.17701@iscnvx.lmsc.lockheed.com>, 
>myoung@force.ssd.lmsc.lockheed.com writes:
>>   OK, this seems to be the right tack for ethernet-ATM transfer.  I vote
>> to continue this thread, possibly leading to some standard mapping
>> between ethernet and cell relay.

>This is not the forum for such activity, even if such a standardisation was
>desirable.

Emily PostNews rule number 114, fascicle 43: don't propose discussion of 
extensions to standard protocols in a forum that is accessible without
paying international air fare...

Really, lighten up. This sounds like an interesting idea; I'm
delighted to hear that your lab is actually implementing something
very close to it:

Mark.Hayter@cl.cam.ac.uk (Mark Hayter) writes:
>We have been using a system similar to this to allow interworking between
>our ATM networks and the Ethernet for several years. The ethernet packet
>contains the headers for all of the cells followed by the data - thus the data
>is contiguous at the host. This system works well, and the router forwarding
>code is efficient (since it is basically just doing cell forwarding).

I'm curious as to why you chose to aggregate all the cell headers at
the front of the packet, rather than just the first - did this design
predate AAL5?

				Peter Desnoyers
--
From: finn@isi.edu (Greg Finn)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Computers dont like ATM?
Date: 21 Nov 92 22:30:18 GMT
Reply-To: finn@dalek.isi.edu (Greg Finn)
Organization: USC-Information Sciences Institute

In article <sjdveq8@sgi.sgi.com> rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:

>+---------------
>| When ATM-based LAN performance exceeds PTM-based LAN performance/cost,
>| ATM proponents will have a much better argument than they now have. 
>| Frankly, I don't forsee that happening in the electrical domain.
>+---------------
>
>Well, I do, actually. Sliding down the price/volume curve, and all that...
>Two-chip solutions that go from AAL PDUs to ATM cells to SONET line coding
>(and back) are not that far away, at least at 155 Mb/s.

	I don't doubt your statements about how cheap the ATM silicon
can be.  Virtually all CMOS chips have a unit cost of a few dollars or
less to manufacture in great volume.  But the simplicity of no
fragmentation/reassembly allows the network interface to be made so
small that it doesn't even require one complete chip, it fits onto a
small part of a microprocessor chip.  There are already existence
proofs.

	More pesky, but a problem for all fast LANs now is that Gb/s
class cable driver parts are very expensive.  Data is data and data
over distance at high speeds costs.  155 Mb/s allows one to use coax
for typical LAN runs between a workstation and the wiring closet down
the hall where the hub, concentrator or switch is kept.  I think it is
no coincidence that some 622 Mb/s ATM LAN projects have retrenched to
155 Mb/s.

	At Gb/s rates you can go parallel copper for about 30 meters.
We have characterized vanilla 25-pair phone cable to carry
differentially driven 110 MHz signals.  That seems to be about the
limit.  Skew and loss of margins impose limits.  Beyond 30 meters
fiber-optics is suggested.  It is here that things are still very
expensive.  You need sub-nanosecond parts.

	There are a lot of players trying to make this less expensive.
Parallel coax and parallel plastic fiber reduce the signalling rate,
better or much less expensive gigabit encoder/decoder chips, ...  I
have no feeling about what that may lead to in terms of cost
reductions.  Volume now is very low.



--
Gregory Finn	(310) 822-1511
Information Sciences Institute, Marina Del Rey, CA 90292
Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Variable Length Issues
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Thu, 19 Nov 92 15:38:30 GMT

In article <22909@venera.isi.edu>, finn@isi.edu (Greg Finn) writes:
>
>	Very true.  I co-developed a multi-gigabit LAN.  If a
>store-and-forward (or retrieve) operation is to occur without reducing
>the channel bandwidth, it requires memory that operates at twice the
>channel rate. 

I agree, this a valid complaint about ATM. However see below the 
argument on cut through switching.

But, having the capability for store and forward allows switches to
be connected in random mesh patterns without having to build the
cut through operation through an arbitrary number of nodes.

>
>	Packet storage within a switch should be avoided at high
>channel rates if practical and can be accomplished with cut-through
>routing.  This issue has nothing whatsoever to do with fixed versus
>variable-length packets.

Cut through is a little related to the fixed vs variable issue: cell 
relay like cut-through switching in small chunks.  But in essence I 
agree, having small fixed sizes does not prevent cut through switching, 
nor does it prevent all optical designs.

>I can say something about LANs.  PTM allows one to design LANs that are 
>exceedingly fast and that have tiny host interfaces that
>require no fragmentation/reassembly hardware.

And this is the strongest criticism, but:

Fragmentation allows slow speed devices to share the same switching 
bandwidth with higher speed devices, without bridging and allows arbitrary
mesh networks.  This is valid even in single sight installations.

Variable length with cut-through requires all devices to have channels 
at the same high rate to prevent congestion.  How do you design the same 
LAN to serve low cost PCs or high performance sstations without 
wasting the technical gains by adding bridges.  Bridges are now
quite common, and they include all the management hassles.

>	ATM is politically very popular.  Arguments that ATM brings
>about end-to-end compatibility do not impress me.  Most LAN traffic
>stays within the LAN.

Ah, but the most valuable (monetary) user traffic is often 
the WAN traffic, like distributed sales and inventory.

**************

Finally, what about the argument for dual priority and support for
short low latency messages?

**************
Additional Comments:

Variable length cut through certainly has a place in a perfect world,
unfortunately its not a perfect world and the two technologies will 
compete, and cell relay will compete effectively.

Perhaps we need a standard which allows a cell relay virtual path to 
reserve enough synchronous bandwidth to feed a variable length LAN
on the run, performing the re-assembly on the fly without a message 
store and forward? 

And dare we raise the cell size issue again, egad!
Newsgroups: comp.dcom.cell-relay
From: robelr@bronze.ucs.indiana.edu (Allen Robel)
Subject: Re: Comment made at Next Generation Networks conference
Organization: Indiana University
Date: Tue, 24 Nov 1992 04:49:24 GMT

In <sntb3jc@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>100Mhz ethernet may or may not be wonderful.  Very few people know any
>useful technical facts, and none that I think might know anything about
>it have said much.  You might as well talk about 1Gbit/sec packet radio
>if you're going to talk about wonderful millenial, cargo-cult stuff.
 
I honestly don't know what I said to invoke  or deserve this kind of 
response.  Vernon, I'm only trying to learn.  That's what this group 
is all about.  I don't claim to be an expert at any of this stuff.  
I'm just a user who knows enough to ask questions (or at least try).  
In the spirit of keeping this discussion group open to non-intimidating 
and free discussion, could you to please lighten up a bit.
 
thanks,
 
allen 
-- 
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: myoung@force.ssd.lmsc.lockheed.com
Subject: Sorting
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Wed, 18 Nov 92 15:36:10 GMT

In this application an arbitrary group of processors have been
already been allocated and their wave interpreters connected
in an arbitrary mesh network using virtual paths.  A list of data 
made available to one processor, and using the following simple
wave sort algorithm, the list is immmediately spread over a
binary sort tree, imposed upon the arbitrary mesh network.
As the tree is formed, processors are chosen from the list
of connections in an arbitrary order, some processors being
used to manage more than one node of the sort tree.  All synchronization
is automatic with the wave syntax.

WAVE Sort:

The tree node divides list of objects according to whether the upstream
list of items according if an object is greater than or less than the first 
item on the list.  A tree is created with the sorted items at the leaves of 
the tree.  The wave process is  ongoing, continuing to sort items as long as 
items are available in the upstream nodes.  That is as new records arrive
they are automatically sorted and distributed, new nodes formming as
required.

  At any given time, a secondary wave can be launched to collect
the items from the tree leaves in a sorted manner.


  Written in pseudo wave:


WAVE SORT:

   Frontal Storage:
         First Item
         List Pointer (either left or right)

   Nodal Storage:
         Left List, Left list index
         Right list, right list index

  WAVE GET NEXT ITEM
   Frontal Item:
        Obtained Item

   Propagate upstream
      Wait for next item in left or right list 
       according to list pointer

      Increment List pointer
      return

   If obtained item is less than first item then
      if obtained item is first object obtained that is
      less/equal than first item then
          Propagate WAVE SORT to a new down stream node, 
            obtained item is new first item and list pointer is left
           not wait for echo
      else
          add it to left list, increment index
      endif

      if obtained item is first object obtained that is
      more than first item then
          Propagate WAVE SORT to a new down stream node, 
            obtained item is new first item and list pointer is right
           not wait for echo
      else
          add it to right list, increment index
      endif
Newsgroups: comp.dcom.cell-relay
From: rjb17@cl.cam.ac.uk (Richard Black)
Subject: Re: fat cells (was Re: Computers dont like ATM?)
Organization: U of Cambridge Computer Lab, UK
Date: Fri, 20 Nov 1992 21:16:32 GMT

--
In article <1992Nov20.150333.17701@iscnvx.lmsc.lockheed.com>, 
myoung@force.ssd.lmsc.lockheed.com writes:
>   OK, this seems to be the right tack for ethernet-ATM transfer.  I vote
> to continue this thread, possibly leading to some standard mapping
> between ethernet and cell relay.

This is not the forum for such activity, even if such a standardisation was
desirable.

-----
Richard Black				(usual disclaimers)
University of Cambridge
Computer Laboratory
Cambridge
United Kingdom
Newsgroups: comp.dcom.cell-relay
From: "Gary C. Kessler, +1 802-879-3375" <KUMQUAT@SMCVAX.BITNET>
Subject: RE: NT1/NT2 question (2nd time around)
Organization: Indiana University
Date: Thu, 19 Nov 1992 21:03:00 GMT
X-Vms-To: IN%"comp.dcom.cell-relay@ucs.indiana.edu"

Jeff -- Your best source is back at the standard, which, in this case, is
CCITT Rec. I.327.

Supposedly, the broadband versions of an NT1, NT2, and S and T reference
points is about the same as for "narrowband ISDN."

A broadband NT1 (B-NT1) is the functional device responsible for the
termination of the transmission facility.  In all likelihood, this function
will actually occur in a PBX or other on-premises switch.

The broadband switch, e.g. B-ISPBX, is a B-NT2.

The broadband S ref. point (S with a "B" subscript) is the same as in
narrowband ISDN; i.e., between B-TE and the B-NT2.

The T <sub B> ref. point is between B-NT2 and the public B-ISDN.  Note that
there isn't much talk of a U reference point.  1st, the CCITT views the
transmission facility as owned by the network, anyway, and doesn't
standardize that stuff.  2nd, as in the PRI, the B-ISDN access for "U" and
T will be the same.

I hope this helps.

Gary C. Kessler
MAN Technology Corp.
+1 802-879-3375
kumquat@smcvax.bitnet