#1. The source device encapsulates whatever traffic it has to send in a
AAL5 PDU then segments the PDU and places the pieces of the PDU into the
payload of the ATM cells.
#2. AAL5 is almost always is used in UBR (unspecified bit rate) calls.
ie: No garuntee from the carrier that they will deliver your cell to
the destination.
#3. During times of congestion the carrier will drop cells in a UBR
call.
#4. If a cell (or cells) are dropped within the carrier's network; the
AAL5 PDU's CRC will be invalid.
#5. There is a EOF (end of frame) bit within the Cell header; which
tells the destination when it has recieved the last cell comprising the
AAL5 PDU.
#6. If the EOF cell is lost then the destination will try to recombine
2 (or more) AAL5 PDUs possibly resulting in a PDU that is too large.
OR
If the only cell comprising a AAL5 PDU made it through the network was
the EOF cell then the destination will find that the reassembled AAL5
PDU is smaller than the min allowed
This is a Breif overwiew of what ATM does and why you'll see AAL5
errors.
There are always ifs and buts and a million little details; BUT I won't
get into those....
PS: if the errored AAL5 frames are not over 1% then don't worry about
it.
DaveC
Q wrote:
>
> I'm getting AAL5 CRC and AAL5 Length errors. They are both tied to one
> another in terms of rate of errors. This is a difficult problem in terms
> that they are both related. One problem is that the other sidce of the WAN
> is a Cabletron SSR 8600 hunk oof crap. Someone give me a clue...TIA!
>
> marc
> FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=3711&t=3682
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]