HDTenEightyP/NetNews huggingface dataset:
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Cross Posting
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Thu, 7 Jan 93 18:32:49 GMT

I read the latest trade magazines on the subject of new distributed
processing technology and ATM.  They are close, but haven't quite gotten
it as far as it should be.

The current client server applications work just fine with the current
networking systems.  The issue here is replacing the client server model
with the semantic data model, and whether the replacement can be
accomplished without some virtual path network technology.

Example:

  Consider putting the entire corporate literature database under the
semantic model with schema such as:

   Reports have text, abstracts, key words, authors, they reference other
reports, and are attached to product development teams.

   Authors have resumes, and have worked on other product development teams,
and have written other reports.

  Given this schema, it can be construed as a network connection of data,
and queries are construed as traversals and extractions from the data.
For example: Which reports reference other reports which use a specified
key word.

  Data can be entered into the corporate semantic model regardless of its 
location, classes can be indexed across the corporate semantic model, and
class instances can be discovered by some exploration of the corporate
network.

  When the semantic model has certain properties, like: Single valued
traversals, existence of property values, and type consistency
along traversal; then a set of equivalence and inference axioms result,
and these axioms allow the definition of a traversal protocol of which
Wave is the most obvious example.

  The axioms define associative, transitive properties of paths, and
their related traversal programs.  Included is a kind of distributive
property which allows multi-variate recursive queries. The distributive
axiom requires two operations, the path splitting, and node hopping
functions.

  This is a different model then the client server model, and it requires all
the flexibility of a programmable messaging layer, it needs the self routing
capability of an application specific network layer.

  The semantic theory, as far as is published, seems to be rapidly closing
on an access strategy language which has a syntax almost totally defined
by theory, hence differences in implementations will be minimal.

  In order to short circuit the understanding process, I will try to
cross post some ideas in both the comp.database.theory and comp.dcom.cell-relay.
We want the data base theoreticians to include virtual path networks into
their model.  Hopefully they will begin to see that a traditional router
or bridge, is simply an index on some class; that a shortest path is simply
a semantic reduction.  Then they can begin to think about the network 
management issue in terms of semantic theory; and conversely, think about
the virtual path networks as a connectionist machine.
Newsgroups: comp.dcom.cell-relay
From: earlf@trappist.net.com (Earl Ferguson Adv Dev)
Subject: Re: Application Specific Switching Processors
Keywords: atm, frame relay, switches
Organization: Network Equipment Technologies
Distribution: usa
Date: Mon, 11 Jan 1993 06:19:52 GMT

In article <1993Jan7.193136.28931@berlioz.nsc.com> lui@kitaro.nsc.com (Michael Lui) writes:
>>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 structure searches, etc.
>
>Do you mean of building a smart switch which is analogous to a smart hub?  

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; all
other switches would treat the cells normally; however, when a cell for
the VC(s) being used for the search reach one of the data base node
switches, it will be processed by the data base specific switching
processor, passibly locating part or all of the data, or redirecting
the search based on data base structure information.
---
Earl Ferguson
earlf@net.com
My personal opinions and NOT those of my employer.
Newsgroups: comp.dcom.cell-relay
From: hellstro@tnclus.tele.nokia.fi
Subject: Re: two more questions re: SDH and ATM
Organization: Nokia Telecommunications.
Date: Tue, 5 Jan 1993 09:46:27 GMT

craig@sics.se (Craig Partridge) writes:

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

No bitstuffing will be done. The ATM cell payload scrambling is supposed to
protect ONLY the ATM cell header against mimic patterns appearing in the
cell payload. In addition to previous the entire STM-1 (STS-3) frame
(excluding the synch sequence) containing the scrambled ATM cells will be
scrambled again according another polynomial. So it's not worth trying
to mess up the SDH/SONET equipment with ATM cells.      

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

This is precisely how it will be done.

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

