Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

From: "Bhandari, Jitin (Jitin)" <[email-masked]>
Date: Wed, 8 Nov 2006 16:52:59 -0500

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-masked]] 
Sent: Wednesday, November 08, 2006 3:20 PM
To: Bhandari, Jitin (Jitin)
Cc: 'Ilie Glib'; Haresign Lincoln; [email-masked]
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-masked]] 
> Sent: Wednesday, November 08, 2006 1:52 AM
> To: Bhandari, Jitin (Jitin)
> Cc: 'Ilie Glib'; Haresign Lincoln; [email-masked]
> 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-masked]
http://www.openss7.org/

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 8 Nov 2006 15:24:02 -0700

Jitin,

Bhandari, Jitin (Jitin) wrote:                   (Wed, 08 Nov 2006 16:52:59)
> 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.

I think your example is for the wrong protocol.  MGs are controlled by an
MGC-MG control protocol such as the IETF standardized GCP.

If you are meaning to say that you would like to lump all 100,000 CICs into
a single SSP connected to the SS7 network you will even need more than one
point code.  There is nothing stopping you from assigning 10 point codes to
your MGC complex.  The SS7 network (and the SG) however, does not care how
you distribute messages related to a given CIC within your MGC complex.

If you have multiple MGCs, each is a separate entity from the viewpoint of
the SS7 network, and each gets a point code.

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

The SG cannot distribute traffic within your MGC complex for you.  However,
you could use M3UA _within_ your complex in whatever proprietary fashion you
choose.

> the discussion was all about.

Well no, RFC 4666 (RFC 3332 is obsolete) is a proposed standard that provides
transparent transport of MTP-User messages between an SG and an MGC: not for
distributing message within an MGC.  See the architecture document, RFC 2719.

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

I agree.  The issue is MGC centric and no change to the RFC is necessary.

If, however, some body would like to standardize distribution within the MGC
complex, LOADSEL/LOADGRP provide an good basis.  We should clean them up with
that clearly stated and publish them as INFORMATIONAL RFCs to provide
organizations such as SCOPE or CP-TA with a basis for further standardization.

--brian

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