OAMs

[Giampaolo Tomassoni]

> -----Original Message-----
> From: Stanislaw Gruszka [mailto:stf_xl at wp.pl]
> Sent: Saturday, March 08, 2008 12:25 PM
> 
> On Friday 07 March 2008, Giampaolo Tomassoni wrote:
> > Dears,
> >
> > during the last days I experienced a lot of ADSL resynchs due to OAM
> > LoopBack Request not being replied by the usbatm driver of my
> SpeedTouch.
> >
> > Thereby, I attempted to develop a patch to the usbatm code purposed
> to
> > implement a minimal OAM LB Reply functionality. I of course attach a
> copy of
> > this patch as a unified diff against the stock 2.6.24 kernel.
> 
> Is usbatm proper place for OAM processing? There are some messages on
> this topic on mailing list archives, but without any conclusion.  Maybe
> worth
> to ask again on linux-ATM-general ML how to design OAM support for
> usbatm.

The problem here is that the linux-atm stack misses a SAR layer. This is
because most of the ATM cards among the "classical" ATM interfaces in Linux
already handle a SAR layer (and someone even QoS parameters).

In the "other" class of the ATM interfaces in linux the USB-connected ones
are the most notable, mostly because of their spread use and ease of
availability.

Some time ago I developed a sarlib module for linux which implemented a
further layer between the ATM stack and the interface. The driver of the
latter could eventually use the sarlib layer in order to do AAL processing
(at the age it shipped with an implementation of the so-called AAL0 -the
"raw" one- and AAL5. It didn't borrow any OAM processing, but I believe that
the sarlib is the best way in which it should go. I'm speaking of the
end-to-end OAMs, not the x-to-segment ones, of course.

Nevertheless, there was a bit of resilience in the acceptance of the "yet
another ATM layer" by the kernel community and I wasn't able to involve the
usbatm one in that (of course, even in the sarlib case the usbatm module is
the main target).


> Another basic quesion is if such support is really needed.

My own thinking about this is "yes, definitely". When using Classical-IP
over ATM, in example, the node at the CPE side may even not have a specific
address (it is a PtP connection) and the provider often finds OAM LB
Requests a useful way in order to inspect the state of the connection. If
the CPE doesn't reply to their requests, the result is often a link resynch,
which I believe must be avoided at the most possible extent.

Other solutions like, in example, extracting OAMs, delivering them to an
external module and re-injecting the replies in the channel's outbound
traffic, doesn't seem an effective solution to me with respect to the
current state-of-the-art of the atm stack. It would basically mean
developing a SAR-processing module anyway...

Why not "put a patch" soon and think to a better design later? The USBATM
module would be involved in the redesign anyway...


> Cheers
> Stanislaw Gruszka

Cheers,

Giampaolo