Take a look at this: The payload size reserved for ATM cells in VC-4
will be 2340 bytes, which isn't any integer multiplied by 53. Thus,
it doesn't matter wrether the cell starts in the first byte or not,
the cells will always cross the VC-4 boundary. The cell delineation
will be done by the means of HEC (CCITT Rec. I.432).

Jan
Newsgroups: comp.dcom.cell-relay
From: ag@fokus.gmd.de (A. Gavras)
Subject: Re: TAXI
Originator: ag@icarus
Organization: GMD-Fokus
Date: Thu, 7 Jan 1993 08:40:57 GMT

Newsgroups: comp.dcom.cell-relay
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: TAXI
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 8 Jan 1993 08:21:24 GMT

ag@fokus.gmd.de (A. Gavras) writes:
+---------------
| sree@iti.gov.sg (Sreedharan Bhaskaran) writes:
| |> Could anyone please tell me what TAXI is all about...
| 
| 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.
+---------------

Well, not really "busses", in the sense of computer I/O busses, but just
8-bit (or 10-bit on some versions) data paths -- a "byte pipe". It is easier
to think of TAXIs as just really, really fast UARTs (or USRTs, actually).

+---------------
| The chipset uses 4B/5B coding and was designed for use in FDDI networks.
+---------------

Well, it was actually designed slightly before FDDI was standardized, so
while it uses the same encoding for data an non-data symbols, it uses the
non-data symbols in slightly different ways by default. For example, TAXIs
use the "JK" symbol pair as the idle-line fill pattern, instead of FDDI's
"I" symbol. And it has none of the FDDI PHY symbol-filtering or elasticity-
buffer management logic.

However, since you can send the "I" symbol (and other non-datas) explicitly,
and since you can keep "JK"s from being sent by keeping the transmitter busy,
it is just barely possible to implement an FDDI PHY with a concoction of TAXIs,
FIFOs, and PALs. (Barely. But certainly not easy.)

Still, if you're not trying to be FDDI-compatible, TAXIs are a cheap and
very simple way to create a high-speed point-to-point serial link, up to
their speed limit -- which at my last information was about 275 Mb/s.
They take care of byte syncronization for you, and provide a limited way
to send "out-of-band" data (the 4B/5B "non-data" symbols) over the same
channel. For example, one might insert "R" or "S" symbols every so often
in the data stream to perform an "XOFF/XON" flow-control function for the
reverse direction. Or use "JK" and/or "T" to mark packet boundaries. Etc.

There are also competing serializers from other companies, which go up
to speeds as high as a gigabit/sec or more (e.g., the Tri-Quint [formerly
Gazelle] 32-bit "HOTROD"). But as long as you stay within their speed
range, TAXIs are about the cheapest thing there is...

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

In particular, the most recent TAXI parts can support the "Fibre Channel"
8B/10B coding (and escape codes), and thus should be usable with the Block-
Coded TC Sub-Layer option of the "Network Compatible Local Area ATM" proposed
spec. [Of course, there are several other vendors who also have Fibre Channel
compatible serializers: AMCC, IBM, H-P, others...]


-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
From: cktoh@iti.gov.sg (Toh Chai Keong (CCL))
Subject: Developing Video Applications over B-ISDN(ATM)
Organization: National Computer Board, Singapore
Date: Tue, 12 Jan 1993 11:00:28 GMT

I am currently embarking a B-ISDN project based on Video
Multicast using ATM.

I hope that anybody that have done some research work or
have developed video applications based on ATM could provide
me information on their findings, work, etc..

Also, besides the CCITT Integrated Video Services Baseline
Document, are there others pending video over ATM standards
to come by?

Glad to hear advices from members of this group.

Thanks,
Chai-Keong
(Singapore)
---------------------------------------------------------

-- 
------------------------------------------------------------
Chai-Keong,Toh,
Associate Member of Technical Staff,
Computer & Communications Laboratory,
Newsgroups: comp.dcom.cell-relay
From: lui@kitaro.nsc.com (Michael Lui)
Subject: Re: Application Specific Switching Processors
Keywords: atm, frame relay, switches
Organization: National Semiconductor Corporation
Distribution: usa
Date: Thu, 7 Jan 1993 19:31:36 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 structure searches, etc.

