Status
Description: OpenSS7 old status.
The OpenSS7 project is in pre-release pre-alpha stage. What this really means
is that we are still working on the code and it is really not suitable
for public release. What we have done is made the source code available for
those that are interested in following the pre-release development or in
pushing the envelope on our development.
Load this code and mess with it at your own peril. Currently
the code is likely to crash your machine and cause you to have to reboot. You
may irreparably damage your header files and be unable to recompile your
kernel. You may have to reload you system. There is no warranty.
We hope to have an alpha release of the stack which is suitable for public
consumption around November 2000 (yes, that quickly). If you are interested
in becoming a pre-alpha tester and help us stabilize the alpha release, please
drop us a note at [email protected]
and let us know your intentions.
If you would like to contribute to the project,
please read the ``What's Needed,'' below,
subscribe to our mailing list and e-mail us
([email protected]) and let
us know what and how your would like to contribute. If you would just like to
see where we stand on the source code, check the
download page.
A significant departure has been made from the old codebase. (See the design page for detailed information.) Basically,
the items which are marked in green on the
architecture diagram are done, the items marked in blue are in progress,
and the items marked white have not even been touched yet.
- What's Done:
- Sealevel ACB56 SS7 Device Driver:-
An SS7 device driver for the ACB56 card from Sealevel which uses the
SS7 Link Driver Interface and provide a V.35 physical SS7 link. This
is an example driver and is a single-file, 700 odd line driver which
provides all the necessary capabilies expected of the SS7 Link Driver
Interface.
- SS7 Link Driver Interface:-
An MTP Level 2 driver interface as a loadable module which provides a
virtual driver interface which provides Level 2 state machines and
interface to the MTP Level 3 state machines at the socket layer.
Loads as a loadable kernel module and provides AF_SS7 and ETH_P_SS7
packet interfaces.
- SS7 MTP and SCCP Socket Code:-
MTP and SCCP socket interface code which provide users the ability to
open, configure, bind and close an AF_SS7 socket with SS7_PROTO_MTP
and SS7_PROTO_SCCP or SS7_PROTO_RAW protocols.
- SS7 MTP State Machines and Routing Tables:-
MTP state machines interfacing to the MTP socket code on the upper
interface and L2 packets coming from the NET4 packet scheduler on the
bottom interface. Routing table which provides routing for
destination point codes, route sets, routes, link set, and links.
- To Do:
- SS7 SCCP State Machines and Global Title Translations Database:-
Need to put together SCCP state machines per Q.714 for connectionless
operation and support of subsystems. Need a Global Title Translations
SCCP routing tables and configuration support for routing tables.
- `procfs' and `sysctl' Support for SS7 MTP:-
Need to hook in procfs and sysctrl for the control and
configuration of the MTP and SCCP protocol layers.
- `ioctl' Support for SS7 MTP:-
Although the ioctls are there, what is need are the ioctls for adding
and removing destination point codes, route sets, routes, linksets and
links to and from the MTP routing tables. Also need are the ioctls to
set timer values associated with specific MTP point codes.
- SNMP Support:-
Working in SNMP support for both MTP and SCCP.
- Statistics:-
Statistics needs to be cleaned up and made appropriate to standards
(such as Q.752).
- Alarms Subsystem:-
Need to work an alarms subsystem into the Linux kernel for classifying
Critical, Major and Minor alarm conditions and providing appropriate
alarms logs and indications to an operator.
- Some SIGTRAN L2 drivers and L3 interfaces:-
Work in some support for various SIGTRAN stuff.
- What's Needed:
- Developers:-
Of course, as many delvelopers as possible to continue development and
documentation of the SS7 stack and drivers.
- Hardware:-
Organizations or individuals to contribute hardware, especially for
driver development (ACB56 cards, T1 cards, V.35 modems, etc.), also
for test configuration for regressive conformance testing and
certifications.
- Test Gear & Labs:-
Organizations to contribute test gear, laboratory time, testing
personnel for regressive conformance testing and certification of
releases.
- T1 Interface Driver:-
I need two things here: volunteers to write the driver, and an existing
manufacturer and distributor of PC-based T1 interface cards to
contribute technical specifications for driver development to the
project.
- DSO/DSOA Interface Driver:-
Again, I need two things here: volunteers to write the drivers, and an
exsting manufacturer and distributor of PC-based DS0/DS0A interface
cards to contribute technical specifications for driver development to
the project.
- Conformance Testing:-
Access to conformance test gear and conformance testing laboratories
and volunteers to perform the tests.
(Alternatively, I need volunteers to incorporate conformance testing
capabilities into an existing driver so that a Linux box can be used for
conformance testing. Also, I would need someone to write the
conformance test suites.)
- Certification:-
Organizations will to contribute or volunteer to share the costs of
formal certification of major releases of the software in specific
configurations.