HDTenEightyP/NetNews huggingface dataset:
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Lower Speeds
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Mon, 12 Oct 92 13:36:12 GMT

Lower Speed lines:

BT Tymnet is upgrading its network to include wider avability of
9.6 kbps access.  Since 9.6 kbps modem seems to remain the favored
access method, perhaps we sould consider the efficiency of cell relay
at this speed.  Is it out of the question?
Newsgroups: comp.dcom.cell-relay
From: brian@dxcern.cern.ch (Brian Carpenter   CERN-CN)
Subject: List of CCITT recommendations
Summary: List of CCITT recommendations concerning ATM
Keywords: CCITT ATM BISDN
Organization: CERN European Lab for Particle Physics
Date: Thu, 15 Oct 1992 13:26:57 GMT



List of CCITT recommendations concerning ATM
============================================

You have to buy these on paper from
  ITU
  Place des Nations
  CH-1211 Geneva 20
  Switzerland.
The fax number of the sales office is +41 22 730 5194.

Don't even think about finding them on line.

This list is posted only because I happen to have it on disk.
I have no responsibility in this area and I do not guarantee
its completeness, correctness or relevance.

  Brian Carpenter   CERN

E.164      Numbering plan for the ISDN era                   08/91

G.707      Synchronous digital hierarchy bit rates           04/91

G.708      Network node interface for the synchronous        04/91
	   digital hierarchy

G.709      Synchronous multiplexing structure                04/91

I.150      B-ISDN asynchronous transfer mode functional      04/91
	   characteristics

I.211      B-ISDN service aspects                            04/91

I.311      B-ISDN General Network aspects                    04/91

I.321      B-ISDN protocol reference model and its           04/91
	   application

I.327      B-ISDN functional architecture                    04/91

I.330      ISDN numbering and addressing principles          1988

I.331      Numbering plan for the ISDN era                   1988
	   >>> contains only a pointer to E.164 <<<

I.332      Numbering principles for interworking between     1988
	   ISDNs and dedicated networks with different
	   numbering plans

I.361      B-ISDN ATM layer specification                    04/91

I.362      B-ISDN ATM  adaptation layer (AAL) functional     04/91
	   description

I.363      B-ISDN ATM adaptation layer (AAL) specification   04/91

I.413      B-ISDN user-network interface                     04/91

I.432      B-ISDN user-network interface - Physical layer    04/91
	   specification

I.610      OAM principles of the B-ISDN access               04/91

Q.11 bis   Numbering plan for the ISDN era                   1988

Q.11 ter   Timetable for coordinated implementation of the   1988
	   full capability of the numbering plan for the
	   ISDN era (Recommendation E.164)

Q.931      ISDN user-network interface layer 3               1988
           specification for basic call control                 
-----------


Xref: sparky comp.dcom.cell-relay:593 comp.dcom.lans.fddi:728
From: slaski@netwrx1.NW1.COM (Robert Slaski)
Newsgroups: comp.dcom.cell-relay,comp.dcom.lans.fddi
Subject: ATM/FDDI cabling
Date: 16 Oct 92 14:10:20 GMT
Followup-To: poster
Organization: Open Networks, Inc., Reston, VA

I apologize if this is an FAQ.  I need guidelines on cable planning to
support FDDI today and ATM tommorrow.  My specific problem is a large 
campus e.g several kilometers.  FDDI is a ring topology.  ATM appears
best suited to a star (switch) topoloy.  I am planning to structure a
mesh topology the supports a ring but includes shorter paths to a future
central ATM switch.  I have reviewed a great deal of ATM material but
it deals with protocol and equipment not cable.  Any guidance? 

Thanks.

==============================================================================
  Robert Slaski			Usenet:	  uunet!netwrx1!slaski
  Open Networks			Internet: slaski%netwrx1@uunet.uu.net
  11490 Commerce Park Drive               slaski@netwrx1.nw1.com  
  Suite 205
  Reston, VA  22091      	Voice:    (703) 648-0013
Newsgroups: comp.dcom.cell-relay
From: brian@dxcern.cern.ch (Brian Carpenter   CERN-CN)
Subject: Re: (none)
Organization: CERN European Lab for Particle Physics
Date: Thu, 15 Oct 1992 14:03:42 GMT

In <1088@pico.qpsx.oz.au> dean@pico.qpsx.oz.au (Dean Economou) writes:

Dean,

>First, thanks to Tom Gray for mopping up the incorrect statements about
>ATM, SMDS, DQDB, and B-ISDN.