Do you mean of building a smart switch which is analogous to a smart hub?  

Newsgroups: comp.dcom.cell-relay
From: giese@k9.dev.cdx.mot.com (Bruce Giese)
Subject: Re: Want to buy a ATM Development System
Organization: Motorola Codex, Canton, Massachusetts
Distribution: usa
Date: Mon, 11 Jan 1993 18:13:19 GMT

joydeep@iti.gov.sg (Joydeep Bose) writes:



>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


Take a look at the Dec. 14, 1992 issue of Communications Week.
Page 67 lists a large number of vendors who admit to working
on ATM products.  The article includes details such as type of
product, bandwidth, availability, and price.

Those listed are: Adaptive, ADC Fibermux, BBN, DEC, DSC, Fore,
Frame Relay Tech., Fujitsu, Gandalf, InteCom, NEC, Newbridge,
Premisys Comm., Siemens Stromberg-Carlson, Telematics Int.,
TRW Elect. Syst. Group, Ungermann-Bass, and Wellfleet.  The
others apparently wouldn't admit enough info about their systems
to be included in the list.

				Bruce Giese
Newsgroups: comp.dcom.sys.cisco
From: "Brian Smith" <bsmith@nms001.ateng.az.honeywell.com>
Subject: Re: DECnet areas
Return-Path: <bsmith@nms001.ateng.az.honeywell.com>
Date: 8 Jan 93 10:01:34 MST
X-Note1: message-id generated by recnews
X-Note2: mail msgid was   <9301081701.AA01640@nms001.ateng.az.honeywell.com>


> From cisco-forw@spot.colorado.edu Thu Jan  7 09:28:57 1993
> Date: Thu, 7 Jan 93 07:48:14 -0800
> From: Nicholas Thille <thille@cisco.com>
> To: smiles@nmc.ed.ray.com
> Cc: cisco@spot.colorado.edu
> Subject: DECnet areas
> Content-Length: 1523
> 
> 
> >> We have an AGS+ at each of three of our facilities.  Each AGS+ has about
> >> eight to ten Ethernet interfaces.  Each facility is a different DECnet area,
> >> and the AGS+ at the facility is the DECnet area router.
> >> 
> >> At one of our facilities, we are running out of DECnet addresses.  We have
> >> already allocated 750 of 1000 addresses, and at the rate we're using them
> >> we'll have used them all by this June.  We will be forced to move to a
> >> second DECnet area before the 1993 is out.
> >> 
> >> The only way I know to implement this second DECnet area is by using a
> >> separate piece of equipment -- basically, a second AGS+.  We'd really rather
> >> not do this.
> >> 
> >> Can the existing AGS+ do anything regarding this second area?  Can it act as
> >> area router for two different areas?  Are these in the plans for future
> >> Cisco releases?
> >> -- 
> >> Kevin.Ruddy@NMC.ED.RAY.COM
> >> 
> 
> Cisco routers have offered level 1 and level 2 (area) DECnet routers for
> some time.  I don't know when the support was initial done, but it has been
> there since release 8.2.
> 
> The below configuration commands are described in chapter 12 in the Release
> 9.0 and Release 9.1 router manuals.  I suspect the commands are the same in
> earlier releases, but check the DECnet chapter just to be sure.
> 
> To configure the cisco router as a level 1 router use the command:
> 
> 	decnet node routing-iv
> 
> To configure the cisco router as a level 2 (area) router, use the command:
> 
> 	decnet node area
> 
> Regards,
> 
> Nick Thille
> Engineering 
> cisco Systems, Inc
> 
Nick,
I think you missed Thille's question.  He needs multiple level 2 (area routers), unless he makes use of an area at another site which would not be wise becuase of performance and reliability.  

