From: icarus!mbu@fokus.gmd.de (M. Burak)
Newsgroups: comp.dcom.cell-relay
Subject: Re: AAL 5 query
Date: 4 Sep 92 10:41:01 GMT
Organization: GMD-Fokus (Berlin)



In article <1992Sep2.121122.15112@ccsun.strath.ac.uk>, 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. 
>
>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.
>
>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.
>
>This seems to mean that	without some
>method of identifying which AAL entity a VCI/VPI pair's incoming cells should 
>be sent to, only one connection i.e. one VCI/VPI pair can be supported on any
>interface using this scheme. 
>
>Was this deliberate in order to simplify the document, and such an association 
>is left for the reader to infer, or am I missing something very basic?
>
>Help would be appreciated.
>
>-- 
>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. 

>This seems like a basic question.  Can we have any answer posted to this,
>please?


As far as I know, D.W. Stevenson is basically right. Probably in the future there
will be interactions defined between the management plane, control plane and the
user plane to solve this problem. As far as I read the CCITT standards there are 
no interactions defined yet to solve this problem. There will probably be a discussi
on about indicating the AAL type by signalling means in January next year by CCITT.

Another approach to solve this problem is to look at the real world. This means,
that there could be a proprietary interface between the ATM/AAL boudary, forwarding the
received cells to the according AALs. This can be achieved by marking the received 
ATM cells.
This is only a proposal and a function local in the user protocol stack.
I hope that helped a little bit.

Markus
Newsgroups: comp.dcom.cell-relay