HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.dcom.cell-relay

In comp.dcom.cell-relay, craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:

> Can somebody perhaps clarify my understanding of certain parts of AAL5:

> I'm looking at the situation where a host requires to have more than one 
> VC open at one time. In this case, one AAL entity is required for each
> connection. ATM-SDUs from each AAL are multiplexed/demux'd by a single
> ATM layer entity in the interface. This gives the following structure for 
> the interface:

> 			 ATM physical connection
> 				    |
> 				    |  
> 				ATM entity 
> 				|   |   |
> 			       AAL AAL  AAL
				
> 				   CPU



> In order to transfer information across a virtual connection, the user layer
> passes a MAAL-CREATE.request primitive (with the far end ATM_CEI and
> AAL_CEI as parameters) to initialise new AAL state machines for a new AAL 
> entity. 

Why are the far end connection identifiers specified here?
And, is this explicity documented?

> There is no primitive that is passed from the MAAL (or AAL) entity to the ATM
> layer which says "a new connection is being created, please assign a new
> VCI/VPI pair for use with this AAL and associate cells to/from this 
> VCI/VPI pair with this newly created AAL entity.". 

> As far as I can see, this means that the ATM layer is unable to demultiplex
> cells to the correct AAL entity, since firstly, the ATM layer doesn't know
> which VCI/VPI corresponds to which AAL and secondly, there is no parameter
> in the ATM-DATA.indicate primitive to identify a unique AAL entity to 
> which each ATM-SDU should be passed.

True, however
I've always assumed (although one should NOT assume anything here) that a
VPI/VCI was automagically associated with an AAL_CEI in the ATM entity,
and hence this is how (de)multiplexing was done.

Tony Wiley.
Newsgroups: comp.dcom.cell-relay
From: craa85@ccsun.strath.ac.uk ( D.W.Stevenson)
Subject: Re: Future of IP routers
Organization: University of Strathclyde
Date: Thu, 27 Aug 1992 08:12:52 GMT

In article <BtLKKH.CJ6@usenet.ucs.indiana.edu>, robelr@ucs.indiana.edu (Allen Robel) writes:
|> In article <1992Aug26.095756.5247@ccsun.strath.ac.uk>  
|> craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:
|> > type. This will remove the requirement to send video/audio traffic via a  
|> router,
|> > because the video/audio AAL entities will connect directly with the  
|> video/audio
|> > AAL entities at the other end.
|> 
|> Which means that the filtering functionality currently available
|> in routers gets pushed out to end nodes and is carried out
|> at call setup?  

The end node is responsible for REQUESTING a call set up. It is up to the 
network i.e. an ATM switch to decide whether the call can be connected or not.
Functionality for restricting calls will presumably be built into the switch.
The addressing issues for ATM still haven't been resolved yet 
but I imagine it will be possible to address an individual service and hence 
enforce policy restrictions.

This is of course good news for the telcos and switch manufacturers, since over 
the years they have seen their dominance of the local area data comms markets 
wiped out by broadcast LAN technology and they can now grab it back by building 
local ATM switches and providing outsourced local ATM networks.

-- 
Dave Stevenson 				d.w.stevenson@uk.ac.strath
Computer Centre				Tel : 041-552 4400 x3461
University of Strathclyde
Glasgow, U.K.
Newsgroups: comp.dcom.cell-relay
From: bantha.decnet.lockheed.com!young
Subject: Re: Another Problem
Reply-To: young@bantha.decnet.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Mon, 31 Aug 92 16:05:29 GMT

In article <p8bpe4o@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <1992Aug30.164226.2031@iscnvx.lmsc.lockheed.com>, bantha.decnet.lockheed.com!young writes:
>> This newsgroup continues to debate the interface between TCP/IP routers
>> and ATM. Must be an important application.
>> 
>> Now here is another problem which ATM might solve.
>> 
>> As I look around this company I see hundreds of little cubic foot computers
>> on each desktop, exactly alike, distributed geographically.  Some companies
>> literally have thousands of these things.
>> 
>> Imagine that an account executive wants to read into his spread sheet the
>> entire daily summary of mail orders spread over a number of distributed
>> offices.  Thus, he wants to extract a particular file located in each of
>> a large set of desktop machines.  
>> 
>
>Are you sure that ATM is an obvious part of a solution to this kind of
>problem?
>
>Wouldn't a naive ATM based solution involve setting up virtual circuits
>to each of the target machines, some fixed number at a time, probably
>one, with the consequent terrible response times?  And wouldn't a naive
>ATM based system involve a lot of manual configuring?
>
>Doesn't this sound more like an application for a multicast based
>"distributed" application?  Perhaps some kind of multicast remote
>procedure call?  Using UDP/IP multicast?
>
>That is not to say that the layers below UDP/IP might not involve one
>or more wide area or local ATM circuits.
>
>
>Vernon Schryver,  vjs@sgi.com
Yes, Yes the solution needs some kind of exploratory, application specific,
protocol which can search out and find, then bind those desktops in
a spanning tree, and then have the capacity to extract file data from
each node, all in a parallel fashion.

