Re: # of Signalling Processes

Hello Tolga,

I am not sure whether it is deployment only. Normally a product supporting
certain features of the standard protocol/application shall be rather open
to what it can receive. I would not call support of 2^24 ASP being OPEN, to
me it is more like being CRAZY.
I would expect from SIGTRAN WG a statement about minimum capabilities
required from SIGTRAN compliant implementations. It can also be a deployment
RFC.

My questions are very similar to the recent discussion of DAUD in M3UA,
although it is not causing so obvious interop consequences.


Regards

/Ilie

On 5/9/07, Asveren, Tolga <[email protected]> wrote:
>
>
> Ilie,
>
> All these are more deployment considerations. People can have different
> loadsharing schemes on SGPs. For example, SGP could use round robin for
> certain cases, e.g. for a service with a single TCAP query/response. In
> such a deployment, number of ASP supporting the AS wouldn't be restricted by
> SLS.
>
> Basically, there is some network engineering associated with this. IMHO,
> protocol specification is not the best place to talk about considerations
> associated with deployments.
>
>    Thanks,
>    Tolga
> ________________________________________
> From: Ilie Glib [mailto:[email protected]]
> Sent: Wednesday, May 09, 2007 8:03 AM
> To: Salil Agrawal
> Cc: sigtran
> Subject: Re: [Sigtran] # of Signalling Processes
>
> Salil,
>
> as you pointed out yourself, there is no much sense to support more than
> 16 M3UA ASPs within an AS for ITU-T markets.
> What is the point to support more ASPs then? If we conclude -16 is enough,
> can this create interoperability problems for systems having more than 16
> ASPs/IPSPs? For instance, can that result in overloading those poor 16 ASPs
> that your SGaccepted to go active?
>
> Regards
>
> /Ilie
>
> On 5/9/07, Salil Agrawal <[email protected]> wrote:
> Hi Ilie,
>
> Response to your questions
>
> Simple question: How many signalling processes your system can talk to at
> the same time for the same RK? Will they receive the same amount of traffic
> in loadshare TMT?
>
> Depends on the ASP registered with the relevant AS, no limitation on that
> number as per RFC.
> If load sharing is done based on SLS (in case of M3UA), or done based on
> Sequence Number (in case of SUA) then not necessarily the load will be equal
> until unless it is round robin.
>
> Will you use SLS values to distribute M3UA traffic? How about the size of
> the SLS?
> Size of the SLS is 16 in case of ITU, 32 in case of ANSI 5bit, 256 in case
> of ANSI 8bit so if the distribution is based on the SLS then ideally you
> should not have ASPs in an AS more then the SLS MAX value.
>
> Thanks,
> Salil
>
>
> ________________________________________
> From: Ilie Glib [mailto: [email protected]]
> Sent: Wednesday, May 09, 2007 4:43 PM
> To: Lee Dryburgh
> Cc: sigtran
> Subject: Re: [Sigtran] # of Signalling Processes
>
> Hello Lee,
>
> quick question in response: what of the SIGTRAN RFCs mentions that
> Signalling Processin SIGTRAN means an OS process?
>
> Signalling Process is a SIGTRAN concept, and different implementers can
> map it in their own way to their platforms and architectures.
>
> In my viewthe number of active processes especially in loadsharing and
> broadcast TMTs is very important and can either improve or degrade your
> system performance.
>
> Simple question: How many signalling processes your system can talk to at
> the same time for the same RK? Will they receive the same amount of traffic
> in loadshare TMT?
>
> Will you use SLS values to distribute M3UA traffic? How about the size of
> the SLS?
>
> Regards
>
> /Ilie
>
> On 5/9/07, Lee Dryburgh < [email protected]> wrote:
> Quick questions - have you read about n+k redundancy in the specs? Are
> you familiar with processes (in the UNIX sense, child processes,
> daemon Etc.)? I have no idea why you think the RFCs should be stating
> limits on the number of software processes that you spawn.
>
> Regards
>
> Lee
>
> On 09/05/07, Ilie Glib < [email protected]> wrote:
> > Hello Folks,
> >
> > SIGTRAN protocols provide support for systems redundancy and scalability
> by implementing the concept of signalling processes (SGP, ASP, IPSP) and
> TMT.
> >
> > Could you please share your view on the minimum number of signalling
> processes per logical entity (AS or SG) that the SIGTRAN signalling
> processes MUST support.
> >
> > I am after answers to very simple questions like
> >
> > 1. How many SGPs shall a standard ASP support per SG?
> > 2. How many SGs shall a standard ASP support per SS7 destination?
> > 3. How many ASPs shall an SGP/SG support per AS?
> > 4. How many remote signaling processes per logical entity (SG/AS) have
> to be supported to comply with SIGTRAN RFCs?
> >
> > I would expect that SIGTRAN RFCs provide answers to the questions above.
> However, to my knowledge, none of the RFCs puts any limit on the number of
> redundant signalling processes. In my view this may result in
> interoperability problems and traffic disturbances.
> >
> > 5. What are the corresponding capabilities of products from main market
> players?
> >
> > These questions make sense almost for all user adaptation layers and
> traffic mode types.
> >
> >
> > Thank you in advance for your help
> >
> > --
> > Ilie
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> >
>
>
>
> --
> Ilie
>
>
>
> --
> Ilie
>
> _______________________________________________
> 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