Re: [Sigtran] M3UA default AS

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

Narender,

ngoel@cerberus.intellinet-tech.com wrote:                                            (Mon, 13 Jan 2003 20:50:40)
> On Mon, 13 Jan 2003, Brian F. G. Bidulock wrote:
> Brian,
>  Have to considered protocol error conditions in load sharing model. Do SG 
> need to handle respective error conditiond? Do loadsharing always be 
> specified for entire spectrum of traffic. For example -
> 1. If sccp receives message with return option and ssn is unknown then 
> SCCP is supposed to generate UDTS with reason=unequipped SSN. Does SG 
> generate this UDTS? Or which ASP shall receive this message?

The loadsharing rule is that any ASP in the loadshare AS must be prepared to
receive any message.  A policy at the SG could send these messages round-robin
to ASPs active in the AS or could send them to a particular ASP according to
the loadsharing algorithm.

For M3UA, the ASP generates the UDTS, for SUA and TUA the SG generates the
UDTS.

> 2. Same is the case for TCAP, if it receives a message with invalid TID 
> P-Abort is generated. If TID is not present in load shared TID then does 
> SG generate p-abort?

For SUA the ASP generates the P-Abort, for TUA the SG generates the P-Abort.
For TUA see draft-bidulock-sigtran-tua-01.txt currently on the I-D server.

> Do you recommend load sharing for entire spectrum of traffic or some kind 
> of default behaviour at the SG.

Traffic which matches a load selection can be routed to the ASP currently
responsible for that load selection.  Traffic which does not match any load
selection can be passed to any active ASP in the AS.  The SG could implement
policies that might be of use (round-robin, default ASP) for traffic not
maching a load selection and stil remain completely interoperable and within
the specification.

In particular, in the case of UDTS, a compliant SCCP implementation at any of
the ASPs in the AS will return UDTS properly if sent the offending message.
The same is true for TID if loadsharing on TID is performed.  Any complilant
TCAP implementation on any of the ASPs in the AS will return P-Abort.

The problem with trying to use loadsharing on SSN or TID with M3UA is that the
ASPs in the AS are collectively responsible for all subsystem management.
M3UA should not broadcast SCMG messages.

In fact, this is a problem for MTP Level 3 in M3UA: the specification says
that (a copy of each) SNMM are sent to each active ASP in the AS.

" 4.5.1 At an SGP
" 
"    On receiving an MTP-PAUSE, MTP-RESUME or MTP-STATUS indication
"    primitive from the nodal interworking function at an SGP, the SGP
"    M3UA layer will send a corresponding SS7 Signalling Network
"    Management (SSNM) DUNA, DAVA, SCON, or DUPU message (see Section 3.4)
"    to the M3UA peers at concerned ASPs.  The M3UA layer must fill in
"    various fields of the SSNM messages consistently with the information
"    received in the primitives.
" 
"    The SGP M3UA layer determines the set of concerned ASPs to be
"    informed based on the specific SS7 network for which the primitive
"    indication is relevant. In this way, all ASPs configured to
"    send/receive traffic within a particular network appearance are
"    informed.  If the SGP operates within a single SS7 network
"    appearance, then all ASPs are informed.

(And, of course, SSNM are not sent to ASPs in the ASP-INACTIVE state for an
AS.)

This can have a disasterous effect on ITU-T congestion management at the AS,
if the ASPs were to indicate each SCON received by an ASP to a combined AS
congestion state machine, but there may be cases where an ASP will never
receive one of these SSNM.  Consider the following:


                  SG
             +-----------+                +-----------+
             |           |    Assoc 1     |           |
             |   SGP1    |----------------|   ASP1    |
             |           |\   Assoc 2     |           |
             +-----------+ \___________   +-----------+
                   |                   \
             +-----------+              \ +-----------+
             |           |    Assoc 3    \|           |
             |   SGP2    |----------------|   ASP2    |
             |           |                |           |
             +-----------+                +-----------+


When SGP2 issues a SCON, according to the M3UA spec, it will be sent to APS2
only (because it is only sent to APSs which are active for the AS at the SGP).
So ASP1 does not receive SCON and continues sending traffic at full rate to
SGP1.  When the distant point in the network response with TFC, it might again
appear at SGP2, only informing ASP2 and traffic is not throttled at ASP1.  If
ASP1 is, indeed, responsible for the congestion, part of the SS7 network will
eventually fail with this approach.