Does ATM help?  Yes, if the vpi/vci are not naive.  The intelligent
messaging system performs best when it has a virtual "graph machine" below
it on which it can build its tracks, tear them down, tunnel about etc.
The problem is not that ATM virtual paths are naive, the problem is that
the ATM architecture does not postulate a simple "bios" for path building
and network exploration.
From: craa85@ccsun.strath.ac.uk ( D.W.Stevenson)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Future of IP routers
Date: 3 Sep 92 09:41:48 GMT
Organization: University of Strathclyde

In article <JTW.92Aug26203449@pmws.lcs.mit.edu>, jtw@lcs.mit.edu (John Wroclawski) writes:
|> 
|>     This problem will be overcome when people start using ATM based
|>     backplanes internal to the router.
|> 
|> I don't understand this point. You appear to be describing the
|> difference between a time-division "bus" backplane and a parallel or
|> "switch-fabric" backplane. ATM has nothing to do with this; either
|> design can be used to switch either IP or ATM.
|>

You are right in saying ATM has nothing to do with this. I'm just pointing out
the current limitations of high end commercial routers, which use time division
backplanes whereas in the future, in order to get the increased backplane
throughput required to match the increase in packet processing power of each
interface, they will use switch fabric backplanes instead. ATM is the most likely
candidate because ATM silicon will soon be available, in quantity and at low cost.

-- 
Dave Stevenson 				d.w.stevenson@strath.ac.uk
Computer Centre Communications		Tel : 44 41-552 4400 ext 3461
University of Strathclyde
Glasgow, Scotland, U.K.
From: grayt@Software.Mitel.COM (Tom Gray)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Future of IP routers
Date: 28 Aug 92 15:12:13 GMT
Organization: Mitel. Kanata (Ontario). Canada.

In article <BtLKKH.CJ6@usenet.ucs.indiana.edu> robelr@mythos.ucs.indiana.edu writes:
>In article <1992Aug26.095756.5247@ccsun.strath.ac.uk>  
>craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:
>> type. This will remove the requirement to send video/audio traffic via a  
>router,
>> because the video/audio AAL entities will connect directly with the  
>video/audio
>> AAL entities at the other end.
>
>Which means that the filtering functionality currently available
>in routers gets pushed out to end nodes and is carried out
>at call setup?  I'm not sure that I'm comfortable with this
>sort of arrangement.  Take a hypothetical situation where,
>as a part of organizational policy--possibly for budgetary
>reasons--users should be denied access to interactive video
>communication outside of a given administrative domain but

The problem that you have described is handled even now
fro voice communications by PBX's. Users can be denied
access, can be granted access only to cheaper services
,can be granted access on a time of day basis etc.
etc. etc.

There is no prblem in handling such restrictions and even
more complicated restrictions at call set up.






.
.
.
.

-- 
i.sinature
From: bantha.decnet.lockheed.com!young
Subject: Re: Future of IP routers
Reply-To: young@bantha.decnet.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Mon, 31 Aug 92 16:12:14 GMT

