HDTenEightyP/NetNews huggingface dataset:
From: myoung@NEBULA.SSD.LMSC.LOCKHEED.COM
Subject: Re: Application Specific Switching Processors
Reply-To: myoung@NEBULA.SSD.LMSC.LOCKHEED.COM
Organization: LMSC, Sunnyvale, California
Distribution: usa
Date: Mon, 11 Jan 93 17:00:56 GMT

In article <1993Jan11.061952.28086@unet.net.com>, earlf@trappist.net.com (Earl Ferguson Adv Dev) writes:
>
>The notion of "smart" here is more application oriented than that
>normally associated with the term "smart hub". The intelligence is
>highly application specific, allowing an efficient implementation of a
>highly specialized network for, say, data base searches. Only the
>switches at the data base nodes need to have the ASSP processors;


1) Distributed Updates from asynchronous sources requires they
undergo arbitration at some point on the net.  If the arbitration
takes place on the network nodes, then significant reduction in update
time can be achieved.

2) Topology knowledge about the net helps in planning a query.
Whether one does a selection before a join depends upon whether
the join takes place over T3 lines while the selections take place
over disparate sales offices connected via slower T1 lines.  Hence, 
the application needs to obtain accurate, timely topology information
which requires some discovery process over the network nodes.

3) A server would like to have location information concerning a
set of clients, and possibly ring the clients in an out of band hamiltonian
circuit for flow control.

4) Arbitrary data searches are faster when done with a general exploration
of the physical network, requiring splitting of the message at various
nodes.  Application specific spanning trees which cover a closed
universe of storage units allows discovery of data items having flat
addresses which may be located anywhere in the closed universe.

5) Most of the sophisticated diagnostic and sniffer functions required
in the new networks require flexible access to the intermediate nodes.

Technically one might develop a sharp separation between network management 
and applications but market efficiency requires that the physical resources 
be turned over to the application via some flexible messaging layer. 

Remember Microsoft's stated intent: To put the entire enterprise data
structure under the semantic model (Info World), and this will include 
network objects.
Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Re: Application Specific Switching Processors
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Distribution: usa
Date: Tue, 12 Jan 93 17:18:14 GMT

In article <1993Jan12.012712.13581@berlioz.nsc.com>, lui@kitaro.nsc.com (Michael Lui) writes:

>Sorry for my ignorance because I'm still a beginner in this switching technology.
>I still have some questions. For instance, I like to connect an end station to a 
>data base server. 


We do not want to confuse.

There are two models: 

First Model:

The traditional in which the switched network is a cloud, connecting 
two endpoints via a virtual path in which no processing takes place.  This 
is the model for connecting a terminal with a data base server.

Second Model:

The proposed, but not yet accepted model, which says that the data base server
is a messaging layer and the data is scattered widely across the network.
In this model, a complex query needs to traverse multiple VCI, and the
construction of the query pattern is optimized over multiple VCI, and the
searching of data may require parallel propagation across multiple links.

The first model is currently sold by these wonderful switch vendors, and works
just fine for your problem.

The second model awaits a critical mass of developers who understand its
operation.
Newsgroups: comp.dcom.cell-relay
From: bharath@iti.gov.sg (Bharath Narayanan (CCL))
Subject: Re: Info On XTP
Organization: Indiana University
Date: Tue, 12 Jan 1993 01:03:31 GMT
X-Mailer: ELM [version 2.3 PL11]

Hi,
I am Bharath from ITI - C&C lab. I have some info on eXpress Transfer Protocol.
Please let me know if you are intersted.
I am seated at I-floor.
Bharath

Newsgroups: comp.dcom.cell-relay
From: kyma@shell.portal.com (Matt J Young)
Subject: Certification Program
Summary: A Very Bad Idea
Organization: Portal Communications Company
Date: Tue, 12 Jan 1993 02:00:38 GMT


Network Certification

Network General has launched a program to certify network engineers via
a certification test based upon existing network technology (Comm Week).
The engineers would be certified from tests based upon products from
existing vendors.