Thille,  we have the same problem and now have 3 decnet area's used by us (Honeywell ATSD eng.) and a fourth used by other groups in the plant.  We have seperate AGS+s acting as the area routers.  If you have a small number of nodes in a second area, you might get by with using an IGS+ or even a VAX as the area router. There are some nasty's to watch out for such as packets being bounced between  the highest priority routers.  If you're interested in more, let me know.

				Brian Smith
				Staff Eng.
				Honeywell CFSG, ATSD Eng.
				(602)436-6691
From: jack@umbc3.umbc.edu (Jack Suess)
Newsgroups: comp.dcom.sys.cisco
Subject: cisco arp cache becoming corrupted
Date: 11 Jan 1993 12:45:53 -0500
Organization: University of Maryland, Baltimore County Campus
Distribution: na
NNTP-Posting-Host: umbc7.umbc.edu

We have a problem where the arp cache gets corrupted on a router
and the ethernet address does not correspond to the correct IP address.
When this has happened, it is usually the ethernet address of one of the
cisco ethernets providing the link to the other router. Our setup has
three routers, call them A, B, and C. Each router is connected via ethernet
to the other two. A picture showing the subnet assignments
would be the following:



                        |-----|
                        |_____| machine on subnet 100 that should be on 50
                           |
                           |
                           |
                           |
                   13.1    A   12,1
                          /  \ 
                         /    \
                        /      \
               13.2    /        \  12.2
                      B----------C
                      5.20     5.1


What happens is on router B, the arp cache for IP address 13.1 will somehow
get changed and show the ethernet address for 13.1 to be some device other
than the cisco. When this happened, I was able to track down a machine
whose IP address was configrued wrong. It was on a subnet attached to router
A, subnet 100, and configured as if it was on subnet 50. What surprised me was 
why that would hose the arp cache of router B. I could reproduce the 
problem by booting the machine and within a minute router B would update it's
arp cache showing IP address 13.1 being the machine I just booted. The machine
I booted did not have anything related to subnet 13 in it's configuration 
files. When this happens all traffic between routers A and B dies since router
B is directing it to the wrong interface. One thing I have done is create
a static arp entry but that really isn't the best way to handle this. Has
this been reported elsewhere and is there a fix for it?

Sincerely,
Jack suess
410-455-2582
jack@umbc3.umbc.edu



-- 
Jack Suess                           UMBC Academic Computing
Internet: Jack@umbc5.umbc.edu        Standard Disclaimer:
Bitnet: Jack@umbc                    The opinions expressed above are mine and
ATT: 301.455.2582                    not my employers.
Newsgroups: comp.dcom.sys.cisco
From: Gary Kunis <gkunis@cisco.com>
Subject: Life and the MAS-26
Date: 8 Jan 93 17:55:31 PST
X-Mailer: ELM [version 2.3 PL11]
X-Note1: message-id generated by recnews
X-Note2: mail msgid was   <199301090158.AA09727@spot.Colorado.EDU>

Hey Tom,

We have a separate power autoranging power supply because of
the strict BABT standards in Prince Charles realm.  The Brit-
ish are very strict about power supply homulogation.

Such is life.

  -- Gary --

Newsgroups: comp.dcom.sys.cisco
From: Peter Radig <peter@orfeo.rhein-main.de>
Subject: Re: How reliable are 9.1 sub-releases ?
Phone: +49 69 746972
Address: Palmengartenstr. 1, D-W6000 Frankfurt am Main 1, Germany
Organization: Peter Radig EDV-Beratung, Frankfurt am Main, Germany
Date: Sat, 9 Jan 1993 20:22:21 GMT
Fax: +49 69 7411443

In <C0G3J1.4sv@ecmwf.co.uk> syj@ecmwf.co.uk (Jean-Philippe Martin-Flatin) writes:

>How reliable are 9.1 sub-releases ? We are currently hesitating between
>the following to upgrade all our CISCOs:

>	9.0(3.x)
>	9.1(1.x)
>	9.1(2.1)

