Subject: RE: [Sigtran] # of Signalling Processes

From: "Salil Agrawal" <[email-masked]>
Date: Wed, 9 May 2007 17:05:43 +0530

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-masked]] 
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-masked]> 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-masked]
<mailto:[email-masked]> > 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-masked] 
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>

-- 
Ilie 

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

---

From: "Ilie Glib" <[email-masked]>
Date: Wed, 9 May 2007 14:03:07 +0200

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-masked]> wrote:
> 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.
>
> 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-masked]]
> *Sent:* Wednesday, May 09, 2007 4:43 PM
> *To:* Lee Dryburgh
> *Cc:* sigtran
> *Subject:* Re: [Sigtran] # of Signalling Processes
>
>
>
> Hello Lee,
>
>
>
> 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-masked]> wrote:
>
> On 09/05/07, Ilie Glib < [email-masked]> wrote:
> > Hello Folks,
> >
> > SIGTRAN protocols provide support for systems redundancy and scalability
> by implementing the concept of signalling processes (SGP, ASP, IPSP) and
> TMT.
> >
> > 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
> > 5. What are the corresponding capabilities of products from main market
> players?
> >

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 9 May 2007 08:11:26 -0400

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

 
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-masked]] 
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-masked]> wrote: 

Regards

Lee

On 09/05/07, Ilie Glib < [email-masked]> 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.
>
> 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.
>
>

-- 
Ilie 

-- 
Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 9 May 2007 06:21:08 -0600

Ilie,

Ilie Glib wrote:                                                      (Wed, 09 May 2007 14:03:07)
> 
>    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.

The number of SLS values in the SLS field of the MTP routing label is
not a limit on loadsharing from ASP over SGP.  In fact, ASPs serving a
load-share AS are not required to load-share over available SGP.
Nevertheless, when an ASP load-shares over available SGP, it is coherent
traffic flows that need to be sent to the same SGP (not the SLS value
which is merely derived from the traffic flow).  For distributing
coherent flows over SGP, the OPC, DPC, NI and SI fields can also be
taken into account, permiting coherent load sharing over many more than
16 SGP.

The other way around, the SGP can also take into account OPC, DPC, NI
and SI fields in addition to SLS when loadsharing.

>    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

16 is not a restriction.  AS define a number: the minimum number of
active ASPs necessary to service an AS; to permit prevention of
overloads.

--brian

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

---

From: "Ilie Glib" <[email-masked]>
Date: Wed, 9 May 2007 14:28:10 +0200

Brian,

thanks for your answer. n+k redundancy is defined for M3UA only. Indeed it
may shield the AS from traffic inflow, but according to my knowledge n+k
redundancy is optional. So the SGs may not support that.

Regards

/Ilie
On 5/9/07, Brian F. G. Bidulock <[email-masked]> wrote:
> Ilie Glib
> wrote:                                                      (Wed, 09 May
> 2007 14:03:07)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 9 May 2007 06:29:35 -0600

Ilie,

Ilie Glib wrote:                                                      (Wed, 09 May 2007 14:28:10)
> 
>    Brian,
> 
>    thanks  for  your  answer.  n+k  redundancy  is defined for M3UA only.
>    Indeed  it  may shield the AS from traffic inflow, but according to my
>    knowledge n+k redundancy is optional. So the SGs may not support that.

Untrue.  SUA defines n+k redundancy as well.

--brian

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

---

From: "Ilie Glib" <[email-masked]>
Date: Wed, 9 May 2007 14:32:21 +0200

should you say SUA mentions n+k in one sentence without going to details or
referring to M3UA.
/Ilie

On 5/9/07, Brian F. G. Bidulock <[email-masked]> wrote:
> 2007 14:28:10)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 9 May 2007 06:58:33 -0600

Ilie,

M3UA does not support anything more than SUA in this regard.  In particular,
SUA has the NTFY("Insufficient ASP resources active in AS") notification to
which I referred as useful for preventing overloads.

--brian

Ilie Glib wrote:                                                      (Wed, 09 May 2007 14:32:21)
> 
>    should  you  say  SUA  mentions  n+k  in one sentence without going to
>    details or referring to M3UA.
> 
>    /Ilie

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

---

From: "Ilie Glib" <[email-masked]>
Date: Wed, 9 May 2007 15:05:53 +0200

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-masked]> 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
> 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,
> that your SGaccepted to go active?
>
> Regards
>
> /Ilie
>
> Signalling Processin SIGTRAN means an OS process?
>
> In my viewthe number of active processes especially in loadsharing and