RE: Congestion in M3UA/SUA and the use of the SCON

"Haresign Lincoln" <[email protected]>
Newsgroups gmane.ietf.sigtran
Message-ID <849535E338E99741B7F7413F73253EDB0249FAC8@us-nj-mail1.comverse.com>
Brian,

I certainly don't expect anyone outside fo Comverse to design our SW.
We are extremely successful at that deployed in 100s of networks and
thousands of deployments throughtout the world.  I'm not sure where you
are getting that from or why you would even suggest it.  What I do
expect is that if a committee is going to come out with a standard, then
that committee should be willing to:

1) accept improvements
2) accept compliments
3) accept criticism 

As I stated, the SIGTRAN RFCs are quite good for their age and my hats
off to the contributors.

In my humble opinion, I believe we can make improvements in the
specifications.  At the moment, I'll focus on the SUA specification.
This is not related to "nodal TFCs".  It is related to subsystem
management and how that applies to SCON messages from the ASP.  The
ability to send an SCON from the ASP exists today in the spec.  I've
already outlined two problems with this in SUA.  I will propose
alternate text.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Thursday, October 06, 2005 1:54 PM
To: Haresign Lincoln
Cc: Tolga Asveren; [email protected]
Subject: Re: [Sigtran] Congestion in M3UA/SUA and the use of the SCON

Haresign,

Haresign Lincoln wrote:
(Thu, 06 Oct 2005 10:21:48)
> Tolga,
> 
> [TOLGA]:Does anybody know the rationale behind sending SCON from ASP 
> to SG when ASP -not the M3UA layer of ASP but something else- is
congested?
> 
> The rationale would be that the ASP is congested at the layer above 
> M3UA and you want to reduce or eliminate new traffic.  I can give you 
> several more concrete examples if you want them.  There are many 
> reasons why an ASP would want to indicate congestion.

User part (and subsystem) applications must use their own measures for
flow control within the user part (and subsystem).  These things are for
SS7 network and protocol congestion, not application congestion.

> 
> > [lincoln]: Where is this documented?
> [TOLGA]Probably nowhere in official documents, I happen to know about 
> it just because I could remember -hopefully correctly- the discussions

> about whether SCON from ASP to SG should be allowed or not. Could be 
> an idea to mention about it somewhere.
> 
> And if the specs don't specify something, then it's not in the specs.
> Period.  I don't think there is any getting around that one.  

ANSI T1.111.4/2000 specifies the conditions under which an SS7
signalling point can send a "nodal TFC" as a result of the congestion of
the Signalling Message Handling function.  The SS7 documents are
Normative.  SCON in the ASP->SG direction was intended to provide a
protocol mechanism to allow "nodal TFC", primarily in the multiple SG as
STP case (similar to DRST which is also only used in the mutliple SG as
STP scenario).

It has no other use.  As "nodal TFC" itself is optional to send in SS7,
SCON ASP->SG must obviously be optional in M3UA/SUA.  Also, because the
SG is responsible for policy towards the SS7 network (and other MTP- or
SCCP-Users), the SG does not need to respond to it or take any action on
it whatsoever, unless it wishes to.

If you cannnot figure out how to use it don't.  Nobody is requiring you
to use it.

If you would like someone to design your SG for you, do no expect the
specification to do so.

--brian

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

______________________________________________________________________
  This email message has been scanned by PineApp Mail-Secure and has
been found clean.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.