[Linux-ATM-General] SAp - OAM Cell Handling in ATM-Device Driver

[Russell M. <rmc...@vi...>]

o follow up a little more on my own post, The hardware we are using is
pretty 'dumb' when it comes to ATM, I think it is a safe bet to say that no
HW handling of the OAM messages is being done.

This brings several questions for both transmitting and receiving OAM cells.

1) Since the HW is 'dumb' does the atmsigd have enough smarts to properly
format all outgoing AAL5 packets such that the HW can be OAM stupid, and
switches should respond accordingly.

2) Assuming 1 is correct, on the RX path, does the atmsigd have enough
smarts to reply / loopback, etc... to OAM messages when they are passed up?
Or is it a requirement that drivers for ignorant hardware handle most of
this and only pass up non-OAM messages on the normal 0.5 SAAL connection?

At the moment, for a test, I have the driver to dumbly pass up all PTI=4 OAM
cells to the 0.5 channel. Using saaldump I get a lot of invalid sizes
reported. Using 'strace atmsigd -u uni31' I will get several good seconds of
running, but eventually it causes a segmentation fault, though this may not
be directly related. 'aread 0.5' is equally happy without atmsigd and will
continuously dump out 48 byte payloads.

I know the long route through this is to read the UNI31 spec, and try to
understand the complete signaling for setting up and tearing down a call,
but I was really hoping to avoid trying to understand all the physics just
so I can bounce a ball, so to speak.

-Russ

> -----Original Message-----
> From: Russell McGuire [mailto:rmc...@vi...]
> Sent: Thursday, March 08, 2007 1:49 AM
> To: 'lin...@li...'
> Subject: SAp - OAM Cell Handling in ATM-Device Driver
> 
> I was curious if anyone could shed more light on how a device driver
> should handle certain packets.
> 
> We are in progress in creating a new driver for a ATM T1 card and are a
> bit confused on how to handle the packets coming back from a ATM-T1 switch
> after we initiate the atmsigd.
> 
> i.e. we are getting the packets, and it would appear that they are OAM P2P
> cells. Should these be passed up like:
> 
> 1) AAL0 cell to the stack using standard vcc->push(*<53 byte pointer>)
> 2) AAL0 cell to the stack using standard vcc->push(*<48 byte pointer>)
> 3) Using vcc->push_oam(*cell) 52 bytes?
> 4) Perhaps just passing them as a single cell AAL5 48 byte skb vcc-
> >push(*48 byte skb).
> 5) Drop them entirely?
> 
> I haven't read a ton on the UNI spec, but then again it doesn't cover
> linux4atm. OAM cells are always single cells right? And thus we ignore the
> PDU size field?
> 
> Part of this is confusing me, since I am working with a vendor and each of
> us has different understanding of how to handle this. To many cooks in the
> kitchen so to speak.
> 
> Our goal is simply to make the atmsigd happy, the switch happy, and allow
> the normal SVC stuff to work afterwards.
>