In article <3476@ra.nrl.navy.mil>, atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
>In article <1992Aug28.092320.17105@ccsun.strath.ac.uk> craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:
>
>>The point I am trying to make is that IP is 
>>designed to route packets, and by route I mean
>>direct the packet to the next router on it's 
>>at each intervening router for router software to process. 
>
>  Not at all the same function.  IP performs dynamic routing with the
>path traversed (by packets from source A to destination B) changing
>all the time based on loading, congestion, and whatever.  With ATM,
>routing is done only once (from source A to destination B) -- only at
>call setup time -- and so ATM does switching at switches rather than
>routing at switches.  If the ATM path chosen at call setup time has a problem
>(e.g. a switch fails) then connectivity is completely lost.  If an IP router
>dies, the other routers will automatically and dynamically route around it
>until it comes back up and connectivity is not lost.
>
All good ATM networks will have re-route capability on switch failure.
Also, there are methods for congestion based routing over multiple ATM paths,
but these methods will require the equivalent of an IP above the cell
layer for re-assembly.  I do not think that IP and ATM are in competition
here, ATM is a very good support for IP and IP offers a ready built
message control system for ATM.
From: gray@cac.washington.edu (Terry Gray)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Future of IP routers
Date: 30 Aug 92 02:14:54 GMT
Article-I.D.: u.1992Aug30.021454.29795
Organization: UW Networks and Distributed Computing

