Subject: RE: [Sigtran] Congestion in M3UA/SUA and the use of the SCON

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 11 Oct 2005 14:09:51 -0400

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-masked]] 
Sent: Tuesday, October 11, 2005 1:59 PM
To: Haresign Lincoln
Cc: Tolga Asveren; [email-masked]
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-masked]
http://www.openss7.org/

______________________________________________________________________
  This email message has been scanned by PineApp Mail-Secure and has
been found clean.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Oct 2005 17:09:01 -0600

Haresign,

Haresign Lincoln wrote:                                                            (Tue, 11 Oct 2005 14:09:51)
> network, PCSTATE and N-PCSTATE have no meaning.

In this situation they have plenty of meaning.  Response NSDUs
are typically much larger than query NSDUs (small query, big
response).  The traffic is asymmetric and the remote end can
possibly be congested (receive) at SCCP even though it is not
congested in the transmit direction.  So any assumption that
just because a node is receiving messages from a remote SCCP
that its not congested is foolish.  Also, querying subsystems
tend to be switches that have many subsystems active.  SCCP does
not detect transmit congestion, only receive congestion.  It is
easy for the switch to be congested for receive by other
subsystems.

In fitting with the standard congestion avoidance procedures at
SCCP, the SCCP-User is required to avoid sending messages below
the restricted importance level and the if the SCCP-User does
not do so, the SCCP is required to send additional N-PCSTATE
indications.

Also, it would also be foolish to hinge the design of SUA (and
SCCP for that matter) around only restricted SCCP Protocol Class
0, TCAP Operation Class 3 applications with a simple query
response pair.

I suggest reading the SS7 standards with regard to the required
response of SCCP-Users to the receipt of N-STATE and N-PCSTATE
primitives.

> However, it may be

If the ASP is going to implement an SCCP procedure, it must meet
the requirements of the SCCP layer, not simply an SCCP-User.  To
perfrom SCCP Management, the SCCP layer must know the SCCP-SAPs
(each including an MTP-SAP which includes a point code) of all
its users, as well as the SCCP-SAPs (including MTP-SAP including
point codes) of all of the concerned remote subsystems for each
local subsystem.  Otherwise it cannot perform simply management
far less congestion mangement.

So, if the ASP is going to send SCON to the SG, the ASP must
contain enought of the SCCP management layer at the ASP to
effect this SS7 management procedure, and therefore must also
known what point code it is signalling congestion for.  It is
fortunate that we made the Affected Point Code Mandatory in the
SCON message from ASP to SG to preclude an ASP from violating
its responsibilities with regard to congestion detection in the
same way that your SCCP-Users are violating their responsibility
in performing congestion avoidance in response to received
N-PCSTATE.

> request to the SCCP.  N-PCSTATE is an SCCP->User message.  

Because the AS is an SCCP-User.

--brian

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