>Each of them fixes some bugs we suffer from. But the whole 9.1 release
>has had a bad reputation so far, and our distributor seems quite afraid
>to let us go beyond 9.0(3) ! Does anybody have some experience with these
>sub-releases ? Positive or negative ?

>The protocols we are interested in are IP, ARP, RARP, Decnet and Novell.

Novell fast switching of small pakets is broken in 9.1(1.?) (BugID 8547).
That makes Novell routing only usable if you put "no novell route-cache"
into your config.

This should be fixed in 9.1(2.x) but I didn't get my hands on it right now.

cu,
Peter
Newsgroups: comp.dcom.sys.cisco
From: Larry Bowden <lbowden@last-call.cisco.com>
Subject: Re: Bug reports, and this mailing list...
Date: 11 Jan 93 18:35:07 PST
X-Note1: message-id generated by recnews
X-Note2: mail msgid was   <CMM.0.90.2.726806107.lbowden@last-call.cisco.com>


> > 
> > Just a reminder that the cisco@spot.colorado.edu mailing list (and the
> > associated comp.dcom.sys.cisco Newsgroup) are user mailing lists that are
> > NOT directly associated with cisco.  While the recent <text deleted>
> > discussions are entirely appropriate, issues like
> > "my router crashed and gave me this stack trace" would probably elicit
> > better results if reported directly to cisco customer engineering, either
> > by email (to customer-service@cisco.com), by phone, or by CIO.
> > 
> > Bill Westfield
> > cisco Systems.
> > 
> Bill,
> 
> I'm sure this is true but the info is very helpful for us other users to know 
> about.  Maybe people could send the problem to Cisco AND here?
> 
> 			
> 			Brian Smith
> 			Honeywell CFSG
> 

The determining factors as to where to send something are whether or
not you want a guaranteed Cisco response, and, what is the intended
audience.  

If you want an answer from Cisco the only ways to get a guaranteed
response from Cisco is to call 800-553-2447 (24HR), or email sent
to tac@cisco.com.

If you want to discuss the issue with other Cisco-literate folks 
both inside and outside Cisco, post it to Cisco@spot.colorado.edu
or comp.dcom.sys.cisco.

If you want both a guaranteed Cisco response and discussion with 
other Cisco users, send it both places.


Larry Bowden					       
Cisco Systems					       TAC    1.800.553.2447
Customer Engineering				       fax:   1.415.903.8787
1525 O'Brien Drive				       Voice: 1.415.903.7567
Menlo Park, CA 94025				       email: lbowden@cisco.com




Newsgroups: comp.dcom.sys.cisco
From: Bob Albrightson <albright@lager.cisco.com>
Subject: Re: BootP question [detailed, longish]
Date: 7 Jan 93 8:09:08 PST
X-Note1: message-id generated by recnews
X-Note2: mail msgid was   <CMM.0.90.2.726422948.albright@lager.cisco.com>

I see at least one problem with this packet: (This is the bootp reply
from the bootp server)

> !	  Source IP Address:    132.241.200.10
> !	  Dest. IP Address:     132.241.16.1
> !	  ...
> !	  ...
> !	  Source Port:          67  Bootstrap Protocol Server
> !	  Destination Port:     67  Bootstrap Protocol Server
> !	  ...
> !	  ...
> !	  UDP Data Area:
> !	  PPPPPPI@PPPPPPPP   02 01 06 00 00 00 49 40 00 08 00 00 00 00 00 00
> !	  ^DPPP^DPHP^DPPPPPPP   84 f1 50 0b 84 f1 c8 0a 84 f1 10 01 02 07 01 08
				^^ ^^ ^^ ^^
The problem is the server is assigning a subnet 80 address to bob-pc
(132.241.80.11, actually).  This is why bob-pc is not receiving the
reply.  The router will send the packet to its subnet 80 interface.
Look at the arp cache for 132.241.80.11 on the router.  You will find
it points to 0207:0108:6be4.

Take a look at ther servers bootp config file.

 -bob
Newsgroups: comp.dcom.sys.cisco