Then there is this horrendous situation:

                  SG
             +-----------+                +-----------+
             |           |    Assoc 1     |           |
             |   SGP1    |----------------|   ASP1    |
             |           |                |           |
             +-----------+                +-----------+
                   |                    
             +-----------+                +-----------+
             |           |    Assoc 2     |           |
             |   SGP2    |----------------|   ASP2    |
             |           |                |           |
             +-----------+                +-----------+
                   |                    
             +-----------+                +-----------+
             |           |    Assoc 3     |           |
             |   SGP3    |----------------|   ASP3    |
             |           |                |           |
             +-----------+                +-----------+
                   |                    
             +-----------+                +-----------+
             |           |    Assoc 4     |           |
             |   SGP4    |----------------|   ASP4    |
             |           |                |           |
             +-----------+                +-----------+

In the case above, only one ASP will ever receive an SSNM message under the
curent rule (because the SGP determines the concerned ASPs, not the SG).

If the requirement were that the "SG" (instead of SGP) sends a copy to each
ASP, then the SG would need a way to identify which ASP was which to avoid
sending a given ASP multiple copies (and breaking ITU-T congestion algoritms
at the MTP-User).  It might be possible to use ASP Id (or its equivalent in
terms of the transport addresses of the connecting ASPs) to accomplish this
under normal operating conditions.

So it appears that even getting SSNM messages correct give the M3UA SG some
grief.  How do you ever expect it to get SCCP or TCAP management correct?

M3UA terminates and handles signalling-route-set-test and signalling-route-
set-congestion-test messages at the SG and maintains the signalling point and
user state at the SG to respond to these messages.  The ASP never sees these
messages.  This avoids having to figure out which ASP is going to respond to
the test.  But for SCMG and in particular subsystem-test messages (SST), the
M3UA SG cannot handle responding to the messages itself.  Using the
loadsharing rule, the M3UA SG could send a single copy of the SST to any one
of the ASPs active in the AS for DPC/SI=SCCP, and that ASP would be
responsible for the response.  SCCP congestion messages (as well as SSP,SSA)
would still need to be broadcast to ASPs on an SG-wide basis as with SCON
above.  But this broadcast within an load-share AS is not within the rules for
load-share AS in the M3UA specification.  M3UA addresses SSNM separate from
DATA to handle this, but SCCP management messages are just DATA and are only
sent to one ASP in a load-share AS, not all of them on an SG-wide restricted
basis.

Rather than try to overload all of this into M3UA, it is still better to use
SUA.  SUA includes all of these considerations by placing a standards
compliant SCCP at the SG.

TCAP gets even more interesting, because TCAP management is not even specified
in the scope of the TCAP protocol (other than echoing through SCCP
management).  It is at the discretion  of the application to implement
whatever management is necessary.  So, for example, IN/AIN uses ACG (automatic
code gapping) parameters in TCAP transaction to throttle transaction rates.
Ensuring that ACG gets to the correct ASP(s) in loadshare AS at the M3UA level
would require large chunks of SCCP and TCAP state machines.  It is simpler to
address TCAP with SUA (or better still TUA).

Error situations such as you mention are simple compared to management
messages.

Now, if you are stuck using M3UA (because some foolish people specified it
for, say, 3GPP, and at draft level 7, which should never have been referenced)
then you can still use SUA _between_ ASPs (or some other state sharing or
message passing) to redistribute traffic at the AS as you had mentioned in
your previous note.  In that case, loadsharing on SLS is the wisest thing to
do to equally distribute the load within the AS.  Then the ASP itself is
responsible for distributing copies of SSP, etc., to its brethren, and the
exercise at the ASP is a simple one of building a distributed SCCP
implementation.

Wel, I could go on... ;)

--brian

