The IP over ATM Mailing List Archive by date

[bryang@eng.adaptec.com (Bryan Gleeson)]

Tim,

>
>To my knowledge there are (at least!) 2 places where whole frames are
>discarded due to the loss of a few cells.  This may obviously take
>place in the SAR layer at the destination;  it may also take place
>in the network, if the switch is implementing "frame discard" (which
>has -at least- 2 forms:  either throw away the rest of a frame after
>congestion forces you to throw away an associated cell, or predict
>imminent congestion and throw away the next complete frame).
>
>In response to the latter, the new [4.0] ATM Forum signaling specification
>will support the explicit indication of "frame discard".  The idea is to
>control this on a per-connection basis.
>
>I don't believe the issue of loss at the SAR layer, has been addressed.
>I think it should be solved in the ATM domain, through per-connection
>signaling.  Someone would have to propose how to do so, and bring a 
>contribution to the Forum.  This WG could also offer a liason to the
>ATM Forum (via Drew Perkins or Joel Halpern), either proposing a solution
>or proposing that a solution be developed.
>

I'd just like to clarify why the per-connection signalling is necessary 
to allow corrupted data delivery. In a simple case of two applications
talking directly over one VCC it is not needed. The applications
know if they can handle corrupted data or not, and when they "turn on"
the VCC at the board level they can indicate if they want corrupted
data to be delivered, thus it is a local decision. If there is a frame
switch in the path (e.g. a multicast server) or an interworking/edge device
then it doesn't know what it should do with corrupted data and so has to 
be explicitly told about it. So seems like we need two bits - 
a "frame discard on congestion" and a "frame discard on corruption".
Presumably BCOB-X fits into the picture also as this indicates to
the network whether it should treat the VCC at the cell level
or is allowed to take AAL framing into account.

BTW there are ATM boards today that allow corrupted data delivery.
The behaviour is as for uncorrupted data except a flag is set to
indicate that the CRC failed. Most drivers don't use this feature
though. I believe the ITU-T are having an interim meeting this month on 
corrupted data in order to get some words written before the spec 
(not sure what the number is) is frozen.

Bryan Gleeson
Adaptec.