Subject: RE: [Sigtran] # of Signalling Processes

From: "Salil Agrawal" <[email-masked]>
Date: Wed, 9 May 2007 16:26:24 +0530

Hi Ilie,

There is no restriction by any of the sigtran RFC on th number of ASP,
AS, SG or SGP supports, so any SIGTRAN signalling entity can have any
number of AS/ASP per SG/SGP or reverse till it does not break the
theoretical limit I mean ASP ID is coded as 4 BYTE in many messages so
until unless we are able to support it is acceptable from RFC point of
view. 

The problem of the interoperability, I don't see any issue in that can
you please specify what type of issue you visualize in the
interoperability when using different number of redundant processes. 

Thanks,

Salil

________________________________

From: Ilie Glib [mailto:[email-masked]] 
Sent: Wednesday, May 09, 2007 4:16 PM
To: sigtran
Subject: [Sigtran] # of Signalling Processes

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

---

From: "Ilie Glib" <[email-masked]>
Date: Wed, 9 May 2007 13:24:48 +0200

Hello Salil

see below.

Regards

/Ilie

On 5/9/07, Salil Agrawal <[email-masked]> wrote:
>
>  Hi Ilie,
>
>
>
> There is no restriction by any of the sigtran RFC on th number of ASP, AS,
> SG or SGP supports, so any SIGTRAN signalling entity can have any number of
> AS/ASP per SG/SGP or reverse till it does not break the theoretical limit I
> mean ASP ID is coded as 4 BYTE in many messages so until unless we are able
> to support it is acceptable from RFC point of view.
>

/ilie I am curious what system has support for 2^24 remote signalling
processes per AS. If there is no one, then none of existing systems complies
in that sense to the RFCs.

>
> The problem of the interoperability, I don't see any issue in that can you
> please specify what type of issue you visualize in the interoperability when
> using different number of redundant processes.
>

/ilie Imagine 256 ASPs going active for the same signalling point code / RK.
Will your SG acknowledge all ASPACs? If so, will your SG loadshare traffic
between all of those?

If your SG does not ack all 256 ASPACs, does it provide for
interoperability?

>
> Thanks,
>
> Salil
>
>
>
>
>  ------------------------------
>
> *From:* Ilie Glib [mailto:[email-masked]]
> *Sent:* Wednesday, May 09, 2007 4:16 PM
> *To:* sigtran
> *Subject:* [Sigtran] # of Signalling Processes
>
>
>
> Hello Folks,
>
> 4. How many remote signaling processes per logical entity (SG/AS) have to
> be supported to comply with SIGTRAN RFCs?
>
> 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