Vote in favor of keeping ATM

[Martin Birgmeier]

Hi Harti,

Thanks for your pointers.

On 03/09/11 10:40, Harti Brandt wrote:
> Hi Martin,
>
> On Sat, 19 Feb 2011, Martin Birgmeier wrote:
>
[...]
>
> MB>- whether and how it is even possible to inject raw ATM cells,
>
> AF_NATM with AAL0.
>
> MB>- whether I even need "options NATM" (currently I can happily instantiate a
> MB>(of course non-functional) ATM interface using just "device atm"),
>
> Since time has passed I'm not sure on this. You need optiosn NATM either
> to do IP over ATM directly or to get the AF_NATM stuff. Don't remember,
> sorry.

 From looking at the source I believe "options NATM" might only be 
needed to do IP over ATM directly. Specifically, routing information 
seems to be stored somewhere (this is where "options NATM" currently 
breaks). However, I have no idea what one actually gets with just 
"device atm" but no "options NATM". As I said, I can do atm_ifattach() 
successfully, but don't currently know what that really accomplishes.

I do not need IP over ATM, but rather need PPPoA. For this, I need to 
extract the raw PPP frames either directly, or from their LLC 
encapsulation, as per RFC2364. That I want to do via netgraph, 
specifically by expanding the functionality of the ng_atmllc node to 
also treat LLC/ISO, thereby turning ng_atmllc into "ng_llc" (RFC2684).

>
> MB>- what do I need to do on the USB side to start receive and transmit machines
> MB>(do I need to start separate kernel threads or just issue two
> MB>usbd_transfer_setup() calls as for loading the firmware),
>
> I'v no idea on this.
>
> I would suppose, that your driver would appear to the atm stack as an ATM
> interface, right?

That question was in fact more directed to Hans-Petter, and he has 
already answered it. But regarding your question, I simply don't yet 
know enough about the ATM stack. The only thing I know is that I can get 
raw ATM cells out of and into the USB interface/ADSL line, but I do not 
know how to make this meaningful to the current ATM stack. I probably 
need to do the AAL5 SAR myself, because from looking at the drivers 
(fatm, hatm, etc.) I have the impression that this is something which is 
normally handled by the hardware itself (does the hardware know how to 
handle either AAL0 or AAL5, doing SAR for the latter? And for AAL0, what 
do I get on a socket read/write? - One ore multiple cells? - Same for 
AAL5 - do I get one or may I also get multiple packets?).

I'd also be interested in understanding how I might be able to handle 
signaling information arriving over the ADSL line - I believe this does 
sometime happen.

>
> MB>I do of course read the source, but with the scarce documentation available
> MB>that's a steep learning curve.
>
> You may try to look up the original paper on NATM - its a nice reading as
> far as I remember...
>
> harti
>

Regards,

Martin