From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: AAL 5 query
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 4 Sep 1992 15:20:03 GMT

craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:
+---------------
| Can somebody perhaps clarify my understanding of certain parts of AAL5...
| 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 ...or am I missing something very basic?
+---------------

Yes, your basic model is a bit skewed. You've perhaps become a little bit
blinded by an overly-rigid "stacks of protocols" view. [As Michael Padlipsky
and others have noted, "Layering makes a good servant but a bad master."]
It is not at all necessary that every demultiplexing step be done dynamically.
Many or even *all* of the demultiplexing steps up the "protocol stacks" can
be done statically at call-setup time.

Then all the receiver needs to see is the VPI/VCI, and based on that *alone*
it knows all the demultiplexing and/or processing steps up the protocol stack
for that particular call. For example, VCI=3 might be a voice call, using AAL1;
VCI=17 might be using AAL5/802.2/SNAP/OUI=0/IP/UDP/RPC/NFS; and so on.

There is absolutely no need that the information about the particular stack
be carried in every cell, or even in every frame. It's implicit from the VCI.
The fact that we may choose to continue to carry some of that overhead in
the packets for the sake of historical code compatibility is in no way an
admission that we *have* to do it that way. Since there is no historical
compatibility problem with identifying an AAL, we can feel free to leave
it out of the per-cell or per-frame dynamic information, and rely on the
static (for the duration of the call) information.

Conversely, just because we *can* deduce a certain demultiplexing key from
the VCI is no reason to abandon useful traditional forms for the sake of
a few saved bytes. Yes, the VPI/VCI *could* tell you not only the AAL, but
the destination_{LSAP,NSAP,TSAP,process} and source {LSAP,NSAP,TSAP,process}
as well. But if we cut those bytes out of the packets that we send via ATM
[as some have suggested], it will be harder for an ATM end-point to act as
an internetwork router. [Note I said "harder", not impossible or even very
difficult.] The "compressed" packets will have to be "built out" before being
routed [much as SLIP with header-compression does today].

+---------------
| A similar problem occurs when multiplexing outgoing cells at the ATM layer,
| because multiple AAL entities will pass cells to the ATM layer, but without
| any parameter to say which AAL they are from.
+---------------

Only if you believe in "AAL Entities" as separate objects. I don't. AAL
processing is just a small additional *attribute* of the processing of
data arriving or departing on a given virtual circuit, and it can be
handled by that circuit "in-line", rather than as a separate "entity".
In fact, all of the proposed ATM chips I know of handle all of the AAL's
(1-5) in the chip. Which AAL is used is just another small field in the
per-VC "context" RAM, along with which reassembly queue to use, what
rate control to use, etc.

If you treat ATM & all the AALs as a single (parameterized) "physical layer",
the view gets a lot simpler.


-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