>I think what has happened is that through the activity of the ATM Forum,
>the generic technology acronym "ATM" has come to mean the particular ATM
>incarnation being formed in the ATM forum.  So perhaps the semantic
>errors of some of our posters can be explained by that.  My own summary
>of the relationship between ATM and all its implementations goes like this:


>1. ATM is a generic technology.

Well, yes, but this newsgroup was named cell-relay to avoid
confusion between generic ATM and CCITT ATM.

>2.  B-ISDN is CCITT's version of an ATM service definition, and it aims
>to avoid defining particular network implementations.

The CCITT has defined a lot more than a service definition.
See the stack of recommendations cited in my previous posting.
Once the NNI and Q.93B are defined, a switch maker will be at
liberty to use these between his own switches, or a proprietary
implementation. This is necessary and sufficient for a switched
network, in contrast to shared-medium networks such as LANs and DQDB.

>3. ATM is a generic technology, 802.6 DQDB is a particular network
>standard based on ATM technology.

Now I know you work for QPSX so you understand DQDB a lot better than
I do. But I don't see how you can say that a distributed queue dual
bus is "based on ATM technology" when the main motivation for the
invention of cell relay was the realisation that switching fabrics
can now be built cheaply with silicon. It would be no less accurate
to say that DQDB is "based on Cambridge ring technology". Both DQDB
and the latest Cambridge have aligned their slot size with CCITT
ATM cell size but a dual bus is not a ring is not a switch fabric.

>4. SMDS is a service definition based on DQDB, and therefore ATM
>technology.

>5. The ATM Forum is attempting to define a simplified ATM service
>definition which uses some aspects of CCITT work.  Its scope is
>restricted to promote early acceptance of ATM technology.

I think this is a very personal view of the ATM Forum.
My view is that the ATM Forum is attempting to define de facto
standards and practices in areas where the CCITT specs are lacking
(e.g. UNIs suitable for building wiring). If the ATM Forum starts
doing things which are incompatible with CCITT they will lose
my sympathy (and money). So far they are very well aligned with
CCITT. Somebody from the ATM Forum please comment.

>Perhaps we need to choose a better name for the ATM Forum to avoid the
>confusion its name has created.  Any suggestions?

What confusion? Anyway a chat group on Usenet can hardly tell
the ATM Forum to change its name.

Regards,
	Brian Carpenter CERN, brian@dxcern.cern.ch
			voice +41 22 767 4967, fax +41 22 767 7155
From: dean@pico.qpsx.oz.au (Dean Economou)
Newsgroups: comp.dcom.cell-relay
Subject: Re: (none)
Date: 15 Oct 92 09:42:20 GMT
Organization: QPSX Communications LTD, Perth, Western Australia.
X-Newsreader: Tin 1.1 PL4

First, thanks to Tom Gray for mopping up the incorrect statements about
ATM, SMDS, DQDB, and B-ISDN.

I think what has happened is that through the activity of the ATM Forum,
the generic technology acronym "ATM" has come to mean the particular ATM
incarnation being formed in the ATM forum.  So perhaps the semantic
errors of some of our posters can be explained by that.  My own summary
of the relationship between ATM and all its implementations goes like this:


1. ATM is a generic technology.

2.  B-ISDN is CCITT's version of an ATM service definition, and it aims
to avoid defining particular network implementations.

3. ATM is a generic technology, 802.6 DQDB is a particular network
standard based on ATM technology.

4. SMDS is a service definition based on DQDB, and therefore ATM
technology.

5. The ATM Forum is attempting to define a simplified ATM service
definition which uses some aspects of CCITT work.  Its scope is
restricted to promote early acceptance of ATM technology.

Perhaps we need to choose a better name for the ATM Forum to avoid the
confusion its name has created.  Any suggestions?

Cheers,
Dean

Newsgroups: comp.dcom.cell-relay
From: KUMQUAT@SMCVAX.BITNET
Subject: (none)
Organization: Indiana University
Date: Wed, 7 Oct 1992 13:40:04 GMT

Received: from SMCVAX.BITNET (KUMQUAT) by MITVMA.MIT.EDU (Mailer R2.08 R208004)
 with BSMTP id 7423; Wed, 07 Oct 92 09:23:58 EDT
Date: Wed, 7 Oct 92 09:21 EDT
From: "Gary C. Kessler, +1 802-879-3375" <KUMQUAT@SMCVAX.BITNET>
Subject: RE: ATM over T1; use of header address bytes
To: comp.dcom.cell-relay@ucs.indiana.edu
X-VMS-To: IN%"comp.dcom.cell-relay@ucs.indiana.edu"

