Motivation for ASPTM for congestion

Brian,


Some text about why we want to have ASPTM for congestion is below.

   Thanks,
   Tolga




M3UA and SUA protocols allow to split SS7 application
traffic into separate pieces by utilizing the concept
of Route Keys, where traffic belonging to each Route
Key can be served by multiple M3UA entities, i.e.
multiple ASPs. The concept of RKs and utilizing
multiple ASPs allows a flexible message distribution
architecture. On the other hand this distributed
architecture brings the need to aggregate status of
SS7 entities, e.g. PCs, user parts, subsystems, at SGs, so that a unique
view can be
presented to the rest of the SS7 network. Availability
status of distributed SS7 entities is aggregated based
on ASPTM and SCTP association state on SGs. In
addition to availability, congestion status of an ASP
is also important to determine the aggregated
congestion status of a distributed SS7 entity and to
distribute messages accordingly to ASPs for SGs, which
want to do so.

Current M3UA specification relies on SCTP congestion
indications to detect congestion status of ASPs. This
has certain drawbacks as listed below:

a) A typical implementation utilizes multiple queues
between an application and SCTP layer on an ASP.
Shrinking of rwnd on peer SCTP to a level where it
prevents message transfer will happen only after
application layer congestion propogates to local SCTP
after the queues between application and SCTP are
filled up with messages to certain threshold values.

       ASP                        SGP
+------------------+       +-------------------+
|   +------------+ |       |                   |
|   |Application | |       |                   |
|   +---+---+----+ |       |                   |
|       | - |      |       |                   |
|       | - |<-----+---+   |                   |
|       | - |      |   |   |                   |
|   +---+---+----+ |   |   |                   |
|   |   M3UA     | |   |   |                   |
|   +---+---+----+ |   |   |                   |
|       | - |      |   |   |                   |
|       | - |<-----+---+   |                   |
|       ||- |      |   |   |    SCTP    rwnd   |
|   +---+---+----+ |   |   | +---------------+ |
|   |   SCTP     | |   +---+>| | | | | | | | | |
|   +------------+ |   |   | +---------------+ |
+------------------+   |   +-------------------+
                       |
                   Queues on which
                   ASP congestion needs
                   to propogate


b) An ASP may serve multiple AS and only one of them
may get congested, e.g. due to a slow data-base
access. Relying on SCTP association congestion would
cause SCTP association to get congested for traffic
for all AS served by ASP.

c) M3UA logic of ASP and application logic could
reside on different blades/CPU cards adding another
layer of communication between SCTP and application
logic, delaying propogation of congestion further.

d) Congestion of SCTP association effects all M3UA
messages regardless of their importance, e.g.
management messages are blocked by congestion as well.

Because of the facors listed above, there is a need to
communicate congestion information of ASPs in the
context of an AS to SGPs. Considering that this is
simialar to ASP being ACTIVE/INACTIVE for an AS, this
can be best accomplished with a new ASPTM serving that purpose.