RE: CIC as a RK

Jitin,

I'm a big proponent of TID in SUA (not necessarily in M3UA) and we have
invested heavily in it and it is working for us quite well.  We are
using it not as a RK, but for load distribution as specified in the ASP
Active message.

With regard to CIC as a RK, I seem to be getting a mixed message.
Brian, in one of his last emails, seemed to imply that you and everyone
else that we vocal on this subject was content with the status quo (RFC
4666 was fine and leave it up to the ASPs and implementors to solve the
problems independently if I can paraphrase here).  However, below you
are indicating that you feel more work is necessary.  Am I missing
something?

If you feel that further work is needed, I'd be happy to help define
wording, requirements, etc...

Regards,
Lincoln



-----Original Message-----
From: Bhandari, Jitin (Jitin) [mailto:[email protected]] 
Sent: Thursday, November 09, 2006 2:38 PM
To: Haresign Lincoln; Tolga Asveren; Ong, Lyndon; Ilie Glib
Cc: [email protected]
Subject: RE: [Sigtran] CIC as a RK

Lincoln et. al,

Yes, I did bring up this issue and for the reason as CIC parameters were
missing between transitions from RFC-3332 to RFC-4666. It is fair to say
that M3UA has been widely adopted by SG & MGC carriers and since
RFC-3332 included CIC based Routing Key for arbitration (or at least
attempted CIC arbitration) with registration procedures. 

We are having this discussion as RFC-3332 and its implementation are
widely performed and many of us used CIC as Routing key with optimized
version and fixing and resolving issues (whatever exists with CICs in
RK) in the network at proprietary level.

>From my opinion (and I think all SS7 network providers would agree) and
I stated that in my previous emails that its as how one want to perceive
M3UA requirements are in for SS7 networks. 

If M3UA is only required to maintain the integrity of Routing Label
(which does NOT include CICs or TIDs) for Routing keys (fair to say), it
is fair to assume that we could exclude CICs or TIDs from RK. 

I still agree that given architectures of MGCs (with hundreds of ASPs
and distributed resources) we would surely need arbitration logic for
both CICs and TIDs in the real world for any size of MGCs from 8 ASPs to
hundreds of ASPs in one MGC. 

It's up-to us that if we are interested in enhancing the current scope
of M3UA to perform such distribution mechanisms or just move it inside
MGC and have each vendor scope it out by themselves.

So, as I think Lincoln and probably all agreed that we need clear
requirement as what we want M3UA to do for us. RFC-3332 did show some
hope for CIC arbitration and we all realized its limitation. 

There are two clear school of thoughts:

1. M3UA should adhere to only Routing label for Routing Key and hence
all Routing Key related definition should not include CICs and TID. Any
such logic (if required) can be defined with MGC. If this is the case
then I must say that RFC-4666 needs to be very specific for Routing Key
definition at both places either be Static or Dynamic. Currently, the
Static Key definition (via LM) is wide open which can easily lead to
inter-op issues.

2. M3UA role needs to be enhanced to include CICs & TIDs and we all
solve such Issues at SG level. I think Lincoln in one of his previous
emails did clearly mention two issues which are the major issues to be
solved no matter if solve this issue either with LOADSEL or CICs in RK.
We can surely have separate discussion threads scooping out the issues
and possible solutions if we want.

Thanks,
Jitin

-----Original Message-----
From: Haresign Lincoln [mailto:[email protected]]
Sent: Thursday, November 09, 2006 1:45 PM
To: Tolga Asveren; Ong, Lyndon; Ilie Glib
Cc: [email protected]
Subject: RE: [Sigtran] CIC as a RK

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

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