I cannot think of a more insidious program designed to stifle
innovation.  The idea stinks of an effort to codify existing network
architectures, preventing a more advanced form of distributed processing 
to emerge.  HP is doing itself a dis-service by joining the program.

I have seen a lot of maneuvers in Silicon Valley, designed to protect
technology, and all of these have led to a steady outflow of innovation
from Silicon Valley to points elsewhere.  In all cases the CEOs of the
local companies engage in high-jinks designed not to create new
multi-vendor solutions for the customer, but to protect older
technology or control the development of new.  This certification
program falls into the later group.

Newsgroups: comp.dcom.cell-relay
From: walvdrk@research.ptt.nl (Kees van der Wal +31 70 332 6295)
Subject: Re: ATM Test Tools and Prototype Adaptors
Organization: PTT Research, The Netherlands
Date: Tue, 12 Jan 1993 16:00:26 GMT

In article <19930108.121623.809@almaden.ibm.com>, sulzen@vnet.ibm.com (Bill
Sulzen) writes: 

> I am interested in obtaining information on all ATM test tools.
> To date, I am only aware of the HP tool.  Does anyone else make such a
> tool?

Alcatel STG is offering the Alcatel 8643 ATM Traffic Generator and Analyzer 
(ATGA). It's a PC plug-in card (ISA bus) plus software. It transmits and 
receives cells (pure ATM) at 155.52Mbit/s. 

I received some information from:

Richard Brander 
and
Paolo Di Casola
Alcatel STR AG
Friesenbergstrasse 75
8055 Zurich  Switserland

phone: +41 1 465 3274/2111
fax: +41 1 465 3191/2411
X.400: S=postmaster; P=Alcatel; A=arCom; C=CH
Newsgroups: comp.dcom.cell-relay
From: ag@fokus.gmd.de (A. Gavras)
Subject: Re: TAXI
Organization: GMD-Fokus (Berlin)
Date: Thu, 7 Jan 1993 09:13:16 GMT

In article <1993Jan6.105126.28378@iti.gov.sg>, sree@iti.gov.sg (Sreedharan Bhaskaran) writes:
|> Could anyone please tell me what TAXI is all about and how  I may access articles
|> or info. regarding it ?

TAXI stands for Transparent Asynchronous Transmitter/receiver Interface and is
a TM of Advanced Micro Devices (AMD).
It is a chipset Am7968/Am7969 that provides a means to establish a high speed
serial link between two 8 bit wide parallel busses.
The TAXIchip set consists of a transmitter Am7968 which takes parallel data
and transmits it serially at up to 125 MHz or 175 MHz and a receiver Am7969
which converts the serial data stream back to parallel form. 
The chipset uses 4B/5B coding and was designed for use in FDDI networks.
For more information contacts you nearest AMD Sales Office.

In a (local) ATM network you can use the TAXI chipset to implement an
inexpensive serial link for the transport of ATM cells.

-- 
_____________________________________________________________________________
Anastassios Gavras, GMD-FOKUS, Hardenbergplatz 2, 1000 Berlin 12, Germany
Tel:+49 30 25499263 FAX:+49 30 25499202 e-mail:gavras@fokus.berlin.gmd.dbp.de
_____________________________________________________________________________
From: kerch@reynaldo.parc.xerox.com (Berry Kercheval)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Info On XTP
Date: 11 Jan 93 23:03:11 GMT
	<1993Jan11.134325.16258@cbfsb.cb.att.com>
Reply-To: kerch@parc.xerox.com
Distribution: usa
Organization: Xerox PARC, Palo Alto, CA

>>>>> On 11 Jan 93 13:43:25 GMT, rajeev@cbnewsf.cb.att.com (rajeev.dolas) said:
rajeev> 	I am remember from the XTP book that info was available from
rajeev> 	PEI itself as the protocol is "open". If my memnory serves me
rajeev> 	right then send mail to xtp-request@pei.com. I am not sure what
rajeev> 	is required in the header or the message. 


