RE: CIC as a RK

IMO, allowing CIC ranges as RK constructs and explaining how it is supposed
to be used and addressing any issues related with it (hopefully not much) in
the M3UA document may be useful.

    Thanks,
    Tolga

> -----Original Message-----
> From: Ong, Lyndon [mailto:[email protected]]
> Sent: Thursday, November 09, 2006 12:20 PM
> To: Haresign Lincoln; Ilie Glib
> Cc: [email protected]; Tolga Asveren
> Subject: RE: [Sigtran] CIC as a RK
>
>
> Hi Guys,
>
> I've been watching the discussion with interest, but am not sure if
> a consensus is developing (a problem with this group for a while).
> Can people state what they think is the best approach?
>
> e.g, work within the current (updated) M3UA, define some extension
> to the M3UA, work on Brian's LOADSEL proposal?
>
> Lyndon
>
> -----Original Message-----
> From: Haresign Lincoln [mailto:[email protected]]
> Sent: Thursday, November 09, 2006 8:50 AM
> To: Ilie Glib
> Cc: [email protected]; Tolga Asveren
> Subject: RE: [Sigtran] CIC as a RK
>
> Ilie,
>
> As I stated in one of my first emails, I have no problem with any
> approach that is taken (LOADSEL vs. M3UA RFC vs. something else).  I
> just believe we need to better document the approach and outline all the
> issues with this.
>
> I'm uncertain how to proceed further on this.  IMHO, if we make it an
> extension of the M3UA RFC, it is more likely to be adopted by a broader
> range of network equipment providers.  But perhaps I'm wrong.
>
> Lyndon,
>
> As chair of this working group, do you have any advice on this topic in
> general?
>
> Regards,
> Lincoln
>
> -----Original Message-----
> From: Ilie Glib [mailto:[email protected]]
> Sent: Thursday, November 09, 2006 10:01 AM
> To: Haresign Lincoln
> Cc: [email protected]; Tolga Asveren
> Subject: Re: [Sigtran] 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
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran