Re: M3UA: SCON: congestion condition never abates

urte,

I should point out that there is an alternative to auditting congestion.
That is to simply resume sending traffic after a short period (1.4-2.0
seconds).  If the network is still congested, you should get a SCON message
rather immediately.  Otherise, traffic can just continue.

--brian

Brian F. G. Bidulock wrote:                                 (Tue, 23 Oct 2012 15:23:12)
> urte,
> 
> Please see comments inline...
> 
> urte plesske wrote:                                         (Tue, 23 Oct 2012 16:58:27)
> >    Hello, I'm faced with a problem based on the following architecture:
> >    AS connected to two SGs
> >       AS
> >      /  \
> >     /    \
> >    SG1---SG2
> >    SCCP: SGs are making GTTs to route to the ss7 network.
> >    MTP configurations on AS:
> >    There are two routesets defined on AS, one to SG1 (containing direct
> >    route and route over SG2) and to SG2 (containing direct route and route
> >    over SG1)
> > 
> >    SCON message was received by AS from SG2 with affected PC SG1.
> >    On AS the route set (PC SG1) was inhibited. No traffic was sent to SG1
> >    by AS any more.
> 
> This, to begin with, is somewhat peculiar.  The circumstances
> under which SG2 would send SCON to the AS concerning SG1's point
> code would be:
> 
>  - traffic on the association from AS to SG2 is overloading;
> 
>  - SG2's SMH function is overloading (in which case it should
>    have first attempted a DRST in ANSI-based networks);
> 
>  - the C-links between SG2 and SG1 are congested.
> 
> Which begs the question, why is the AS sending messages with DPC
> of SG1 to SG2?  Is not the direct route between AS and SG1
> available and unrestricted?  Perhaps you have already received a
> DRST from SG1 concerning its own point-code? (which would not be
> correct).
> 
> So, that's number 1 problem: Why are you sending M3UA-User
> messages from the AS to SG1 via the indirect route through SG2
> when there exists a direct route to SG1?
> 
> >    Usually the AS would start sending periodic DAUDs messages as a result
> >    of the congestion, but because SG1 was got to know as adjacent node, no
> >    DAUDs with affected Point Code = Point Code SG1 were sent by any ASP.
> >    No SCON messages were sent by SG2 to AS because no DATA and DAUD
> >    messages were received to react.
> >    The congestion condition never abates.
> 
> No, that is incorrect.  You should audit even though the
> destination is adjacent.  Following on on my first issue,
> you should be auditing SG1 already because there is something
> the matter with the direct route for you to have been sending
> messages on the indirect route.  The direct route must be
> restricted or unavailable, or the AS is doing the wrong thing.
> 
> > 
> >    Could you please help me with the following questions:
> >    How to solve this situation (timer on AS?)?
> 
> Send periodic DAUD while point codes are marked congested.
> The period should be 1.4 to 2.0 seconds.
> 
> >    Is it correct not to audit adjacent nodes?
> 
> No it is not.  Adjacent nodes need not be audited for
> availability, but they do need to be audited for restriction and
> congestion.
> 
> >    Can (should) SG2 send a SCON message even there are no DATA and DAUD
> >    messages to react?
> 
> No, is does not have to.  SG2 only need send SCON to the AS
> under the same conditions as an STP would send TFC to an
> adjacent signalling point.
> 
> >    Where can I find (rfc) the information, that SCON is like TFC and not
> >    TFR?
> 
> In the sections describing SCON and DRST.  SCON is equivalent
> to TFC, DRST is equivalent to TFR.
> 
> --brian
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/sigtran

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