[RFC] proposal for new library: libosmo-net

[Harald Welte]

Hi Pablo,

On Thu, Sep 29, 2011 at 02:33:28PM +0200, Pablo Neira Ayuso wrote:
> In order to re-use the existing networking interfaces in any GSM
> interface, I'm thinking about extracting some code from the e1input
> infrastructure and provide some generic API to create, destroy, write
> and read data, something like:
> 
> #define OSMO_NETIF_T_NONE       0
> #define OSMO_NETIF_T_DAHDI      1
> #define OSMO_NETIF_T_MSISDN     2
> #define OSMO_NETIF_T_IPA        3
> #define OSMO_NETIF_T_RS232      4
> #define OSMO_NETIF_T_WHATSOEVER 5
> 
> struct osmo_netif *osmo_netif_open(int type, ...);

I think this should probably be a _reconfig() function, i.e. something
that can process incremental changes to the configuration.   It is very
likely that the BSC process runs for a long time, and the E1 timeslot
configuration / or other signallign configuration changes during
runtime.  So an initial "open" is not really sufficient.

The _reconfig() calls could be triggered every time we "exit" from the
VTY node that configures the like or signalling-link.

I also think that the _open() / _reconfig() call could be device type
specific, i.e. something like

struct osmo_netif *osmo_netif_open_dahdi(...);
struct osmo_netif *osmo_netif_open_ipa(...);
...

as the parameters will probably be _very_ device type specific, it might
not make sense to put all of it in one large union of structures.

Also, I expect almost all users to use VTY for configuration, so we
should have library-internal VTY support where we could have something
like this for the VTY parsing inside the library:

% a real circuit A-bis line on E1 (BS-11, Ericsson RBS, ..)
line AbisLine0
 description Foobar
 driver dahdi
 [driver-specific parameters]

% a real circuit A line on E1
line ALine0
 description ...
 driver misdn
 [driver-specific parameters]

% a virtual A line over IPA
line Aline1
 description ...
 driver ipa-client
 ipa-client remote-ip A.B.C.D
 ipa-client remote-port <0-65535>
 ipa-client unit-id 1234 0
 ipa-client authot-ken AbCdEf

% a virtual A-bis line with IPA protocol like nanoBTS
line AbisSrvOML0
 description Foobaz
 driver ipa-server
 ipa-client local-ip A.B.C.D
 ipa-client local-port 3003

% a virtual A-bis line with IPA protocol like nanoBTS
line AbisSrvRSL0
 description Foobaz
 driver ipa-server
 ipa-client local-ip A.B.C.D
 ipa-client local-port 3002

signalling-link ALine0/0
 description MyMscLink
 timeslot 1 sub-slot full
 encapsulation mtp
 [mtp-specific parameters]

signalling-link AbisLine1/0
 description MyBtsLink
 e1_timeslot 1 sub-slot full
 encapsulation lapd


and then something like this (for the BSC):

bsc
 a-interface signalling-link ALine0/0

% A BS-11
bts 0
 oml tei 25
 oml signalling-link Line1/0
 trx 0
  rsl tei 0
  rsl signalling-link Line1/0

% an ip.access nanoBTS
bts 1
 oml tei 255	% IPA stream ID
 oml line AbisSrvOML0
 oml ipa unit-id 1800 0
 trx 0
  rsl tei 0 	% IPA stream ID
  rsl line AbisSrvRSL0
  rsl ipa unit-id 1800 0

> 1) Rip code from libosmo-abis (input drivers) to implement this new
>    API in libosmo-netif.
> 2) Port openbsc to use this new API in the A interface.
> 3) Finally, put libosmo-abis into libosmo-netif. After that, we can
>    consider libosmo-abis obsolete.

I think the existing libosmo-abis API might very well disappear, OpenBSC
should use the netif library directly even for Abis

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)