Re: # 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 SG accepted 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 Process in 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 view the 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