In article <1992Aug28.092320.17105@ccsun.strath.ac.uk> craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:
>
>In the future, it should be possible to open a data 
>connection from my workstation to another workstation
>in another country directly over the ATM network, 
>without going near an IP (or OSI equivalent) router and
>hence will the IP routing layer (or it's OSI equivalent) 
>really be necessary? 
>
>To achieve interoperability
>with other non ATM workstations it certainly will be, but 
>functionally, I suspect not. Studying the ISO
>IP protocol I see "When the source and destination stations 
>are connected to the same network, an
>internet protocol is not needed. In that case, the internet layer 
>is null and the (internet) header consists
>of the single protocol identifier of 8 bits." 
>(taken from "Handbook of Computer Communications Standards"
>Vol 1 by Stallings). Surely once I can open an ATM connection 
>from my workstation to your workstation, 
>passing across the world, through the global ATM network of switches, 
>we then become connected to the same network
>and so no internet layer is needed and IP routers or equivalent 
>will no longer be required for data transfer over the ATM network. 
>
>The original subject of this posting was whether IP routers would be
>required in the future, or did I miss the point of the original posting?

Dave,
I think you may be forgetting the issue of layer 3 fault isolation.
One of the key reasons we use IP routers is to provide firewalls for
an important class of faults which do not stop at bridges or repeaters.
I believe --somebody correct me if this is incorrect-- that the same 
issues will apply to ATM switches living in an IP environment.  For example,
if an ARP packet (or any other broadcast packet) appears at one port 
of an ATM switch, does it not appear on all other ports of the switch,
assuming the appropriate AAL for handling the IP world?  

If so, you have a terrific opportunity for one department's broadcast
storm to become *everyone's* broadcast storm.

I too am just learning about ATM, so I hope to elicit expert comment on
the above, but it sure seems to me that IP routers will continue to be
essential ingredients for a campus network, if you place a premium on
high availability.  Unfortunately, the ATM router interfaces are likely
to be *very* spendy...



--
Terry Gray
 University of Washington
  gray@cac.washington.edu
Newsgroups: comp.dcom.cell-relay
From: dan@dbg.dev.cdx.mot.com (Dan Grossman)
Subject: Re: Bare Bones Adaptation
Organization: Motorola Codex, Canton, Massachusetts
Date: Thu, 3 Sep 1992 14:22:06 GMT

The idea of AAL5 was not that it would be the one and only AAL.
Rather, it was intended to meet the particular needs of data (and
perhaps image) in a more simple and efficient fashion than AAL 3/4.
Those of us who fought for AAL5 during the T1S1 battles of last year
recognized that the immediate, short term need for ATM would be for
these kinds of applications, and that frankly, AAL 3/4 would be too
cumbersome for these purposes.  I don't think that anybody ever had
it in mind that you would use AAL5 for real-time voice or video.

My guess is that AAL 1 will achieve some degree of acceptance for
carrying non-packetized video and audio;  that in the longer term,
when AAL 2 and the corresponding video and audio coding standards are
complete, AAL 2 will coexist with, then ultimately supplant AAL 1;
that AAL 3/4 will fall by the wayside (unless it is artificially kept
alive by mandating its use in support of signalling);  and AAL 5 will
emerge as the common AAL in support of data, image and other non-real
time traffic.

Newsgroups: comp.dcom.cell-relay
From: bantha.decnet.lockheed.com!young
Subject: Bare Bones Adaptation
Reply-To: young@bantha.decnet.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Tue, 1 Sep 92 15:44:17 GMT

I have a question on the "lean mean" AAL5 adaption layer:

Does this definition cover only the begin and end of message 
indication, leaving the byte count and checksum to be handled
by the application specific upper layer?  

For instance, let's say I am collecting arbitrary uncompressed audio 
from a continous source. With this application, I really have no checksum 
requirement, no message boundaries, just collect bytes.

Is this the bare bones adaption layer? 
Newsgroups: comp.dcom.cell-relay
From: icarus!mbu@fokus.gmd.de (M. Burak)
Subject: Re: Future of IP routers
Organization: GMD-Fokus (Berlin)
Date: Thu, 27 Aug 1992 17:44:48 GMT

Randall Atkinson writes:

>	Claims that one cannot do multimedia over IP look kind of
>silly when you have seen real-time voice/video over today's Internet.
>Given some tweaking of things, I'm quite sure that better quality and
>performance is possible while still using a connectionless network
>protocol and doing routing at the network layer.

Do you really think that TCP/IP over B-ISDN will be the real challenge? As far
as I know, TCP/IP allows you a throughput of 28 Mbit/s over a 140 Mbit/s network.
I don't think that this will be the ultimate protocol performance for high speed networks.
Isn't it better to use faster and probably new protocols on top of the B-ISDN protocol
stack?
Another point is that I don't understand the whole discussion about IP Routers. Nobody
writes that in the B-ISDN there will be Connectionless Servers, taking care of routing
*and* security and address screening and all other management related stuff. Or are 
you talking about setting up connections like for video/audio services using AAL type 5?
If the latter is right than the discussion seems for me ok but if you are talking of an 
public ATM network as envisaged by CCITT then you have the CLS and AAL type 4. Please
tell me if that's right or not.


--
Markus Burak 				burak@fokus.gmd.dbp.de
National Research Corporation		voice: +49-30-25499-262
for					FAX: +49-30-25499-202/168
Mathematics and Data Processing
(GMD-FOKUS)
Berlin Germany
	
		Research Center for Open Communication Systems
Newsgroups: comp.dcom.cell-relay
From: craa85@ccsun.strath.ac.uk ( D.W.Stevenson)
Subject: Re: Future of IP routers
Organization: University of Strathclyde
Date: Tue, 1 Sep 1992 14:15:55 GMT

In article <9224510.20448@mulga.cs.mu.OZ.AU>, gja@mullian.ee.mu.oz.au (Grenville Armitage) writes:

|> 
|> For a user connected to an arbitrary local ATM switch it is unlikely
|> the DNS will be able to return a VCI/VPI pair having any meaningful
|> value. The VCI/VPI which finally carries IP packets into foo@bar.sna.fu
|> will be different to the the VCI (and/or VPI) that any given user
|> needs to send packets to their local ATM switch on.
|> 
As you've indicated, a VCI/VPI pair is only meaningful between host and
first switch. At the switch it's translated into a different VCI/VPI. 

Assuming the 
first switch is a local area switch i.e. under control of the local network
manager, any permanent virtual circuits can have VCI/VPI pairs stored in 
the DNS.

When a cell reaches the first switch, the incoming VCI/VPI uniquely
identifies the outgoing VCI/VPI pair, at which point the incoming VCI/VPI
loses any significance for the next hop on the cell's journey and can be
reused for another connection. This means a
particular VCI/VPI pair only has local significance between two ATM entities
and so I don't see where the problem with only a limited number of 
VCI/VPI identifiers occurs.

-- 
Dave Stevenson 				d.w.stevenson@strath.ac.uk
Computer Centre Communications		Tel : 44 41-552 4400 ext 3461
University of Strathclyde
Glasgow, Scotland, U.K.
From: ms6b+@andrew.cmu.edu (Marvin Sirbu)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Future of IP routers
Date: 26 Aug 92 17:56:11 GMT
Article-I.D.: andrew.geb3Mva00VADI4SMED
Organization: Engineering and Public Policy, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.dcom.cell-relay: 26-Aug-92 Re: Future of IP
routers by Allen Robel@ucs.indiana. 
> Which means that the filtering functionality currently available
> in routers gets pushed out to end nodes and is carried out
> at call setup?  I'm not sure that I'm comfortable with this
> sort of arrangement.  Take a hypothetical situation where,
> as a part of organizational policy--possibly for budgetary
> reasons--users should be denied access to interactive video
> communication outside of a given administrative domain but
> that other services, some of which might include non-interactive
> video/audio retrieval from a subset of information providers, 
> should be allowed.  With TCP, we have "well known" port numbers 

Remember that ATM is going to replace the voice network as well as the
data network.  Take a look at call screening and call control in today's
voice networks; it is actually quite sophisticated.  In an ATM world,
the local ATM switch--acting much like today's PBX--will no doubt be
able to do all kinds of policy restrictions.  Today's PBX can limit
calls to local versus toll or intra-company versus external; it can vary
the service by time of day (toll restriction after 5 pm so the custodial
staff doesn't make long distance calls...) or even provide a different
grade of service depending upon the caller callee pair.  And this is all
done at call setup.  

When the call setup message specifies a service type (e.g. in ISDN the
call setup message can specify "speech" versus "3.1 KHz audio" vs
"unrestricted data" versus "video"), it will be simple enough to add
that to the list of variables on which call setup decisions are made. 
Indeed, if I don't specify that I want circuit switched data capability
when I sign up for ISDN service, -- and pay extra for it compared to
voice only--any call setup message specifying unrestricted data will be
blocked by my CO today!

Marvin Sirbu
CMU
Newsgroups: comp.dcom.cell-relay
From: bantha.decnet.lockheed.com!young
Subject: Security
Reply-To: young@bantha.decnet.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Wed, 26 Aug 92 16:20:40 GMT


	Security in a Cell Relay Network?

Speaking only for private networks, is security that much of a 
problem?  Please explain why I should be concerned.

Can't security filtering be done at the terminals of a cell relay 
network?  At each terminal of the cell relay network, simply
make sure that the VCI table entries are marked for illegal cell ID's.

If my department has been allocated a block of VCI/VPI pair values
for arbitrary use, the ATM network simply ignores any cells coming from
my terminals that are not within my allocated block.

Within my department, I have one or more logical cell relay networks
constructed as I desire, (I am geographically distributed). Now I can 
choose whatever filtering method is available from the software vendors, 
including the use of TCP/IP, to provide filtering systems required by the 
applications I run. 

What is wrong with this picture?
Newsgroups: comp.dcom.cell-relay
From: nicholas@cton.cton.com (Nick Hennenfent)
Subject: frame relay specs?
Organization: Computone, Corp.
Date: Thu, 27 Aug 92 17:07:32 GMT

Where can I get technical documentation/specifications
for frame relay? Thanks.

-- 
Nick Hennenfent
Computone   1100 Northmeadow Parkway   Suite 150   Roswell, GA 30076
VOICE (404) 475-2725 x362    FAX (404) 343-9735
"Visualize whirled peas"
Newsgroups: comp.dcom.cell-relay
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: Bare Bones Adaptation
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 4 Sep 1992 14:16:50 GMT

In article <9224810.18254@mulga.cs.mu.OZ.AU>, gja@mullian.ee.mu.oz.au (Grenville Armitage) writes:
> ...
>                 But your question is similar to asking "what is it
> about Ethernet that needs to know about the next protocol layer up?",
> and the answer is "nothing, really". ...


Quite true, but on the other hand, some layer violating can pay
large dividends in speed.

One common example where having the link layer peak even fiddle with
the bits is "cslip" at 2400 to 38 Kbit/sec.  Other, less well known
cases exist on FDDI at 100 Mbit/sec.


Vernon Schryver,   vjs@sgi.com
Newsgroups: comp.dcom.cell-relay
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: Future of IP routers
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 27 Aug 1992 21:56:49 GMT

In article <1992Aug27.174448.28143@fokus.gmd.de>, icarus!mbu@fokus.gmd.de (M. Burak) writes:
> 
> Do you really think that TCP/IP over B-ISDN will be the real challenge? As far
> as I know, TCP/IP allows you a throughput of 28 Mbit/s over a
> 140 Mbit/s network.

I do not understand the overall debate, nor the relevance of
this point.  However, 28Mbit/se through TCP is a poor showing for anyone.

It has been about a year (maybe more) since T. Skibo reported
32Mbit/sec (33?) over a 300 mile TCP/IP link using FDDI and T3 IP routers
between UNIX workstations.

Loacl TCP/IP speeds over FDDI (100 Mb/s) are 2 or more times faster
in reasonable systems.  (Measured with `ttcp ... -s -l32768`)


Vernon Schryver,  vjs@sgi.com