Re: FW: RFC 4666 M3UA
Brian F. G. Bidulock <bidulock <at> openss7.org>
2007-09-13 16:48:56 GMT
Kevin,
I believe that you are talking about the multiple SG as STP scenario.
For this scenario to work correctly, from the SS7 perspective, each STP
must view the ASP Point Code to be an alias point code that is local to
the STP in the same sense as an ANSI T1.111.4/2000 SCCP "Alias" point
code described in ANSI T1.111.4/2000 3.9 and 3.A. That is, the remote
ASP is connecting via M3UA to a local MTP-SAP on the STP which is shared
between STP pairs in the ANSI T1.111.4 "Alias" sense.
When set up in this manner, each STP must respond to TFC in the
appropriate manner as dictated by, for example, ANSI T1.111.4 Section
13.7, and in your case:
13.7.5 If T15 expires after the last updated of the congestion
status of the signalilng route set towards destination X by a
transfer-controlled message relating to the same destination, the
signalling-route-set-congestion-rest procedure is invoked (see
13.9).
and
13.9 The signalling-route-set-congestion-test procedure is used at
an originating signalling point to update the congestion status
associated with a route set towards a certain destination. The
purpose is to test whether or not signalling messages destined
towards that destination with a given message priority or higher
may be sent.
...
Because the "Alias" point code is considered local to the STP, the STP
must respond in the same manner as a signalling end point under sections
13.7 and 13.9.
The DAUD procedure is not intended to trigger SS7 procedures at the SG,
but is intended as an optional procedure invoked by the ASP to permit
the ASP to syncrhonize its state with regard to availability and
congestion of remote signalling points to support restart.
The SCON is the equivalent of the MTP-STATUS.
So, sending RCT is the obligation of the STP which "owns" the ASP's
signalling point code in the SS7 sense. Route set status changes
resulting from the procedure are indicated to the ASP using SCON.
Because your implementation appears to be sending RCT under the correct
circumstances, but is mere placing the wrong point code in the test
message, it is likely just a bug.
--brian
Lyndon Ong wrote: (Wed, 12 Sep 2007 15:15:00)
>
> Ken,Javier,Lyndon,
> I got your names from an inquiry to the IETF about the RFC 4666.
> Recently I have been involved in some testing of SS7 congestion and
> it's reaction from and IP network using M3UA. The SS7 physical
> connection utilized two ITP's with BLinks to the SS7 network. It
> appears the ITP's tested were not capable of transmitting the RCT (
> Route Congestion Test) message in response to the TFC ( Transfer
> Congestion) they received with a proper Originating Point Code. The
> ITP responded to the TFC with a RCT that contained it's own
> originating point code. The RCT should contain the OPC of the node at
> the end of the trunks. This would be the IP endpoint not the ITP.
> Further it appears there is no provision within M3UA to facilitate IP
> endpoints to send a message to the ITP that would generate a proper
> RCT.
> If possible could you respond to my concerns.
> 1. Do I understand the M3UA protocol in the belief there is no
> workable RCT provision, or is there a provision that would enable
> the ITP to reply to a received TFC with a RCT that has the
> originating point code of the IP endpoint?
> 2. I notice the DAUD message contains an Information Parameter. Is
> there an intent or possibility the DAUD message could trigger a
> RCT on the SS7 side of the ITP with the correct OPC of the IP
> endpoint?
>
--
--
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/
. I did not follow this
> thread in full but could you summarize shortly why you believe that this
> is needed?
>
> ----------------------------------------------
> Jacky chen：
> the changeback procedure of MTP3 is mature and easy to be realized,but the
> draft using the CorrectionId
> is not simple .
>
> and,how do you think about adding parameter into HEATBEAT to check the
> ASP'S Status In AS of each endpoint ,like STLM/STLA.
RSS Feed