Cell Relay Archive

Cell Relay Retreat>List Archive>month:2000-Jan> msg00086



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: SAR & AAL2 ----WHY NOT?????

  • From: riwells@my-deja.com
  • Date: Wed, 19 Jan 2000 22:24:27 GMT
  • Organization: Deja.com - Before you buy.
  • X-Article-Creation-Date: Wed Jan 19 22:24:27 2000 GMT


I am reproducing below the views of Vinod Jeyachandran
<vjeyachandran@mil3.com> on the above subject since his
posting is not showing on my news server, even though it
is picked up by the Cell Relay Archive.

IMHO, Vinod's interpretation that for AAL2 the SAR functionality
lies in the CPS layer seems to be completely at a variance with
the I.366.2 standard, which makes SAR a sub-layer of SCCS, as the
following text (verbatim from the standard) indicates:

"With this Segmentation and Reassembly Service Specific Convergence
sublayer applied for a Service Specific Convergence sublayer for the
AAL type 2, it is possible to transport a packet size of more than
the maximum length specified in the CPS and also to multiplex with
low-rate and short length packets in delay sensitive application".

In fact, this is not the only place in the standard where reference
to the "Segmentation and Reassembly Service Specific Convergence
sublayer" has made.  I don't know how Venod concluded that SAR
functionality is handled in the CPS layer.


----------------Venod's posting begin------------------------------
Here are my observations on the behavior of AAL2.

  If the CPS of AAL2 follows the I.363.2 recommendations there will no
requirement for a SAR layer. The CPS-PDU that comes out of the AAL2 CPS
layer is exactly 48 bytes - no less no more.


(1) The Payload from the SSCS layer is received as the CPS-SDU. Assume
that
the Payload is greater than 44 octets
  ____________________
|                                   |
|____________________|

|---- CPS SDU --------------|

(2) A three byte CPS header is added to the incoming SDU and a CPS
packet
is formed. (Refer Sec 9.1). The TIMER_CU is started.
  ____________________  ___
|                                   ||       |
|____________________||____|

|----------CPS Packet ---------------|

(3) A 47 Octet segment is removed from this packet and a 48 Octet CPS-
PDU
is created by adding a One Octet header to this CPS-PDU Payload. (Ref
(Sec 9.2)
  _____________  ___
|                       ||      |
|_____________||___ |
                                                              ===&gt;
ATM
Cell Payload (Pre-Adapted)
|--- CPS PDU ---|
       Payload
|-- CPS PDU ------------|

(4) The remaining octets of the CPS packet remain in the CPS layer
until
expiry of TIMER_CU or arrival of more data from the higher layer
sufficient
to create a CPS-PDU payload. At this point the remaining Octets are
removed
from the buffer and 48 octet CPS-PDU is created. Padding is done if
required.

  The operations of the CPS-transmitter is fully described in section
10.1
of the recommendation.

I believe that the rationale behind incorporating the SAR functionality
into the CPS layer is to increase the channel utilization and at the
same
time keep the ETE delays low. Though the argument does not hold very
good
for large packets, it makes good sense when dealing with shorter sized
packets.

Back to you guys.

Vinod

************************************************
Vinod Jeyachandran,
Senior Engineer.
MIL 3, Inc,
Old protocols never die, they just get in the way.
************************************************

----------------Vinod's posting begin------------------------------






In article <387F82C9.94F4CB90@sta.samsung.com>,
  Jeff Wilson <jwilson@sta.samsung.com> wrote:
> Can someone kindly explain why AAL2 gets by without SAR functionality?
> Is there any reason why AAL2 has a completely different structure than
> other adaptation layers?
>
> I have already gone through I.363.2, without much insight.
>
> A copy of the response to my email address will be appreciated.
>
> Regards,
> Jeff
> jwilson@sta.samsung.com
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.