#
## SAR Library  (C) 2000, Johan Verrept (Johan.Verrept@advalvas.be)
#

For updates, check the linux-atm mailing list or mail me.
The updates will be very infrequent because I don't have much time.
Any remarks, patches and bug fixes are welcome.

WARNING: This is experimental software. Use at your own risk.

License
=======

This code falls under the GNU Public License, see COPYING
If you want to use this in a commercial product, contact me.

Usage & requirements
====================

Usage: Just link this library to your driver/module/kernel.
Requirements:
	This needs the Linux ATM stuff, but can be easily ported to
	any platform.

API
===

The API to the SARLib is simple. At least, I tried to make it as simple as I
could.  I alsi tried to map it to the ATM Linux API as much as I could.

There is a sarlib_open() function which will initialize the sarlib_vcc
structure with the provided parameters. The sarlib_close() function frees
this all.
the sarlib_open() function is passed in a type, all the header parts, a
pointer to the Linux ATM vcc, a pointer to a list of sarlib_vcc's and a
flags field.
there are 2 flags available now:
	SARLIB_USE_53BYTE_CELL  will force sarlib_encode_rawcell() to produce
53 byte cell in stead of the linux 52 byte cells.
	SARLIB_SET_PTI          this will cause the pti bit of the last cell
int the provided buffer to be set ( by sarlib_encode_rawcell())

Real SARing happens in the sarlib_encode_xxx() and sarlib_decode_xxx()
functions. Everything is straight forward for the encoding of the data,
althought there are a few assumptions.

sarlib_encode_rawcell assumes it gets a multiple of 48 bytes.
	if SARLIB_SET_PTI is set, it assumes a full aal5 pdu is supplied.
	It does NOT calculate the cell header CRC at the moment.

sarlib_encode_aal5    assumes it gets a full aal5 pdu.

The decode functions have no assumptions. Both decode functions need to be 
repeated until they return NULL.  

sarlib_decode_rawcell() requires a LIST of sarlib_vcc's. This allows the user 
to pass in any cells they received, sarlib_decode_rawcell() will drop the 
ones it doesn't know, the others are copied into the relevant sarlib_vcc 
reassembly buffer.  Depending on the type of reassemly (only AAL5 at the
moment) it will return a pointer to that buffer when a complete AAL5 pdu 
has been received. The third argument will contains a pointer the relevant 
sarlib_vcc.  You must repeat the call with the same arguments after
processing the buffer, to allow sarlib_decode_rawcell() to process the
remaining cells in the receive skb. It does NOT check the cell header crc.

sarlib_decode_aal5() requires a complete AAL5 packet to process.
This will do aal5 length and crc checking.  There is some intelligence in
there that will try to recover from an illegal length.  It will take the
length from the trailer and check whether the crc over this part is valid.
This allows the SARLib to only drop 1 AAL5 pdu when the last cell of a pdu
is lost. ( otherwise it would have to drop both...)

There is also a sarlib_alloc_tx function now.  It is supposed to be called
with a sarlib_vcc structure instead of a atm_vcc, I had to do this because I
had no way of getting to the sarlib_vcc structure from the atm_vcc
structure... the user program will have to wrap the sarlib_vcc function.
BE CAREFULL!!  the sarlib_open function will copy the alloc_tx pointer from
the atm_vcc and call it!  You cannot set the alloc_tx function in the vcc 
BEFORE passing it to sarlib_open!! You will have to do it afterwards...

Acknowledgements
================

Thanks to :

- Whoever wrote the CRC routines in linux/drivers/net/wan/sbni.c
