Old Status

Description: OpenSS7 old status.

Fri Sep 22 05:37:28 CDT 2000

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.

• 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.

• 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.

Sun Jul 18 22:14:04 CDT 1999

Following is the current status (updated: Sun Jul 18 22:14:04 CDT 1999) on OpenSS7.

At the current date (Sun Jul 18 22:12:35 CDT 1999), OpenSS7 has not yet been kicked off as open source. The only code which exists is the baseline code which I originally developed under GPL. The following is a status of the state of the baseline code.

What's Done:

• SS7 Level 2 ACB56 Driver:-   An MTP Level 2 driver for the ICS ACB56 card exists. This driver is implemented as a loadable module under Linux and has been tested with Linux kernel 2.0.32 and has been conformance tested against Q.781.

• Encoder/Decoder Library:-   An encoder/decoder library exists which provides set of base classes for SS7 encoding and decoding. The library is complete with protocol specificiations for ANSI 1992 for MTP Level 2, MTP Level 3, SCCP, and ISUP. There is no TCAP encoding/decoding yet.

  The library is implemented using a single header file to specify a protocol variant. It will not be difficult to include other variants of SS7 including ITU-T, ETSI, and a number of other national variants such as Italy, Portugal, China, Japan, Austrailia, Bellcore, etc. An example of the header file for ANSI 1992 ISUP is provided here.

  The library provides a set of classes for encoding and decoding and includes test programs. There are methdos for both encoding and decoding frames and displaying frames using normal protocol analyzer type ASCII display.

• State Machines:-   A state machine framework exists for the specification of both protocol layer state machines and subtending state machine modules.

  State machines for MTP Level 2 (although not needed: it is implemented in the driver) and MTP Level 3 exist for ANSI 1992. These state machines have not yet been integrated with the Level 2 driver; however, they are easily adapted.

  The MTP Level 3 state machine requires a wrapper to have it run as a daemon, read configuration files, and open drivers for the ACB56 links.

• RPC Mechanism for MTP Users:-   An RPC mechanism has been coded to permit MTP Users to attach to the MTP level by point code and obtain MTP message streams. This mechanism permits MTP users to be located on machines which are separate from the machines which provide link termination.

To Do:

• Complete MTP Level 3 Daemon:-   The MTP Level 3 state machines need to be packaged into a Linux daemon process which reads a configuration file and opens Level 2 drivers for the ACB56 cards. The MTP Level 3 Daemon also needs to be tested, verified, and conformance tested.

• SCCP:-   The SCCP state machines need to be implemented for connectionless operation (Class 0 and Class 1) using the state machine framework. SCCP state machines need to be implemented as a stand-alone process and an API (similar to the MTP mechanism) defined and implemented.

• TCAP:-   An ASN.1 parser and encoder/decoder mechanism needs to be implemented for TCAP and for use by TCAP application parts. TC state machines need to be implemented using the framework which has already been provided. An API needs to be specified for use by TCAP applications.

• ISUP:-   ISUP encoder/decoders for ANSI 1992 have already been provided in the baseline package. ISUP state machines should be implemented and used as an example framework for the development of ISUP applications.

• More Driver Support:-   The ISC ACB56 driver might not meet the needs of all users of the package. T1 and DS0/DS0A drivers must be investigated and effected. (This might not require writing drivers, but releasing specifications to manufacturers of cards who would be willing to provide a binary driver.)

• Release Control:-   The entire packaged needs to the placed into a configuration directory (the source is CVS'ed now, however, some reorganization and mounting on a CVS server is required).

• Package Documentation:-   The Level 2 driver is well documented. The other components are less documented. Use of the Encoder/Decoders is intuitive and apparent, so not too much documentation is required here.

  Release and loading documentation is required for the whole package.

What's Needed:

• Developers:-   Of course, as many developers as possible to continue development and documentation of the SS7 stack.

• Web hosting:-   I need an organization to volunteer to host OpenSS7 on a web site, and, hopefully, obtain an organizational domain name for the project (such as openss7.org). If you or your orgnization are interested in hosting OpenSS7, please contact me at openss7@openss7.org and check the web-hosting needs list.

• Hardware:-   Organizations or individuals to contribute hardware, especially for driver development (ACB56 cards, T1 cards, V.35 modems, etc.), also for test configurations 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.

• 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.

• 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.