> From Barry Robbins:

>From what I've read and my conversations with vendors, it would seem that
>ATM interface rates officially start at 155Mbps (OC3), with 45Mbps (T3)
>the lowest rate any switch will support.

 Per the CCITT, this is correct.  The B-ISDN specs. are written to a 155.52
Mbps (OC-3/STM-1) interface, with an option for the 622.08 Mbps
(OC-12/STM-4) intercace.

>My first question:
>Is it possible, in a private network using leased T1s and an ATM switch, to
>support ATM cells over T1 interfaces?  Is anybody out there doing this?  Do
>any switch vendors support this?   How would one pack the cells into the
>T1 frame, just skip every 193rd framing bit?  How are cells delineated on a
>synchronous interface in general.

I don't know if anyone is doing it, but sure, you could pack cells onto a
T1 channel.  A cell is 53 octets long and, yes, you'd merely skip every
193rd bit and use the other 192 bits as a 1.536 Mbps pipe.  This is
essentailly similar to putting cells into SONET/SDH; you skip the overhead
locations.

ATM cells are delineated by a number of mechanisms, commonly by aligning
based upon the header error check field.

>Second question:
>The ATM cell defined for user access has two bytes of VCI (virtual circuit ID),
>and 1 byte of VPI (virtual path ID).  I haven't yet got my hands on any ATM
>specs.  How are these two fields used?  How do they differ?  Are they defined
>for end-to-end addressing?  Or can the switch and/or network stomp on them?
>Any detailed info/pointers appreciated.  Which specs should I get?

You really do have to read the specs to see this in more detail.  The
virtual channel id. identifies a specific virtual channel, which is more or
less analogous to a virtual circuit.  A virtual path, more or less, is a
collection of VCs with the same ATM endpoints.  Thus, switching a VP
switches one or more VCs.  The switch will probably change VPI/VCI values
since there is no reason that the VCI/VPI will be the same on both ends
(just like the X.25 logical channel number may differ on both ends).

B-ISDN specs are I.121, I.150 (ATM Functional Characteristics), I.211
(Service Aspects), I.311 (General Network Aspects), I.321 (Protocol
reference model), I.327 (functional architecture), I.362 (AAL description),
I.363 (AAL specification), I.413 (UNI), I.432 (UNI Physical Layer).  You
can get these from IGI (1-800-323-1088) or Phillips Pub. (1-800-OMNICOM).

Gary Kessler
MAN Technology Corp.
Colchester, VT
802-879-3375
kumquat@smcvax.bitnet
From: amitava@cs.tamu.edu (Amitava Raha)
Subject: Burstiness  and Peak bit rate info. wanted
Organization: Computer Science Department, Texas A&M University
Date: Thu, 8 Oct 1992 16:02:52 GMT


I would appreciate it if anyone could give some information/ref  as to how 
the peakbit rate and burstiness is decided per application. I am interested
in how these paramters are used by the
network management to  make  a connection.

thanks

amitava


--


Newsgroups: comp.dcom.cell-relay
From: amitava@cs.tamu.edu (Amitava Raha)
Subject: Burstiness  and Peak bit rate info. wanted
Organization: Computer Science Department, Texas A&M University
Date: Thu, 8 Oct 1992 16:21:48 GMT


I would appreciate it if anyone could give some information/ref  as to how 
the peakbit rate and burstiness is decided per application. I am interested
in how these paramters are used by the
network management to  make  a connection.

thanks

amitava


--


Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Customers Speak
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Tue, 13 Oct 92 16:37:42 GMT

Customers Speak:

Communications Week always has timely articles on cell relay, this
week they had an article on customer requests.  Among the respondents
was EDS, which said in effect that they want a common management layer
to operate over all vendors switches.  They did not go so far as to
request a clonable switching architecture, however.

Another article discussed MFS Datanet's effort to build a cell relay 
value added network, using vendor supplied switches, from a variety of
vendors.

The customers seem very tuned in to the issue of providing a common
control layer.  Suggestion:  If a programmable protocol standard exists,
then each switch vendor can build the protocol interpreter, and the best
management solutions will then operate on all switches.
Newsgroups: comp.dcom.cell-relay
From: mty@ntuix.ntu.ac.sg (Yap Ma Tit)
Subject: Looking for an ATM Switch
Organization: Nanyang Technological University - Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Thu, 15 Oct 1992 01:06:30 GMT

