RE: RFC 4666 M3UA - Reg Request Message

Brian,

I think you would agree to the fact with 100s of MGs handled hence by 100s of ASPs (within one MGC) with each ASP may be handling 100,000 CICs is a real network. CIC resources are large (80K or more per MG) and MGC call handling (ISUP, Call Control etc) is distributed in nature.

And if you agree to that then every MGC provider would have to worry about arbitration logic built in within some centralized ASP because the fact is that there are multiple ASPs (100s) handling traffic with each MGC.
As from my previous email, either we have centralized ASPs (even two to avoid SPOF) to arbitrate traffic between all ASPs (assuming handling ISUP & Call Control) or have such problems being solved by M3UA.

I thought SIGTRAN RFC-3332 just tried to solve that issue and that's what the discussion was all about.

It's fine with me if SIGTRAN and specially M3UA want to stay in the domain of Point Code based routing for MGC (usually distributed ASP model) and move the problem into MGC domain. Then in that case we don't even need LOADSEL like algorithms as the issue is MGC centric.

-Jitin

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Wednesday, November 08, 2006 3:20 PM
To: Bhandari, Jitin (Jitin)
Cc: 'Ilie Glib'; Haresign Lincoln; [email protected]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Jitin,

Please see comments below.

Bhandari, Jitin (Jitin) wrote:                          (Wed, 08 Nov 2006 13:28:08)
> Brian,
> 
> See my responses below.
> 
> -Jitin
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]] 
> Sent: Wednesday, November 08, 2006 1:52 AM
> To: Bhandari, Jitin (Jitin)
> Cc: 'Ilie Glib'; Haresign Lincoln; [email protected]
> Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message
> 
> Jitin,
> 
> I don't see how you can possibly need to split CIC ranges across ASPs,
> and why you could possibly need to register them dynamically even if you
> did.
> >>>>>> See network topologies of MGs and you would realize the through put
> >>>>>> and capacity requirements for MGC. 

You still have not state a need here and, frankly, I cannot see one.  Two
low-cost servers can easily distribute load for even massive MGCs.

> 
> It think that you are expecting M3UA to solve internal MGC design issues
> that it was never intended to solve.
> >>>>>>> No. We are just trying to standardize an issue which is present out
> >>>>>>> there in the network and we see everyday. My discussions are purely
> >>>>>>> from the nature of inter-ops between MGC & SG. If only Point code
> >>>>>>> based routing is only the scope and requirement for SIGTRAN, then we
> >>>>>>> do not need any further modification to RFC 4666.

Just what is this issue to which you refer?  Can you describe what real-world
problem would necessitate routing on CIC?  SS7 ISUP nodes handle an entire
point code of traffic all day long, every day, across the globe.

> 
> Why do you need to do this at all?
> >>>>>>>>> MGs handle resources are all deployed geographically everywhere.
> >>>>>>>>> MGs do have large capacity upto 80K CIC resources and beyond. You
> >>>>>>>>> would need that much processing power (distributed of-course) to
> >>>>>>>>> handle each one such MG which could further be 100s in number.
> >>>>>>>>> Also, it is not necessary that each MG will be handled by all ASPs
> >>>>>>>>> on the MGC. It is also not necessary that we always perform Load
> >>>>>>>>> sharing model between ASPs supporting One MG. The specs should
> >>>>>>>>> provide full flexibility. 

SS7 ISUP nodes (SSPs) each have a point code.  Geographic dispersal of SSPs
within the SS7 network is performed by assigning a point code to each
geographically separate node.  SS7 does not do geographic dispersal based on
anything less than a point code.  Routing on CIC is rather like expecting the
IP network to route on port number rather than IP address.

> 
> Why do you not just place two ASPs in front of your MGC and distribute
> by CIC within the MGC architecture to your heart's content?
> >>>>>>>> Thanks for the suggestion. One could easily implement this model
> >>>>>>>> and have arbitration logic for CICs at centralized ASP on the MGC.
> >>>>>>>> On the same lines, then, why do we need LOADSEL? One could
> >>>>>>>> implement such LOADSEL model at MGC on the ASP in the same fashion.
> >>>>>>>> Also, see my above network topology which is a very valid one in
> >>>>>>>> real world, where through put and arbitration would be a serious
> >>>>>>>> issue with single point of processing and obviously single point of
> >>>>>>>> failure (which is in-acceptable for any telecom network). 

Two ASPs.  No SPOF.

> 
> Why do you expect the SG (which is obviously distant from the MGC) to
> perform this distribution for you?.
> >>>>> Because that's what RFC 3332 talked about with introduction of CIC
> >>>>> ranges. RFC-4666 is still open about Static Routing key definition on
> >>>>> this via LM. It's only ETSI which specifies PC level routing. Either
> >>>>> we clearly close the option of Routing key beyond PC or define it in a
> >>>>> better way for both Static & Dynamic. Also, Routing key definition
> >>>>> should be same for both procedures.

ETSI only followed the discussion that we had in the WG over the last 4 or 5
years, with the sole exception that routing on SI value is possible under some
circumstances.  If you want to look at the discussion that lead to the removal
of SSN and CIC (but more related to SSN), see the thread "m3ua- IG" from
January 2003 on the archives.  In those discussions we pretty much agreed that
routing keys should be based on elements of the MTP header (OPC/DPC/SI) and
that SSN and CIC where loadsharing techniques (if necessary at all) rather than 
routing elements.

All in all, as SS7 point codes are focussed at a geographic point (that's what
the "point" in "point code" means) and you are free to distribute within the
MGC complex at that geographic point without affecting the SG/ASP protocol,
there is no need for SSN or CIC in RK or for load sharing for that matter.
SLS is sufficient to ensure a distributed load over ASPs serving a load
sharing AS.  The same is true for SUA (TID and DRN labels are also unnecessary
and should have been removed long ago).

--brian

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