Linux Kernel Design (Deprecated)

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