I am looking for an ATM (asynchronous transfer mode) switch
to support our research in high-speed multiservice networks
and distributed multimedia applications.

If you come across any of these switches, please email me
the suppliers' address, fax no.,...

Thanks

Ma Tit, Yap
mty@ntuix.ntu.ac.sg
astyap@ntuvax.bitnet
mty@comp.lancs.ac.uk

Newsgroups: comp.dcom.cell-relay
From: bantha.decnet.lockheed.com!young
Subject: Re: VCI/VPI usage
Reply-To: young@bantha.decnet.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Thu, 8 Oct 92 16:31:16 GMT

In article <9228217.5740@mulga.cs.mu.OZ.AU>, gja@mullian.ee.mu.oz.au (Grenville Armitage) writes:
>In article <1992Oct7.135314.8217@iscnvx.lmsc.lockheed.com> myoung@force.ssd.lmsc.lockheed.com writes:
>
>>Work Group Connectivity:
>	[..]
>>  What's missing from this picture?
>
>Without meaning to be impolite, but I find many of your postings to be
>missing (to my mind, at least) a clear connection between the applications
>you postulate and the cell level technology
> ...
>Or perhaps I'm just missing something?

The responder indicates that I mix layers somewhat in examining the
possible applications.  That is a valuable function: "mixing layers 
up a little bit" and examining various applications which might 
result, and preferably do it before the standards become too 
established.

We all understand that ATM is good for the telephone companies,
and we support that application, it reduces trunk costs.

But, as for the end user connections:

Up to now the ATM interest groups have mentioned only television
as the new enabled application.  Other than that, they claim to
allow the existing applications to work faster, but then so do the
TCP/IP groups, doesn't TCP/IP have the same bandwidth on demand
capability when used with HDLC and routers? And even the TCP/IP advocates 
have demonstrated live video.  Is this entire market going to be built 
upon television?

My guess is that cell relay, as a private network and work group offering,
will succeed or fail depending upon the level of flexibility offered
in the use of the virtual paths.  The virtual path is the only thing new.
Matt Young
Lockheed
(408) 756-6789
Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Another Application
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Mon, 12 Oct 92 13:27:14 GMT

The Distributed Data Base Problem:

Distributed data bases must be updated in a consistent manner if 
enterprise transaction systems are to be implemented on down-sized
PC networks.  Here is a potential solution using the switched virtual
path capability of cell relay.

Assume that widely separated PCs may consummate a transaction which must
immediately be updated in multiple duplicate copies of the database.
Since two transactions may asynchronously enter the distributed network,
one transaction must lock the data bases, perform the update, and
release the lock before the second transaction can proceed.

If the data bases are connected via some logical spanning tree, then
each transaction enters the tree at the point at which the transaction 
is initiated.  The transaction must propagate throughout the tree, and
upon meeting a second transaction, (which is attempting to lock the tree
from another direction) will cause the second to either wait, or backoff.

Upon conquering the spanning tree, the update may take place, then the
tree is released by backing out along the same routes used originally to 
take control of the tree.

Requirements:

The problem as posed requires that some protocol interpretation takes
place inside the network cloud for two reasons:  1) The spreading 
throughout the tree involves less bandwidth than a "one to many" broadcast 
from the transaction point and 2) Synchronization and locking is more 
easily accomplished by having all transaction propagate over the same tree.

If a wavefront type of protocol does execute within the cloud, it also
requires that intermediate nodes be treated as endpoints where the protocol
can be unpackaged and interpreted.  But the logical tree may not involve
every physical node, and some spans within the logical tree would like to 
pass through some of the intermediate nodes.

With the additional requirement for low latency, switched virtual paths
seem to be the favored mechanism.  The VCI/VPI pairs become the 
describing variables for intelligent propagation.
Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Re: ATM over T1; use of header address bytes
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Wed, 7 Oct 92 13:50:29 GMT

In article <1992Oct7.004409.28768@qualcomm.com>, brobbins@qualcomm.com (Barry Robbins) writes:
>>From what I've read and my conversations with vendors, it would seem that
>ATM interface rates officially start at 155Mbps (OC3), with 45Mbps (T3) 
>the lowest rate any switch will support. 
>
>My first question:
>Is it possible, in a private network using leased T1s and an ATM switch, to 
>support ATM cells over T1 interfaces?  Is anybody out there doing this?  Do 
>any switch vendors support this?   How would one pack the cells into the
>T1 frame, just skip every 193rd framing bit?  How are cells delineated on a
>synchronous interface in general.
>
  Starting out with a very naive response, why can't the T-1 line be used
