Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

From: "Bhandari, Jitin (Jitin)" <[email-masked]>
Date: Tue, 7 Nov 2006 14:57:44 -0500

Ilie,

I fully agree with you on this.

Thanks,
Jitin

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]] 
Sent: Tuesday, November 07, 2006 2:46 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln, Brian

as far as I can understand, the old draft has everything that is
needed to solve CIC problem in a distributed application, that is, an
RK can contain CIC ranges. NTFY procedures will distribute AS/ASP
status changes to ASPs of the AS.

In order to receive a NTFY an ASP has to be inactive for the RK.

The rest is implementation dependent, handling of application level
procedures is the task of the concerned distributed AS.

/Ilie

On 11/7/06, Haresign Lincoln <[email-masked]> wrote:
> Ilie,
>
> Personally, I don't see how CICs can work in the old M3UA draft.
>
> And I'm still trying to determine what the actual requirements are.
>
> Do AS share the same PC as the SG when working with CICs or do we
> require a different PC?
>
> I think the first issue is to define all the requirements.
>
> Regards,
> Lincoln
>
> -----Original Message-----
> From: Ilie Glib [mailto:[email-masked]]
> Sent: Tuesday, November 07, 2006 1:33 PM
> To: Haresign Lincoln
> Cc: Barry Nagelberg; [email-masked]
> Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message
>
> Lincoln, Barry,
>
> I think  the way forwards with CICs depends on solutions we aim at, and
> it can either refine the RK as in an old M3UA draft, or define a load
> distribution scheme as suggested in LOADSEL draft.
>
> I believe both ways are feasible, and the WG has to agree on the
> preferred option.
>
> /Ilie
>
> On 11/7/06, Haresign Lincoln <[email-masked]> wrote:
> > Well if you are specifing a CIC range as a RK, then for other ASP to
> > be within the same AS, they also must specify the same CIC range..yes?
> >
> > -----Original Message-----
> > From: Barry Nagelberg [mailto:[email-masked]]
> > Sent: Tuesday, November 07, 2006 12:51 PM
> > To: [email-masked]
> > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> > Why the limitation?
> >
> > -----Original Message-----
> > From: Haresign Lincoln [mailto:[email-masked]]
> > Sent: Tuesday, November 07, 2006 12:45 PM
> > To: Barry Nagelberg; [email-masked]
> > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> >
> > So...does that mean you only have one ASP/AS?
> >
> > -----Original Message-----
> > From: Barry Nagelberg [mailto:[email-masked]]
> > Sent: Tuesday, November 07, 2006 12:26 PM
> > To: [email-masked]
> > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> > It is to be used as an RK, which implies routing decisions on an AS
> > level.
> >
> > -----Original Message-----
> > From: Haresign Lincoln [mailto:[email-masked]]
> > Sent: Tuesday, November 07, 2006 12:16 PM
> > To: Ilie Glib
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> >
> > Ilie,
> >
> > You're right.  The problem of TIDs/DRNs is different than CICs as loss
>
> > of an ASP will only result in loss of calls in progess.  The SG will
> > reshuffle new BEGINs to the remaining ASPs.   With CICs it's a little
> > more of a problem as CICs are being assigned by the network as it
> > initiates a call and not by the ASP.
> >
> > I'm unclear what the proposal is for CICs.  Is it to be used as an RK
> > which implies routing decisions on an AS level, or is it more like the
>
> > TID which implies routing decisions on an ASP level.
> >
> > Regards,
> > Lincoln
> >
> > -----Original Message-----
> > From: Ilie Glib [mailto:[email-masked]]
> > Sent: Tuesday, November 07, 2006 11:47 AM
> > To: Haresign Lincoln
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> > Lincoln,
> >
> > the format of the TID/DRN labels is not prepared for dynamic handling.
> > An ASP cannot serve two TID/DRN labels. Moreover, it is not possible
> > to combine several labels in one.
> >
> > Regards
> >
> > /Ilie
> >
> > On 11/7/06, Haresign Lincoln <[email-masked]> wrote:
> > > Ilie,
> > >
> > > Why couldn't you use TID/DRN ranges dynamically?  If the ASPs within
>
> > > the AS have knowledge of each other, and each ASP receives a NOTIFY
> > > upon ASP inactive, another ASP could become ACTIVE.  Not sure what
> > > you
> >
> > > mean by this.
> > >
> > > Regards,
> > > Lincoln
> > >
> > > -----Original Message-----
> > > From: Ilie Glib [mailto:[email-masked]]
> > > Sent: Monday, November 06, 2006 7:00 PM
> > > To: [email-masked]; Haresign Lincoln; [email-masked]
> > > Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message
> > >
> > > Brian,
> > >
> > > I do not agree that TID and DRN is a broken loadsharing scheme.
> > > It works perfectly, although it cannot use TID and DRN ranges
> > > dynamically.
> > > Even that is possible with AS internal communication.
> > >
> > > /Ilie
> > >
> > > On 11/6/06, Brian F. G. Bidulock <[email-masked]> wrote:
> > > > Lincoln,
> > > >
> > > > This simplest approach, and that taken by LOADSEL, is that, if a
> > > > message does not correspond to a registered/configured load
> > > > selection range, it is load shared over the active ASPs for the AS
>
> > > > using the normal loadsharing mechanism (i.e, SLS, round-robin,
> > > > dedicated default
> > > ASP).
> > > > Thus, the selected ASP can apply the appropriate unequipped CIC
> > > > treatment and the SG does not require knowledge of ISUP.
> > > >
> > > > The same is true for SSN and TID for SUA.  If you recall our
> > > > recent discussion regarding TID and DRN labels, the same
> principles apply.
> > > > LOADSEL is a more workable replacement for the broken TID/DRN
> > > > label mechanism.
> > > >
> > > > LOADGRP is even more sophisticated.  It is possible for the ASPs
> > > > to specify that a given Load Selection (CIC 1-3200) is
> > > > Active/Standby within a load group and the SG can fail this
> > > > specific load selection
> >
> > > > from one ASP to its alternate, again without knowledge of the
> > > > upper layer protocol (beyond syntactically extracting the load key
>
> > > > from the message).
> > > >
> > > > --brian
> > > >
> > > > Haresign Lincoln wrote:                       (Mon, 06 Nov 2006
> > > 15:07:17)
> > > > > Brian,
> > > > >
> > > > > Let me see if I understand correctly.  You are saying that we
> > > > > can distribute load within an AS using LOADSEL.  Does this imply
>
> > > > > that all CICs are covered.
> > > > >
> > > > > For example, if the SG is receiving messages from OPC1 for CICs
> > > > > 1-3200 and OPC2 for CICs 1-3200, then there must be an AS that
> > > > > handles all of these incoming IAMs.  Or, are you saying the SG
> > > > > has
> >
> > > > > no ISUP knowledge, and it is just looking at the CIC value and
> > > > > perhaps distributing load to the AS that is registered to
> > > > > receive
> > > traffic from OPC1 for example.
> > > > >
> > > > > Regards,
> > > > > Lincoln
> > > > >
> > > >
> > > > --
> > > > Brian F. G. Bidulock
> > > > [email-masked]
> > > > http://www.openss7.org/
> > > >
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > >
> > >
> > >
> > > --
> > > Ilie
> > >
> >
> >
> > --
> > Ilie
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
>
>
> --
> Ilie
>

-- 
Ilie

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

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

---

From: "Bhandari, Jitin (Jitin)" <[email-masked]>
Date: Wed, 8 Nov 2006 13:06:08 -0500

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-masked]] 
Sent: Wednesday, November 08, 2006 1:20 AM
To: Ilie Glib
Cc: [email-masked]; 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-masked]
http://www.openss7.org/