Re: Question related with DAUD Message

Andrew,

Andrew Booth wrote:                         (Thu, 01 Feb 2007 17:44:31)

> vendors.  That's a bit of an aside from this thread, so I'll leave it
> for you to decide whether to spin it into a separate thread.  I'll just
> say that I agree that delaying a DAVA is better than discarding it. 

IMO discarding an indication to the MTP- or SCCP-User is a defect in
design and implementation.

> Sure, but sometimes bugs slip through anyway.  Some types of bugs are
> notoriously difficult to detect even with rigorous testing.  Bugs that
> require an overload condition then a DAVA probably fall into that
> category.  The first 100 times you do the test you might not have a full
> buffer (of whatever kind) when the DAVA should go out.

I used to do crush and destroy testing for the Telco.  They have ways:
proper load testing and field trials

> >   
> >> What if the ASP is connected to two SGPs and receives DUNA + DAVA from SGP1
> >> and DUNA + association loss from SGP2, in that order?
> >>     
> >
> > The concensus of the designers of the M3UA and SUA protocols
> > long ago (at about m3ua-06) was that SNMM are to be interpreted
> > by the ASP on a per-SG basis rather than a per-SGP basis.  For
> > example, when an AS receives DUNA from any SGP in the SG, it
> > means DUNA for the entire SG, not just the SGP that sent the
> > message.
> >   
> Exactly.  So, in the race condition described above, the ASP is left
> believing that the destination is inaccessible to the SG (incorrectly). 
> This will persist until manual intervention, or the ASP audits.
> 
> Whatever the reason for a mismatch in destination state, it's easy to
> improve your chances of recovery by periodically auditing.

There should not be a race conditions.  SNMM should be delivered
once per SG and once per ASP.  As I said, we agreed that they are
per-SG and not per-SGP.  Avoiding race conditions between SGP was
one of the reasons that we considered back at M3UA-07 for doing
this.  So in your example, either SGP1 or SGP2 should send the SNMM
to ASP1, but not both as you describe.

If ASP1 receives DUNA + association failure from SGP2 (and nothing
from SGP1 per above), it is welcome to audit the AS.  Auditing the
AS on association failure to the SG  (as reliability of message
passing may have been compromised)  might be an idea; however, bear
in mind that the responds to the DAUD can equally be mangled by
association failure.  CORID provides procedures in this situation to
also avoid the missequencing of messages (both DATA and SNMM).

Nevertheless, the Audit procedure is there for ASP designers to use
as they see fit.  I never asked for it to be removed, and even
defended keeping it.  However, how that ASP uses the DAUD procedure
with relation to the local MTP- or SCCP-Users is implementation
specific.  The specs provide general audit procedures that allow
ASP designers great freedom in this respect.

> 
> >   
> >> The main risk would probably be a missing DAVA, since a missing DUNA
> >> would get discovered by a response DUNA if traffic is sent to the
> >> destination.
> >>     
> >
> > The easier test instead of DAUD is to have the SCCP-User send
> > traffic.  ITU specs require a DUNA every 8 or 10 messages for
> > N-PCSTATE.  
> If the ASP has another SG available, the DAUD may be a better choice.

True.

> It might, or it might not.  I think the odds of recovery are better if
> you send the DAUD.  For instance, possibly the nodal congestion will
> have abated by the time the DAUD comes in.

IMO SG should not be designed to discard SNMM messages.  ASPT
messages are for traffic management.  Unsolicited ASP Inactive Ack
is appropriate.  For finer grained conditions, see the ASPCONG
draft.

> >   
> I was concerned more with DAUD(*), which could require a lot more
> responses.  Also, management traffic and user traffic have different
> models.  Management traffic can be quite bursty, and can for short
> periods outstrip the expected user traffic.

As they should.  So, managements messages are sent with the highest
priority in the SS7 network.

Equal attention should be given to DAUD and its response.  However,
SNMM should take priority over traffic only to the ASP requesting
the audit.  Failure to enforce that results in a system that cannot
properly support multiple users.

--brian

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