OpenSS7: The Grand Re-Design

OpenSS7 | Brian F. G. Bidulock, © Copyright 2000, Brian F. G. Bidulock, All Rights Reserved.
All OpenSS7 website, www.openss7.org resources have provided as a courtesy of the OpenSwitch Project and Herlein Engineering.

# The Grand Re-Design

There comes a time in the life-cycle of every project when it is time for a re-design. The OpenSS7 stack started with a character device based driver for the ACB56 card performing the functions of MTP Level 2. It was envisioned that MTP L3 would run as a daemon and would read and write SUs to and from the character device which provided the SS7 Link interface.

That approach turned out not as nice as making the SS7 L2 drivers, link layer network drivers under the Linux kernel and the SS7 L3 (MTP) and SS7 L4 (SCCP) protocol layers underneath a socket layer providing socket abstraction access to MTP and SCCP. The resources of the Linux NET4 package can then be brought to bear on the solution.

The Linux NET4 package is far from simple, as is illustrated in Figure 1, below.

Packets run through queues in the packet scheduler accoding to a queueing discipline on the way out and are moved from the `backlog` queue to the protocol layer whenever the network bottom-half (`net_bh`) runs. `dev_queue_xmit` uses the device driver's `struct device` struct point in an `sk_buff` to determine which device driver to deliver packets to. `net_bh` uses the packet type in the `sk_buff` (in our case `ETH_P_SS7` to determine which protocol layer to deliver the packet to. Protocol layers can be registered and unregistered and can receive significant events (device up, down, failed) from device which register as network devices against the `pkt_type`.

Figure 1 - Linux NET4 Packet Handling

Although it is quite complex, the Linux packet scheduler and NET4 bottom halves do most of the work involved with queueing and marshalling packets between drivers and protocols. Also, many of the socket layer abstractions are supported and may be registered (such as the `create` method for creating a socket of an address family, in our case `AF_SS7).`

Figure 2, below, illustrates the new design approach to the OpenSS7 stack. Device drivers are created with the pseudo-ARP hardware type of `ARPHRD_SS7` and have a private device `struct ss7_iface` which contains most of the common SS7 Link private stuff. There is also a `struct ss7_link` structure per link interface which couples into the routing tables for SS7 MTP. Packets are exchanged with the SS7 MTP protocol as `ETH_P_SS7` packets. The SS7 MTP protocol layer represented by the protocol control block `ss7mtp_cb` exchanges packets with open and bound sockets with the protocol family `PF_SS7` and the address family `AF_SS7`.

Figure 2 - Overall OpenSS7 Architecture

To make an analogy, MTP is very much like IP a this level, and SCCP is very much like UDP. SCCP is a protocol layer stacked on top of MTP which has its own socket interface. This approach provides the capability of supporting all manner of SS7 over IP interfaces which may interface within the kernel at the socket level.

Figure 2 also indicates the current status of development. The boxes indicated in green have completed code. The boxes in blue are a work in progress, and the white boxes have not been touched yet. Final work on the OpenSS7 stack (completion of the necessary white boxes) should occur by about November, 2000.

The basic structure of the SS7 MTP routing tables are illustrated below in Figure 3 and the overall objectives of SS7 MTP routing is illustrated in Figure 4.

Figure 3 - SS7 MTP Routing Tables

The MTP routing tables are treated analogously to IP routing tables in that similar tools (ioctl access, directy routing socket access) are provided for the manipulation of SS7 destination addresses, route sets, routes, linksets and links.

Figure 4 - SS7 MTP Route Sets

More information will be coming shortly for this section...

OpenSS7 | Brian F. G. Bidulock, © Copyright 2000, Brian F. G. Bidulock, All Rights Reserved. Last modified: $Date: 2000/10/04 03:52:24 $