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

From: "Bhandari, Jitin (Jitin)" <[email-masked]>
Date: Wed, 8 Nov 2006 13:28:08 -0500

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. 

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.

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. 

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

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.

--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 13:19:34 -0700

Jitin,

Please see comments below.

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

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

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

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

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