Yes, except that PEI has ceased operations and pei.com no longer
exists.  I believe that the xtp list has been taken over by someone at
the University of Virginia, but I am not sure exactly who (or even if
I have the place right).  

A postscript copy of the version 3.6 XTP spec can be had by anonymous
ftp from sgi.com.  It's in other/xtp and called "xtp3.6.ps.Z".

  --berry (formerly berry@pei.com)


  
--
Berry Kercheval :: kerch@parc.xerox.com 
Newsgroups: comp.dcom.cell-relay
From: rajeev@cbnewsf.cb.att.com (rajeev.dolas)
Subject: Re: Info On XTP
Organization: AT&T
Distribution: usa
Date: Mon, 11 Jan 1993 13:43:25 GMT

In article <1993Jan11.072325.20952@iti.gov.sg> sree@iti.gov.sg writes:
>
>Hello everyone,
>
>	Thank you for your responses to my query on TAXI.
>
>	Please may I know where (sites) I may obtain a copy of XTP form ?
>
>	Thank you in advance.
>
>	sree
>

	I am remember from the XTP book that info was available from
	PEI itself as the protocol is "open". If my memnory serves me
	right then send mail to xtp-request@pei.com. I am not sure what
	is required in the header or the message. 

	Hope this helps.


	Raj Dolas
	AT&T Bell Labs
	raj@qsun.att.com

Newsgroups: comp.dcom.cell-relay
From: bharath@iti.gov.sg (Bharath Narayanan (CCL))
Subject: Re: RESULT: comp.dcom.sys.wellfleet pass 122:14
Organization: Indiana University
Date: Sat, 9 Jan 1993 01:12:24 GMT
X-Mailer: ELM [version 2.3 PL11]

I think I missed out the earlier postings about this ...wellfleet ?
Could anyone post some details ?
Thanks,
Bharath.
bharath@iti.gov.sg

Newsgroups: comp.dcom.cell-relay
From: jeffc@ee.ubc.ca (Jeffrey Chow)
Subject: Re: Saturn Consortium?
Organization: Indiana University
Date: Tue, 5 Jan 1993 21:31:08 GMT
X-Mailer: ELM [version 2.3 PL8]


> 
> Hi,
> 
> I recently read that a consortium named Saturn is working on an ATM
> chipset for
> STS-3 and STS-12. It is supposedly being lead by PMC-Sierra. I am
> interested in
> finding out about this chipset. Does anyone have a phone number or address
> for
> PMC-Sierra or any member of the consortium?  Thanks.

  PMC-Sierra, Inc.
  8999 Nelson Way
  Burnaby, BC
  Canada V5A 4B5
  604-293-5755 
  604-293-6012 FAX
Newsgroups: comp.dcom.cell-relay
From: sree@iti.gov.sg (Sreedharan Bhaskaran)
Subject: Newbie Questions on AAL5
Reply-To: sree@iti.gov.sg
Organization: Information Technology Institute, National Computer Board, S'pore
Date: Mon, 11 Jan 1993 07:35:17 GMT

Hi everyone,

	I will greatly appreciate any answers to the following questions :

	1. When an AAL-user send an AAL-U-ABORT.request, is the AAL connection
	   released, can the user still send data on that connection ?

	2. In message mode, when the CPCS receives a corrupted CPCS-PDU, it
	   discards the reassembly buffer. Does it also raise a signal to the 
	   SSCS layer ? Is the AAL connection still valid ?

	3. In the case of expiry of the SAR timer, is the connection released ?


	4. Does anyone know what primitives have been defined for the AAL 
	   connection establishment/release and what parameters are used ?


	Thank you all in advance.

	sree
From: sulzen@vnet.ibm.com (Bill Sulzen)
Date: Fri, 8 Jan 93 14:55:09 EST
Newsgroups: comp.dcom.cell-relay
Subject: ATM Test Tools and Prototype Adaptors

I am interested in obtaining information on all ATM test tools.
To date, I am only aware of the HP tool.  Does anyone else make such a
tool?

