Re: RFC 4666 M3UA - Reg Request Message

Ilie,

Ilie Glib wrote:                           (Tue, 07 Nov 2006 20:47:53)
> Brian,
> 
> Please can you give an ISUP related example where LOADSEL draft does
> better than RKs with CICs.
> 
> Thank you in advance
> 
> /Ilie

The difficulty with routing verses load sharing is that with routing, for each
CIC range, you need a different RK/RC/AS and all of the difficulties that
entails.

Consider the following example:

ANSI 32k CICs broken into 24 channel circuit management groups for a total of
1366 CIC ranges between two point codes (PCA (local) and PCB (remote)).

OLD RFC Routing Keys would look like:

RK0001: DPC=PCA OPC=PCB TM=OVERRIDE CIC=00000-00023 => RC0001
RK0002: DPC=PCA OPC=PCB TM=OVERRIDE CIC=00024-00047 => RC0002
RK0003: DPC=PCA OPC=PCB TM=OVERRIDE CIC=00048-00071 => RC0003
...
RK1365: DPC=PCA OPC=PCB TM=OVERRIDE CIC=32736-32759 => RC1365
RK1366: DPC=PCA OPC=PCB TM=OVERRIDE CIC=32760-32768 => RC1366

The size of a single registration request message necessary to register all of
these keys at once would be:

 8 (msg hdr) + 1366 * ( 4 (rk phdr) + 8 (rk id) + 8 (tmode) + 8 (dpc) + 8 (opc
 list) + 12 (cic range) ) = 65576 bytes

The successful response would contain 1366 results with 1366 RC values.

Also, because the registering ASP is not ASP Inactive in 1366 separate AS,
each with an independent state,  1366 Notify(AS-INACTIVE) messages need to be
sent to each ASP when it registers.

LOADSEL Load Keys would look like:

LK0001: CIC=00000-00023 => LS0001
LK0002: CIC=00024-00047 => LS0002
LK0003: CIC=00048-00071 => LS0003
...
LK1365: CIC=32736-32759 => LS1365
LK1366: CIC=32760-32768 => LS1365

The size of a single registration request message necessary to register
all of these load keys would be:

 8 (msg hdr) + 4 (rk phdr) + 8 (rk id) + 8 (tmode) + 8 (dpc) + 8 (opc list) +
 1366 * ( 4 (ls phdr) + 12 (cic range) ) = 21900 bytes

The successful response would contain 1 result with 1 RC value and 1366 LS
values.

When each ASP registers, one Notify(AS-INACTIVE) is sent for the entire AS.

Now, assume that ASP1 activates for half of the RC values and ASP2 activates
for the other half (exactly which half is not important) in the RK case, and
ASP1 activates for half of the LS values and ASP2 the other half in the
LOADSEL case.  Each ASP is the standby for the half for which it is not
active.

In the RK case, when ASP1 activates, 683 AS transition from the AS-INACTIVE
state to the AS-ACTIVE state requiring sending 683 Notify(AS-ACTIVE) messages
to ASP1 and 683 Notify(AS-ACTIVE) messages to ASP2.  Again in the RK case,
when ASP2 activates, the other 683 AS transition from AS-INACTIVE to AS-ACTIVE
requiring sending 683 Notify(AS-ACTIVE) messages to ASP1 and 683
Notify(AS-ACTIVE) message to ASP2.

In the LOADSEL case, when ASP1 activates 1 AS transition occurs and 1
Notify(AS-ACTIVE) is sent to ASP1 and another to ASP2.  When ASP2 activates, 1
AS transition occurs and 1 Notify(AS-ACTIVE) is sent to ASP1 and another to
ASP2.

Now, assume that in comes time to send an SNMM for PCB (SCON[1] for example).

In the RK case, the SG will need to send 683 SCON[1] messages (one for each RC
value) to ASP1 and 638 SCON[1] messages (one for each RC value) to ASP2.

In the LOADSEL case, the SG sends one SCON[1] message to each of ASP1 and ASP2
(the same message twice rather than two messages).

Now, assume that ASP2 fails.  In the RK case, 683 AS's transition to the
AS-PENDING state (with 683 pending timers set) and the SG MUST send 683
Notify(AS-PENDING) messages to ASP1.  As the timers fire, 683
Notify(AS-INACTIVE) messages are sent to ASP1. In the LOADSEL case, 683 load
groups transition to AS-PENDING and the SG sends 1 Notify(AS-PENDING) with 683
load selectors in it, one timer can be set.  When the timer expires 1
Notify(AS-INACTIVE) message can be sent to ASP1.

I could go on, but I think that anyone can see from this example that fudging
the RK to include CIC range is an abuse of the AS mechanism that simply does
not scale, and requires that the SG juggle many more states and timers than
the better suited LOADSEL procedures.

When the mapping between AS and manageable SS7 MTP entities (Point Codes, User
Parts) is direct, a more workable approach to SS7 management of the SPMC
results.  Splitting a manageable SS7 MTP entity (ISUP User Part) into hundreds
or thousands of AS requires the SG to juggle (and notify for, and return
status for) all the independent parts that is simply not necessary with
LOADSEL.  LOADSEL allow the AS to represent the ISUP User Part and provides a
more apt management of Load Selections within that AS used only for message
distribution and communications concerning message distribution, with ASPs.

I hope that answers your question.

--brian

-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/