RE: RFC 4666 M3UA - Reg Request Message

Brian,

Thanks for taking time and detailing an example. Please see comments inline.

In a short summary of my comments: Since LS is not related to AS states where as RC (one to one mapping to AS) is, introducing LS will indeed save us from AS transition and other notification in large systems.

-Jitin

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Wednesday, November 08, 2006 1:20 AM
To: Ilie Glib
Cc: [email protected]; Haresign Lincoln
Subject: Re: [Sigtran] 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.


>>>>>>>>>>>>>>>>>> MY COMMENT

As per RFC-3332, I see following structure of Reg Req in single message:

RK-1   DPC=PCA TM=OVERRIDE (CIC RANGE LIST PARAMETER) OPC=PCB CIC=00000-32768 => RC-1

Correct me if I understood wrong.

Though, I never said that adopt CIC ranges list parameter exactly as they were in RFC-3332. Note that RFC 4666 did a better job in incorporating Routing Context in the Registration request message so as existing keys can be modified.

So if we put the Circuit Range in Routing Key (defined in RFC 4666), this is how it looks for a single Registration Request message (as so I assume from single ASP):

The following example assumes following modification to RFC-4666:

1. Introduction of only CIC Range (note excludes OPC as defined in RFC-3332).

(Note that you placed the Multiplier at wrong side, even if you have CIC RANGE LIST (which contains OPC and CIC Range in list format) parameter as defined in RFC-3666 for a single Reg Req message from single ASP. Correct me if I understood in-correctly)

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

Here I see we saved (1366 * 4) = 5464 Bytes.

Also, I disagree with 1366 results and 1366 RC values. This all can be represented by Single RC and Single Result when such registration is sent by single ASP even with RFC-3332(I assume that you mentioned single message so has to be from single ASP). 

Note that with RFC-4666, no matter if you send this request with one message or at multiple times (as you can include RC), you will still end up with only Single RC value as you can modify the previous Routing Key associated with any RC as per RFC 4666.

Between multiple ASPs, model will follow as per THM value. 
>>>>>>>>>>>>>>>>>>> End of Comment - 1

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.


>>>>>>>>>>>> My COMMENT:
I disagree. In the above example, since we talked of single Message from single ASP, this RK can represent single AS even as per RFC-3332

1366 AS are not required as the above key can be represented by Single RC and hence Single AS.

If we had multiple ASPs (upto 1366) with each one sending such CIC range, we would have surely ended up with 1366 RCs.
>>>>>>>>>>>>>>>>> End of Comment



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.
>>>>>>>>>>>>>>>>>>>>>> My COMMENT:
So, now here SG has to manage 1366 LS (another Index). 

In a scenario with my above modification to RFC where the above Routing Key is sent by different ASPs(1366) with different (unique) CIC range, we will end up with 1366 Routing Context which is same as 1366 LS at SG.
>>>>>>>>>>>>>>>> End of Comment

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.

>>>>>>>>>>>>>> MY COMMENT
I Agree. Since 1366 LS are not linked with AS states where RCs would be, we would have to send Notify's to other member(s) of the same AS. But for the above example, we will have only Two Routing Context as per above modification to RFC-4666.  Again, I agree if we had 1366 ASPs registering each such CIC range, we would have so many RCs and AS. However, RK can be modified as per RFC-4666 and hence we can just keep on adding CIC ranges we if have only two ASPs as in the scenario cited above by you.
>>>>>>>>>>>>>>>>> End of comment.

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.


>>>>>>>>>>>>>> MY COMMENT
I Agree. LS logic since unrelated to AS state could save us from AS State Transitions
>>>>>>>>>>>>>>>>

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/

_______________________________________________
Sigtran mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sigtran