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

From: [email-masked]
Date: Fri, 22 Mar 2002 13:02:52 -0500

Hello Brian,

Thanks for the response. Just to clarify...

In the SG-is-STP case, the SG should process a TFC destined to the ASP and
implement the route-set-congestion-test procedure (issue RCTs) on behalf of
the ASP.
(The SG also converts the TFC to a SCON and sends it to the ASP).

I think this issue requires clarification because for the SG-is-STP case,
implementing
the route-set-congestion-test procedure on behalf of an M3UA-attached SEP
is
functionality that is not immediately obvious. The fact that M3UA lacks a
primitive for RCT certainly suggests this, but the matter could be
clarified.

Regards,

Jeff

-------------------------------------------------------------------------------------
Jeffrey,

[email-masked] wrote:                    (Fri, 22 Mar 2002
10:09:50)
> 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?

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.

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

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.

>
> 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)?

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

--brian

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

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 22 Mar 2002 12:46:09 -0600

Jeffrey,

There are probably a lot of things about the multiple SG as STP
configuration that has implementation considerations.  In the
main M3UA draft we wanted to keep away from specifying the NIF.
This is a function of the NIF.  No additional protocol was
required.

As in my note from last summer, however, this is just the tip
of the iceberg for multiple SG as STP behavior.  Changeover and
changeback are also a big issue.  Some of this stuff will be more
adequately addressed by the IPSP extension draft, particularly
as multiple SG as STP configuration is more akin to IPSP than it
is to SGP/ASP.

In IPSP extension draft discussions we have been discussing passing
RCT between SGs in a DATA message rather than formulating a new
message.  In the SS7 network RCT is treated just as any other
message and there seems no need to act any differently than the
SS7 network for IPSP operation.  In the SGP/ASP configuration there
is no MTP/MTP-User primitive that corresponds to RCT.  It is a
function solely of the MTP-Provider.

I'm not sure whether multiple SG as STP should be addressed in the
Implementor's Guide or whether it warrants its own extension draft.

--brian

[email-masked] wrote:                    (Fri, 22 Mar 2002 13:02:52)

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