Also, I am interested in prototype adaptors that showcase a vendors ATM
chipset.  From a previous append to this forum, I am led to believe that
at least 4 companies are working on ATM (chipsets?):

   Fore
   Adaptive
   Huges LAN Systems
   MPR Technologies

Do these companies sell prototype adaptors?  Also, does anyone have contact
information for the above companies?
Newsgroups: comp.dcom.cell-relay
From: earlf@trappist.net.com (Earl Ferguson Adv Dev)
Subject: Application Specific Switching Processors
Keywords: atm, frame relay, switches
Organization: Network Equipment Technologies
Distribution: usa
Date: Thu, 7 Jan 1993 09:12:32 GMT

I believe that it could be appropriate for switches (ATM or Frame Relay)
to be developed that contain both a high performance general purpose
switch and one or more applications specific switching processors
(ASSP). The Class of Service negotiated at VC setup could then include
a request that any switch with the identified ASSP available, switch
cells or frames for the VC to their attached ASSP before forwarding. If
done carefully, this should give the ability to enhance the processing
capability of a switch with the ASSPs needed for data base query,
transaction updates, tree structured searches, etc.

I am no expert in this arena, but it just makes more sense to me to
remove the specifics of an individual application's networking and
distributed processing needs from direct responsibility of the switch or
other general networking layers. On the other hand, it is also desirable
to make this type of distributed application efficient by providing a
means of implementing specific applications functions "close" to the
switching function.

---
Earl Ferguson
earlf@net.com
My personal opinions and NOT those of my employer.
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Info On XTP
Date: 12 Jan 93 07:09:58 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

kerch@parc.xerox.com writes:
+---------------
| rajeev> 	...send mail to xtp-request@pei.com.
| 
| Yes, except that PEI has ceased operations and pei.com no longer exists.
+---------------

Before PEI folded, Larry Green, one of the founders of PEI, spun off two new
companies to deal with XTP by itself.

One is called "The XTP Forum, Inc.", and is a non-profit organization for the
continued evolution of the XTP protocol, possible standardization activities,
etc. This includes the continuation of the XTP TAB (Technical Advisory Board)
and XTP RA (Research Affiliates) activities, more or less unchanged from the
way they were under PEI.

The other company is "XTP Systems, Inc.", which is a for-profit firm engaged
in continued development/licensing of the XTP KRM (Kernel Reference Model)
implementation of XTP (originally developed by PEI & SGI), as well as other
commercial XTP-related activities, I suspect.

Both may be reached at the following address (which may be familiar to some
as the former address of the Santa Barbara office of PEI):

        Larry Green  
        XTP Forum, Inc.            (or XTP Systems, Inc.)
        1900-D State Street
        Santa Barbara, CA  93101

        Phone: (805)965-0825
        FAX:   (805)687-2984

(Currently their e-mail is non-functional, but a couple of us are trying
to help get them re-connected...)


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043
From: craig@sics.se (Craig Partridge)
Newsgroups: comp.dcom.cell-relay
Subject: two more questions re: SONET and ATM
Date: 4 Jan 93 17:32:29 GMT
Organization: Swedish Institute of Computer Science, Kista

Thanks to all the folks who replied to my previous inquiry.  I've got what
I hope are my two final questions on this topic.

First, one of the books I'm reading (Sexton and Reid, Transmission Networking) 
notes that one could load the sync sequence (bytes A1 and A2) into the payload
of an ATM cell and screw up the SONET multiplexors.  They note that as a result
the data in the ATM cells have to be scrambled.  But it wasn't clear to me
that the scrambler would always provide protection.  Is the scrambler
guaranteed not to generate the two byte sequence 0xF6 0x28, or is some
fancy bitstuffing done too?  What about for digital voice -- how is it
protected against sending a sync sequence?

