Re: [openss7] redundancy

["Brian F. G. Bidulock" <bidulock@openss7.org>]

irma,

The goal of achieving carrier class redundancy and availability
(including hot-swap and other carrier maintainability aspects) in the
OpenSS7 stack has been part of the design goals for OpenSS7 from the
onset.  However, it is difficult to specify a redundancy architecture
without reference to the specific target hardware platforms.

Some SS7 vendors provide active-standby high-availability.  However,
normally this approach is taken from the view of horizontally
partitioning the protocol stack.  In other words, at distinct protocol
levels there is an active processor and one or more standby processors
which perform the same function at a horizontal slice of the protocol
stack (in your example MTP).  This approach can be shown to have several
problems:

    1.) The solution doesn't scale well because the sizing of processors
        along the horizontal slice is dependent upon the overall traffic
        of the system.  The larger the system, the more powerful the
        "active" processor must become.

    2.) The larger or higher capacity the system becomes, the more
        crucial it becomes that fail-over times become decreased or some
        form of atomic synchronization is performed between the active
        and standby processors.  This causes both performance problems
        and scaling problems at the high end.

    3.) The active/standby arrangement normally is not limited to a
        layer of the protocol stack, but must permeate up into the user
        application to remain viable from a systems perspective.

For these reasons and others we normally only see this architecture
taken for signalling end points.  The approach is largely unsuitable for
signalling transfer point implementations.

For signalling transfer points, one sees redundancy solutions for the
Message Transfer Part which slice the protocol stack vertically instead
of horizontally.  That is, each processor is equally capable of
performing all of the MTP processing in a vertical slice (signalling
link management, signalling traffic management, message discrimination
and routing).  Using this approach, with current hardware and processing
power, it is even possible to incorporate entire replicates of the MTP
stack into each of the link processors.

This is the approach that we have taken for the OpenSS7 stack (primarily
because we are interested in supporting full STP capabilities) and it is
reflected in the STREAMS design: this was one of the major reasons for
separating the Signalling Link Set (link and link set functions,
changeover and changeback) from the Message Transfer Part (route and
route set functions, forced and controlled rerouting).  This permits the
traditional Level 2 Signalling Link to be implemented on a processor,
the MTP Level 3 signalling link and link set functions to be partitioned
across processors and MTP Level 3 signalling route and route set
functions to also be partitioned across processors.  This partitioning
is envisioned as the replacement of an internal stream with an
interprocessor communications mechanism.  This first implementation of
this approach is targeted as a Blue Cat embedded system implementation
with hot-swappable cPCI processor cards on an H.110 bus, with both the
PCI bus for interprocessor communication (using something like Blue
Cat's messenger) and dual 100M Ethernet rails or an internal 1G packet
backplane.  All this is done so that OpenSS7 can become something which
can be real in a product.

At the other end of the scale, OpenSS7 fills a role in the lab where one
just wants to set up a little SS7 network and transfer some messages
around during product development or testing without having to buy a
full blown STP or other expensive implementation.  The STREAMS design
also permits the entire stack to be run uniprocessor (or eventually SMP)
on a Linux boxen.

As far as redundancy and availability are concerned at the OpenSS7
application level is concerned, we do not care to impose an
active/standby model on the application.  This was the reason for the
stub ISUP and TCAP layers in the OpenSS7 stack: to provide a mechanism
whereby multiple processes on multiple processors could register with
the stack to receive ISUP and TCAP events, either partitioned
horizontally (active/standby, say for ISUP) or vertically (load shared,
way by ISUP CIC range).  The stubs are intended to communicate to the
MTP and SCCP levels the necessary information to determine the
appropriate action under failure and fail-over scenarios and to invoke
the appropriate user part availability or subsystem availability
procedures where applicable.  Some of the techniques used by M3UA and
SUA in the SIGTRAN working group of the IETF may yield some good general
models here which will permit distribution over Application Servers and
Application Server Processes above MTP and SCCP.  These specifications
provide a model for active/standby as well as load sharing arrangements
which are consistent with MTP and SCCP.  I don't wish to reinvent the
wheel there nor wish to repeat the fine work which is being done in
those working groups.

I suppose the short answer is: yes, OpenSS7 has been designed to support
availability for carrier class applications.  However, the more
immediate tasks are to achieve conformance on the stack because there
are a wider range of applications.  Just as with the rest of the OpenSS7
approach, the intent is to make these issues as transparent to the user
as possible, so that the user of the stack need only worry about
redundancy and availability in their own application and need not worry
about the availability or redundancy models of the underlying stack.

I could include this information in the FAQ, but you are the first to
ask the question, so it is hardly a "frequently" asked question ;)

Let us know if you have any other questions or interest in OpenSS7.

--brian


irma molnar wrote:                            Tue, 06 Feb 2001 15:14:22
> 
> Hi
> 
> The SS7 third party protocol vendors such as Trillium, Hughes are
> selling the SS7 protocol layers MTP-3, SCCP with a HA framework
> enabling to run the protocol modules in an active/standby fashion. So
> that the MTP-3 active is running on one node, while the MTP-3 standby
> is running on a second distinct physical node. I have seen no such HA
> active/standby facilities in openSS7 and I am wondering why. Are the
> target goals different ?
> 
> I have not seen response to this in the FAQ.
> 
> Thank you.
> 
>                              Jean-Marc Fenart
> 
> 

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