Re: CIC as a RK

Haresign,

I believe that Jitin agreed before Ilie.

--brian

Haresign Lincoln wrote:                                           (Thu, 09 Nov 2006 13:44:32)
> If I understand this thread,
> 
> Ilie and Brain appear to be content with the status quo for RFC 4666.
> 
> Tolga would like some clarification regarding CIC use and M3UA.
> 
> Jitin, you first brought this issue forward.  Do you have any opinions?
> 
> Personally, I think it would be nice if we could find a solution to CIC
> load distribution in some common way.  
> 
> Did I miscount?
> 
> Regards,
> Lincoln 
> 
> -----Original Message-----
> From: Tolga Asveren [mailto:[email protected]] 
> Sent: Thursday, November 09, 2006 1:19 PM
> To: Ong, Lyndon; Haresign Lincoln; Ilie Glib
> Cc: [email protected]
> Subject: RE: [Sigtran] 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
> 
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran

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