Second, I'm getting conflicting information about how ATM cells get packed.
My understanding is that originally cells were packed into VC-4 payloads,
with bytes and octet boundaries in sync, but possibly offset within the
VC-4 payload (i.e. the H4 pointer may be non-zero).   Furthermore, in the
worst case, a cell could span two VC-4 payloads (end of one and start of
the next).  But more recently I'd been told that the rules have been
changed so that the ATM cells always start in the first byte of the VC-4
payload and there's no splitting cells across VC-4 payloads.  Has this
change indeed taken place?  [As a related side question, so far as I can
tell, SONET uses VC-4 packing for cells, just like SDH -- is that correct?]

Thanks!  

Craig Partridge
Newsgroups: comp.dcom.cell-relay
From: joydeep@iti.gov.sg (Joydeep Bose)
Subject: Want to buy a ATM Development System
Organization: Information Technology Institute, National Computer Board, Singapore.
Distribution: usa
Date: Wed, 6 Jan 1993 05:19:42 GMT



We have decided to buy an ATM development system. What we have not decided is
the vendor from which we should. Our requirement is to do some value added
research work on the system and therefore would wish to have some access to
the underlying hardware and firmware. 
If any gentleman has done some survey on this and would like to share with us
his valuable experiences, we look forward to hear from him soon.

BTW, we have shortlisted some of the vendors::::

1. Fore
2. Adaptive.
3. Huges LAN systems
4. MPR Technologies.

Disclaimer: Not necessarily in that order and this list is not final.


Joydeep


Newsgroups: comp.dcom.cell-relay
From: myoung@NEBULA.SSD.LMSC.LOCKHEED.COM
Subject: Re: Application Specific Switching Processors
Reply-To: myoung@NEBULA.SSD.LMSC.LOCKHEED.COM
Organization: LMSC, Sunnyvale, California
Distribution: usa
Date: Thu, 7 Jan 93 23:04:26 GMT

>I believe that it could be appropriate for switches (ATM or Frame Relay)
>to be developed that contain both a high performance general purpose
>switch (processor) and one or more applications specific processors...

  Or just share the processor, especially the if the processor can 
read/write the tables...
From: keleher@cs.tulane.edu (William Keleher)
Newsgroups: comp.dcom.cell-relay
Subject: CCITT ATM recs available electronically?
Date: 12 Jan 93 17:34:25 GMT
Distribution: comp
Organization: Computer Science Dept., Tulane Univ., New Orleans, LA
Nntp-Posting-Host-[nntpd-18865]: venus


  I've been having a wicked time trying to get timely access to CCITT ATM
reccomendations.  Is there a site where these are available electronically,
or am I kidding myself to think that there might be?
								     -Wm.
From: jh@etana.funet.fi (Juha Heinanen)
Newsgroups: comp.dcom.cell-relay
Subject: Q.93B available
Date: 9 Jan 93 15:07:02 GMT
Distribution: comp
Organization: Finnish University and Research Network

Falk Sass from Siemens made kindly available a Postscript version of
Q.93B.  This is not an offcial version, but useful anyway, especially
since the official one is not (yet) available electronically.  Please
read file q93bcover.ps.Z to find out the exact status.  

The Q.93B files are available for ftp at datanet.tele.fi:atm/q93b
directory.
--
--	Juha Heinanen, FUNET, Finland, jh@funet.fi, +358 49 500958
-- 
Newsgroups: comp.dcom.cell-relay
From: Holland_Thomas@Tandem.Com (Tom Holland)
Subject: Saturn Consortium?
Followup-To: comp.dcom.cell-relay
Organization: Tandem Computers
Date: Tue, 5 Jan 1993 17:50:09 GMT

Hi,

 I recently read that a consortium named Saturn is working on an ATM
chipset for
 STS-3 and STS-12. It is supposedly being lead by PMC-Sierra. I am
interested in 
 finding out about this chipset. Does anyone have a phone number or address
for 
 PMC-Sierra or any member of the consortium?  Thanks.

Tom Holland

Holland_Thomas@Tandem.Com,    
Tandem Computers, Cupertino Ca 
                              
