Linux Native 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

Linux Native Design (Deprecated)

Description: OpenSS7 Linux Kernel Design (Deprecated).