Re: CIC as a RK

Hello Lincoln,

with the current status of M3UA RFC CIC ranges can be used for
loadsharing, if both SG and ASPs support that at provisioning of
ASPs/ASes and the AS takes care od application level procedures.

M3UA implementors' guide provides the following reason for CIC removal:
"Use of SSN and CIC Routing Keys is inadequately defined in RFC3332
leading to non-interoperable solutions."

Whether we want to use CIC ranges as part of RK and improve the
description to provide for interoperability or use them as loadsharing
"label" like in LOADSEL is still open as far as I can understand.

I do not see the reasons that Brian brought as decisive in favor of
LOADSEL vs RK with CICs.

IMHO from Tolga's list below item a) is the best. The default ASP can
also fail and what then.

In alternative a) distributed AS shall take care of ASP failure
situations. The probability of the event where all ASPs are INACTIVE
and cannot go ACTIVE after a NTFY shall be reduced to a minimum. IMHO
MGC internal architecture shall provide for that. Thus SG shall not
initiate any application level messages to SS7 realm.

Regards

/Ilie

On 11/9/06, Tolga Asveren <[email protected]> wrote:
> Lincoln,
>
> I agree with your concerns and as a general strategy I would think one can
> follow (for the case where CIC ranges are used to define different RKs):
>
> a)Using Override trafic mode for each AS. The standby instance may actually
> take over control of the CIC after a failover or just reply back with the
> appropriate answer.
>
> b)Using a default fauilure handling ASP, everything, which is received for
> an AS, for which there is no ACTIVE ASP is forwarded there. That ASP
> constructs the appropriate answer.
>
> c)The SG constructs the appropriate answer and sends it back.
>
>
> I believe, as long as ASP/SG agree on which model is followed, there
> shouldn't be a problem from interoperability point of view. Probably that
> agreement could be provisioned both at SG and ASP.
>
>    Thanks,
>    Tolga
>
> > -----Original Message-----
> > From: Haresign Lincoln [mailto:[email protected]]
> > Sent: Wednesday, November 08, 2006 4:07 PM
> > To: Ilie Glib
> > Cc: [email protected]
> > Subject: [Sigtran] CIC as a RK
> >
> >
> > Ilie,
> >
> > I'm not sure that we have ever answered this basic issue:
> >
> > Do we want to use CIC as a Routing Key (meaning that I can have separate
> > AS with all the same RKs except CIC range).  CIC range will be the
> > determining factor for how the SG routes between AS.
> >
> > Or, do we want to use CIC for loadsharing.  Meaning that the SG will
> > choose AS based upon other criteria besides CIC (DPC, OPC, SI), and then
> > use CIC to distribute within the AS (similar to TID/DRN in SUA).
> >
> > I think the second is more practical as it avoids issues of CIC
> > management that are apparent in the first case.  To illustrate, I have
> > this simple scenario.  We have two different AS.  Each with a single
> > ASP.  They share the same PC as the SG, but use a CIC range as RK to
> > differentiate the two.
> >
> >
> > ---------
> > | AS1   |\
> > | PC=1  | \
> > | CIC=1 |  \
> > ---------   \ |------|
> >              \| SG   |
> >              /| PC=1 |<====SS7 Network===>
> > ---------   / |------|
> > | AS2   |  /
> > | PC=1  | /
> > | CIC=2 |/
> > ---------
> >
> > When AS1 loses the association to SG, how does it handle an incoming IAM
> > for CIC=1?
> >
> > Or if there is a call in progress, how does it handle an incoming REL
> > for CIC=1?
> >
> > These are real scenarios that, if not handled, either affect billing or
> > use of network resources.  No network provider will be happy if these
> > problems are not solved.  If you expect your SG to interface to somebody
> > else's AS, they must be solved in an agreed upon manner.  If it is your
> > SG and your AS, no problem.  You can determine some internal solution.
> >
> > Regards,
> > Lincoln
> >
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
>
>


-- 
Ilie