Newsgroups: comp.dcom.cell-relay
From: sree@iti.gov.sg (Sreedharan Bhaskaran)
Subject: Info On XTP
Reply-To: sree@iti.gov.sg
Organization: Information Technology Institute, National Computer Board, S'pore
Date: Mon, 11 Jan 1993 07:23:25 GMT


Hello everyone,

	Thank you for your responses to my query on TAXI.

	Please may I know where (sites) I may obtain a copy of XTP form ?

	Thank you in advance.

	sree

Newsgroups: comp.dcom.cell-relay
From: lcs@iti.gov.sg (Liew Choon Siong)
Subject: info on Q.93B
Keywords: Q.93B
Reply-To: lcs@iti.gov.sg
Organization: Information Technology Institute, National Computer Board, S'pore
Date: Tue, 5 Jan 1993 09:15:35 GMT

We would like to obtain a copy of the above std. Could anyone pls
tell us where(site) we can access this std?

Thank You.

Liew Choon Siong
email: lcs@iti.gov.sg
From: jstone@netcom.com (Jeffrey Stone)
Newsgroups: comp.dcom.cell-relay
Subject: ATM workstation adapter card source(s)?
Date: 4 Jan 93 16:26:38 GMT
Organization: Netcom - Online Communication Services (408 241-9760 guest)

We are looking for a source for ATM adapter workstation cards.

We hope to find a source for EISA bus compatible ATM adapter cards
where prototypes will be available soon.

Please contact me with information, leads, etc..

NDA conditions acceptable.

Jeff Stone
info/mation
voice 415.324.0443
fax: 415.324.8462
email: jstone@netcom.com



-- 

Jeffrey Stone		jstone@netcom.com		415.324.0443
From: dm@cl.cam.ac.uk (Derek McAuley)
Newsgroups: comp.dcom.cell-relay
Subject: Re: two more questions re: SONET and ATM
Date: 5 Jan 93 11:57:59 GMT
Organization: U of Cambridge Computer Lab, UK

> one could load the sync sequence (bytes A1 and A2) into the payload
> of an ATM cell and screw up the SONET multiplexors.

My understanding is that there are two scramblers, one at the SONET frame level
and another for cell payloads. The frame scrambler is applied to the payload - I
believe is is applied after the line overhead (which includes the sync sequence)
but is reset to s defined state each frame - hence repeated idenitical payloads
generate the same bits on the wire and so it is easy to arrange a repeated sync
pattern in the payload. Note that so far this is nothing to do with ATM and is
required even if  SONET is used to carry a VC4 holding 2340 telephone calls.

For ATM within a VC4, the H4 pointer is now no longer used; this is beacuse
lower rate virtual containers do not have it and a generic solution is desired. 
(I guess the obvious one of aligning cells within each VC frame is considered to
be a gross waste of space -- a VC4 has 2340 bytes hence 44 cells and 8 bytes.)
So it is now suggested that cell alignment within the container is done by
hunting for correct 5 octet headers within the SONET payload (after SONET frame
descrambling) -- i.e. 4 bytes followed by correct HEC -- hence it is necessary
to further scramble the cell payloads to stop (that is decrease to small
probability) someone inserting a chain of 5 octet sequences that look like cell
headers into cell payloads. In this case I believe the scrmabler is not reset
per cell and hence repeated payloads do not generate the same pattern.

Note that in both hunt modes, any sensible implementation should require a
significant number of correct sync / HEC occurances *at the correct frequency*
before declaring lock and then should not be thrown by a correct sync/HEC
patterns that appear at random.

A malicous person could easily defeat the SONET scrambler, the ATM level takes
more work -- if one knew the state of the scrambler, one can clearly define a
payload to defeat it. However, the trick is to find a pattern that can defeat
the SONET scrambler but is also a legal VC4 containing legal ATM cells for legal
VCI/VPI pairs so that you might have a defence when the carrier tries to sue you
for screwing their network |-)

Mac.
Newsgroups: comp.dcom.cell-relay