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

Brian,

For some applications (e.g., SMS) it is not necessary to process a
received SCON.  If the ASP is simply responding to a query from the SS7
network, PCSTATE and N-PCSTATE have no meaning.  However, it may be
desirable for the SG to not route new traffic to a congested ASP.
Therefore, we want to implement SCON from ASP to SG.  I see no need to
burden the ASP with the affected PC if it is not necessary.  Let's make
it optional just like so many other things are in the specification.

Congestion is detected WITHIN SCCP.  I'm not saying the application is
detecting congestion.  I'm saying the SUA layer in the ASP is detecting
congestion (implementation dependent) and sending an SCON to the SG (as
specified in the SG).  I'm simply restating what is in the RFC.

I don't know why you are equating an SCON ASP->SG with an N-PCSTATE
request to the SCCP.  N-PCSTATE is an SCCP->User message.  

Regards,
Linconl

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

Lincoln,

Without knowing any point codes the SCCP-User cannot properly process
received SCON(N-PCSTATE indications) far less generate them.

You need to realize that the SG-ASP interface that we are talking about
is an SCCP/SCCP-User interface.  Congestion, GTT, and the procedures you
speak of are below the SCCP/SCCP-User interface.  It is possible with
SUA to enhance operation with a relay function, but relay nodes are no
longer SG-ASP (they are IPSP).

When we say that an ASP can send SCON to an SG, we are saying that an
SCCP-User can generate N-PCSTATE request to the SCCP.

When sent from the SG (SCCP), and for relay operation, you use the SCON
of the SG->ASP direction.

--brian

Haresign Lincoln wrote:                     (Tue, 11 Oct 2005 13:52:25)
> Brian,
> 
> [brian]: I'm sorry but the concept of an SCCP-User that knows the 
> point code of every node in the SS7 network that it might want to send

> messages to, except its own, is not a very useful one.
> 
> I'm sorry to say, but you are mistaken.  Requiring an SCCP user to 
> know the point codes of any node in the network is too much overhead 
> for most operators for some applications.  For example, a typical SMS 
> application deals only with global titles (inbound and outbound).  
> Operators have no desire to provision all the PCs in their network.  
> They do this in the STPs and use GTT all over the place.  This is a 
> basic fact of operation in most of the large SS7 networks of the world

> that are running SMS.  If you are going to be running SMS over an SUA 
> SG, you would provision your SG with the inbound/outbound GTs.  The 
> outbound GTs would be to an STP that would do further GTT to get the 
> message to the MSC or HLR.  You really don't want to do any 
> provisioning on your ASPs if you can avoid it except for a single GT.
> 
> Knowledge of global titles is all that is required at an endpoint.
> 
> I'm not sure what you mean by "MUST be included in the source and 
> destination addresses of the Registration Request".  Are you referring

> to the PC?  Can you please point out where in the SUA RFC it indicates

> this?  I couldn't find it.
> 
> And no where in the RFC does it indicate that we need to supply the PC

> when sending a message from the ASP to the SG.  Nor does it say that 
> when the SG sends a message to the ASP, it needs to supply a PC in the

> destination address.  Certainly you need to supply an Address 
> Indicator if you are working with GTT, PC, and/or SSN.  But just like 
> an SCCP user today, it does not need to supply a point code in either 
> the calling or called address.  If the PC MUST always be present in 
> the source/destination address, shouldn't we update the RFC to reflect
this?
> All I see is an example of how to use the PC value if the Address 
> indicator is set to a certain value.  The AI just provides information

> about how to encode/decode based upon what is present.  If you are 
> saying the PC is a MUST, then the RFC should be updated to indicate 
> that the source/destination address _MUST_ contain the Point Code
parameter.
> 
> 
> Today, that is not the case.  And we can build an ASP that complies to

> the RFC without any knowledge of the PC.  Knowledge of the PC for some

> applications is unnecessary overhead that operators do not want to 
> configure.
> 
> 
> Regards,
> Lincoln
> 

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