OpenSS7 |
© 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. |
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
Figure 2, below, illustrates the new design approach to the OpenSS7
stack. Device drivers are created with the pseudo-ARP hardware type of
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.
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.
More information will be coming shortly for this section...
OpenSS7 © Copyright 2000, Brian F. G. Bidulock, All Rights Reserved. Last modified: $Date: 2000/10/04 03:52:24 $create
method
for creating a socket of an address family, in our case AF_SS7).
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
Figure 3 - SS7 MTP Routing Tables
Figure 4 - SS7 MTP Route Sets