RE: CIC as a RK

"Haresign Lincoln" <[email protected]>
Newsgroups gmane.ietf.sigtran
Message-ID <849535E338E99741B7F7413F73253EDB0523B459@us-nj-mail1.comverse.com>
Brian,

Below you say that we could use SLS for loadsharing purposes.  Perhaps
I'm missing something, but these seems quite insuffient because:

1) That limits us to 16 values.
2) The SLS value for a call could change during the length of the call.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Wednesday, November 08, 2006 5:05 PM
To: Haresign Lincoln
Cc: Ilie Glib; [email protected]
Subject: Re: [Sigtran] CIC as a RK

Lincoln,

Haresign Lincoln wrote:                       (Wed, 08 Nov 2006
16:07:27)
> Ilie,
> 
> I'm not sure that we have ever answered this basic issue:

Yes, we answered this question when the WG removed SSN and CIC.  

> 
> 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 believe the answer is neither.  CIC or SSN can conceivably be used for
distribution of traffic (neither routing nor loadsharing) within an MGC
complex.  A principle design obejctive is minimization of state sharing
between multiple nodes in a horizontal distributed architecture, and
minimization of lost calls/transactions during failover within the MGC
complex.  However, the procedures are highly dependent upon
implementation details such as functional placement within the MGC
complex, but are local in nature.

For loadsharing between an M3UA SG and ASPs serving an AS, SLS is both
sufficient and necessary (CIC, due to the nature of its allocation, will
not ensure an equal load distribution).  SLS, coupled with an approach
such as CORID, provides assurance of in-sequence delivery at the ASP
pool.  Once a given message arrives, in sequence, at the ASP pool, which
functional unit within the MGC complex that it is delivered to is the
business of the MGC.

That said, M3UA can be used to distribute messages within the MGC
complex, however, its use within the MGC complex can include whatever
proprietary mechanism the MGC designer sees fit and is not really a
proper subject of standardization within IETF.  I use LOADSEL/LOADGRP.
Another design could use whatever mechanisms it chooses.  Perhaps SCOPE
or CP-TA will eventually standardize something here, but these
organizations are welcome to provide extension drafts and request IANA
assignments to that effect.

--brian

> 
> 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

--
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.