> -Narender
>  
> > Joseph,
> > 
> > Load sharing follows the rule that any ASP in the AS must be prepared to
> > receive any message for that AS.  Routing does not follow (and cannot be
> > made to follow) this rule.  draft-bidulock-sigtran-loadsel-01.txt
> > follows this precept as well.
> > 
> > That's why RK is so problematic at CIC granularity, whereas loadsharing
> > on CIC is not.  The SG can try to get the message to the correct place
> > in loadsharing, and failing a match on a load selection, can distribute
> > message over the ASPs in the AS using some other rule (round-robin,
> > default, etc.), or can loadshare based on Message Type (such as
> > distributing CGB differently than IAM, and IAM differently than other
> > call processing messages), but the ASPs must be designed to handle
> > messages outside of their load selection (but still within the Routing
> > Key/Application Server/Routing Context).  So, if the message goes
> > astray within the AS (i.e. is sent to any ASP instead of particular
> > ASPs) it is the responsibility of the ASP to treat the message in the
> > context of the MTP-User and not the SG's responsibility.
> > 
> > Also, loadsharing does not change the scope of the AS which remains as
> > an SEP or MTP-User, permitting the SG to reflect AS state to the SS7
> > network as SEP or MTP-User state.
> > 
> > Perhaps the reason that you don't see the difference is because you were
> > thinking that Routing Keys were useful for load distribution.  They are
> > not.
> > 
> > Routing includes the concept of management of a route and reflection of
> > the state of a route (RK:AS:RC) to the SS7 network.  By definition it
> > should be no more granular than SSNM permits.
> > 
> > Loadsharing is splitting the offered traffic load within an Application
> > Server over multiple ASPs that clients of the SG within that Application
> > Server.  By definition it must be more granular than the Application
> > Server/Routing Key/Routing Context.  Loadsharing for M3UA must preserve
> > ordering, so all loadsharing algorithms must not split traffic across
> > multiple streams or multiple ASPs to avoid re-ordering.  Loadsharing
> > must therefore be performed on SLS or a parameter which is invariant
> > with respect to SLS (e.g. CIC, DLR/SLR, TID).
> > 
> > Does that clarify it better?
> > 
> > --brian
> > 
> > On Mon, 13 Jan 2003, Wung, Joseph wrote:
> > 
> > > Brain,
> > > 
> > > I'm reading your LOADSEL, but can't distinguish loading
> > > sharing from routing.  It seems to me that the loadsharing
> > > is just another layer of routing using finer granularity.
> > > Can you help here?
> > > 
> > > Joe
> > > 
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org]
> > > > Sent: Thursday, January 09, 2003 8:56 PM
> > > > To: Wung, Joseph
> > > > Cc: 'sigtran@ietf.org'
> > > > Subject: Re: [Sigtran] M3UA default AS
> > > > 
> > > > 
> > > > Joseph,
> > > > 
> > > > Don't try to use CIC routing for this: use CIC load-sharing.
> > > > Then the SG knows that it can send CIC=100 to any of the ASPs in
> > > > the load-share AS.  If you need to have controlled load-sharing
> > > > consider:
> > > > 
> > > > 	draft-bidulock-sigtran-loadsel-01.txt and
> > > > 	draft-bidulock-sigtran-loadgrp-01.txt
> > > > 
> > > > that I have just submitted to the I-D drafts editor.
> > > > 
> > > > Until they are available on the I-D server, you will find a copy
> > > > here:
> > > > 
> > > > 	http://www.openss7.org/sigtran01.html
> > > > 
> > > > --brian
> > > > 
> > > > Wung, Joseph wrote:                                           
> > > >                        (Thu, 09 Jan 2003 19:02:49)
> > > > > M3UA section 1.4.2.4 says
> > > > > 
> > > > > 	"When there is no matching Routing Key entry for an
> > > > > 	incoming SS7 message, a default treatment MAY be
> > > > > 	specified.  Possible solutions are to provide a default
> > > > > 	AS at the SGP that directs all unallocated traffic to a
> > > > > 	(set of) default ASP(s), or to drop the message and
> > > > > 	provide a notification to layer management."
> > > > > 
> > > > > I have, say, 3 ASPs:
> > > > > 	ASP-1 for OPC/DPC/CIC=1-24
> > > > > 	ASP-2 for OPC/DPC/CIC=25-48
> > > > > 	ASP-3 for OPC/DPC/CIC=49-72,
> > > > > 	where OPC/DPC are the same.
> > > > > 
> > > > > How would the SGP route an incoming message with OPC/DPC/CIC=100.
> > > > > My question is since the default AS is not registered, thus no
> > > > > associated traffic mode, how does the SGP know the received 
> > > > > message should be broadcast to all 3 of the ASPs or select one 
> > > > > of them to send to?
> > > > > 
> > > > > Joe
> > > > > _______________________________________________
> > > > > Sigtran mailing list
> > > > > Sigtran@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > 
> > > > -- 
> > > > Brian F. G. Bidulock
> > > > bidulock@openss7.org
> > > > http://www.openss7.org/
> > > > 
> > 
> > 

-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran