Subject: [Sigtran] (M3UA) How does an ASP execute route-set-congestion-test (RCT)?

From: [email-masked]
Date: Fri, 22 Mar 2002 10:09:50 -0500

Hello All,

I am curious as to how an M3UA ASP abates congestion in the
SS7 network (executes the route-set-congestion-test procedure)
after receiving a SCON. Is there an unambiguous way for an
SGP to generate an RCT on behalf of an ASP?

This topic has been discussed before (snippets from 8/2001 follow),
but I have not found the conclusion to the thread, and the latest
draft does not seem to address the issue.

Is the answer as simple as making the Congestion Indications
parameter optional for the DAUD in order for the SGP to
differentiate between an availability audit and a congestion
audit (RCT)?

-Jeff

>Date: Mon, 20 Aug 2001 13:59:13 -0500
>From: Kurt Kite <[email-masked]>
>
>Hi,
>
>Brian and Joe have highlighted an issue that I have been meaning to
>raise with the mailing list. The issue is when the SG (acting as an STP)
>receives a TFC for which it is not the endpoint (i.e., it is not the node
>which originated the message which resulted in the TFC). In this case,
>I believe the correct behavior is for the SG to simply forward the TFC,
>via an SCON, to the appropriate ASP(s). Upon receiving the SCON,
>the ASP is free to audit the SG to check the status of the destination.
>In this case, the SG does not maintain the congestion status, so it will
>return a DAVA. It does not seem like the audit procedures are sufficient
>in the case where the SG is acting like an STP. It seems like what is really
>needed here is a way for an ASP to perform a RCT. Or is it simply acceptable
>to clear the congestion status in the above case?
>
>/Kurt

>From: Joe Keller <[email-masked]>
>To: "sigtran" <[email-masked]>
>Kurt,
>
>   I agree with you.  One possible solution would be to add a congestion
>audit message and let the DAUD act only as an availability audit.
>
>Thoughts?
>
>Joe

>Date: Mon, 20 Aug 2001 14:14:53 -0500
>From: "Brian F. G. Bidulock" <[email-masked]>
>Kurt,
>
>Unfortunately the ASP needs a whole bunch more MTP behavior for this
>SG acting as STP case.  RCT is just the tip of the iceburg.  What about
>CBD/CBA procedures where the changeback is between STPs and the CBD
>is addressed with the DPC of the ASP?  It goes on.  Your observation is
>another SG as STP issue which needs to be addressed.  Overloading DAUD
>could get complicated...
>
>--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 22 Mar 2002 10:50:27 -0600

Jeffrey,

[email-masked] wrote:                    (Fri, 22 Mar 2002 10:09:50)
> SGP to generate an RCT on behalf of an ASP?

The ASP reacts to SCON in the same fashion that an MTP-User reacts
to MTP-STATUS primitive.  An SG will initiate route-set-congestion-test
procedures towards the network upon the receipt of TFC per the
SS7 specifications.  Ne'er the twain meet.

The reason for the route-set-congestion-test procedure in the SS7
network are two-fold: one, to allow for lost TFC/TFA/TFP messages in
the network; two, to determine when abatement occurs.  SCONs cannot
get lost, DAUD is there if an ASP thinks it has lost a SCON.

> draft does not seem to address the issue.

What was discused is only the SG as STP case.  Also, there is nothing
stopping the SG from initiating route-set-congetion-test procedures
on behalf of the ASP even in this case.  There is no need for a DAUD
procedure at all.

> differentiate between an availability audit and a congestion

No, it is as simple as building the SG in such a way that it
performs SS7 procedures when it has to.

--brian

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