as a simple byte stream, leaving the issue of the T-1 frame to the lower
level.  Since the T-1 cells are fixed in length, then cell relay framing 
byte would synchronize the receiver.  How does SMDS do this?
From: fengstad@xi.uleth.ca (Grant Fengstad)
Newsgroups: comp.dcom.sys.cisco
Subject: Accessing SNA Gateway through CISCO Routers
Date: 15 Oct 92 23:30:48 GMT
Organization: University of Lethbridge

We are in the process of integrating our Data Communications Network
into our Parent companies.

We (CRA) are primarily based on Ethernet topology and use Cisco routers
to route both IP and Novell's IPX based traffic.

Our parent (Canadian Airlines) is primarily based on an SNA Network and
presently have many Token Ring Source Bridges in place.  We have
recently purchased several AGS+/4 and IGS/R Routers to form a net
Network.  The IGS/R routers will be placed on some of our properties
while the AGS+/4's will be placed at Canadian's properties.  The IGS/R
will be connected via 56K Digital DS0 links to the AGS+/4's.  

In addition to inter-connecting the Networks, it is our desire to access
an OS/2 based SNA Gateway through the Network to get both Terminal and
File transfer sessions to the 370 based mainframes.

My question then is...  Is it possible to run a 3270 based Terminal
Emulation package, such as IBM's PC/3270, have the program communicate
over the Ethernet channel (via 802.2/SNAP), where then the IGS/R will
forward the packets to the AGS+/4 and finally the AGS+/4 will know how
to forward to the SNA Gateway, which will be situated on the same
Token Ring as the AGS+/4?

The AGS+/4 routers will have the bridging software.  The IGS/R's will
not. 

I appreciate any assistance that can be offered.  Email replies are
preferred as I do not get on this group that often.

If there is any interest, I will post a follow-up summary.

thanks.

--
#====================================================================#
# Grant M. Fengstad		     E Mail:    fengstad@xi.Uleth.CA #
# Manager, Network Operations	     Voice:     (403) 382-6724       #
# Canadian Regional Airlines Ltd.    FAX:	(403) 327-1229       #
#====================================================================#
Newsgroups: comp.dcom.sys.cisco
From: Tom_Karolyshyn@dgc.ceo.dg.com
Subject: SNMP priority
Distribution: cu
Date: 14 Oct 92 17:08:10 edt
X-Note1: mail msgid was <9210142208.AB00040@rtp41.rtp.dg.com>
X-Note2: message-id generated by recnews

Message:
Occasionally, when SNMP polling a couple of our remote IGS chassis 
(8.3(3) software; 19.2K serial links) we get no SNMP response.  We 
are, however, able to telnet to the IGS and confirm that it is up.  
We can also see at this time that someone has pretty much buried the 
19.2K link with a megafile transfer of some sort.
My question is this - will the IGS choose to not respond to an SNMP 
GET query if it is too busy forwarding packets?
I'm trying to determine if there is a problem here, i.e., the SNMP 
responses are getting lost, or if the IGS is deliberately ignoring 
the SNMP packets to maintain routing throughput.
Somewhere I'd heard that a router's primary function is to move 
packets, and responding to SNMP queries is secondary.  Is that true?
If so, is there a way to move SNMP responses up on the priority list?
We really can't afford to have SNMP responses on the backburner.
Thanks
Tom Karolyshyn
Data General Corp
Westboro, MA 01580
508-870-7936


Newsgroups: comp.dcom.sys.cisco
From: Raj Sabnani <sabnani@cisco.com>
Subject: gosip addresses
Distribution: cu
Date: 16 Oct 92 14:27:10 -0700
X-Note1: mail msgid was <9210162127.AA28137@last-call.cisco.com>
X-Note2: message-id generated by recnews


>>What is the authority to obtain a GOSIP address for ISO protocol?

>>Thanks, jim

It is the GSA ( Govt. Services Administration ). I think this is
administered by the DOD. 

Regards,

Raj Sabnani                                ..        ..
Customer Engineering                       ||        ||
Cisco Systems, Inc                         ||        ||
Menlo Park, CA 94025                      ||||      ||||
Tel  : 800.553.2447                   ..:||||||:..:||||||:..
Fax  : 415.903.8787                     Cisco Systems, Inc.
E-mail: sabnani@cisco.com