RE: # of Signalling Processes

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