RE: Recommendation for SUA modifications

Brian,

You still have not addressed how to handle _ASP congestion_ in the two
scenarios below.  I have.

At this point, I seem to have the agreement of several other members of
the WG.  You seem to be the only person opposed to making affected point
code optional.  I think Valerie's suggestion was a good one.

I'm not sure this exchange is practical anymore since you and I have a
basic disagreement over how to solve a problem.  I've presented a
solution.  If you have another one, I'd be welcome to listen to it.  But
in lieu of another solution to the two problems outlined below, it is my
opinion that this exchange is no longer serving a practical purpose.  I
look forward to feedback from other members of the WG and the SUA IG
editors.

Thanks for all your feedback.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Friday, October 14, 2005 9:10 AM
To: Haresign Lincoln
Cc: Valerie Gastaud; [email protected]; [email protected];
[email protected]
Subject: Re: [Sigtran] Recommendation for SUA modifications

Lincoln,

Haresign Lincoln wrote:
(Fri, 14 Oct 2005 08:48:46)
> Brian,
> 
> Are you saying that an ASP can not congest?  I'm not really sure where

> you are going with this.  The RFC says the following:
> 
>    The SUA layer at an ASP or IPSP MAY indicate local congestion to an
>    SUA peer with an SCON message.  When an SG receives a congestion
>    message (SCON) from an ASP, and the SG determines that an endpoint
is
>    now encountering congestion, it MAY trigger congestion procedures
of
>    the relevant SCCP standard.
> 
> If this is not true, let me know and we will need to amend the RFC and

> find another way to handle ASP congestion.  My very first email that 
> started this thread asked the question of whether SCON was valid from 
> ASP to SG.  At the time, you indicated that this was valid. Are you 
> now saying it is valid, but only in limited scenarios?

I tried a good number of times to tell you that SCON was for SCCP and
Subsystem (N-STATE and N-PCSTATE) congestion only.  This is no different
in the SG->ASP or ASP->SG directions.  When the ASP sends SCON it is
indicating SCCP or SCCP Subsystem congestion to the SG depending upon
whether it places SSN in the message or not.  When there is no SSN in
the message, it corresponds to MTP congestion (precisely the same
scenario in which M3UA sends SCON from ASP to SG).  When there is an SSN
in the message, and SSN is 1, it indicates SCCP Congestion, when SSN is
other than 1, it indicates SCCP Subsystem Congestion.

> 
> If this is valid, then there are two scenarios that the RFC does not
> handle:
> 
> 1) ASP shares the same point code as the SG and is not aware of it's 
> point code.  Meaning the ASP may just be a global title.  Or there 
> could be multiple AS behind the SG with different subsystems but 
> sharing the same point code as the SG.

It will try again: an ASP that is not aware of point codes has no
business signalling MTP or SCCP congestion levels.  MTP congestion
levels are maintained on a point code basis.  So are SCCP congestion
levels (RIL).
SCCP subsystem congestion (CL) is also maintained on a point code basis.

If the ASP is unaware of point codes, why is it sending the messages?

Also, in the trivial case where SG an ASP share a single point code, the
SG with a fully functional SCCP layer is capable of providing all SCCP
congestion management functions without assistance from the ASP.  It is
more usable in the multiple SG as STP, and ASP as relay scenarios, where
the ASP can send SCON independently to each SG.

> 
> 2) ASP is multiple point codes.
> 
> In the RFC, the handling of the SCON message by the SG is 
> implementation dependent.

No, the handling of the SCON message is clear.  Whether the SG sends an
SS7 message to the SS7 network is in accordance with the conformances
that it must meet in that direction that are outside the scope of the
SUA specification.  Because the SG MAY (in order to meet conformance)
send an
SS7 congestion message, a SCON sent from the ASP clearly MUST have the
necessary information and be generated under the proper conditions.  The
description of the message, and its mandatory contents, accomplish this.

--brian

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