Re: Question related with DAUD Message

Andrew,

I am a little confused by your statements.  A couple of comments:

Andrew Booth wrote:                        (Wed, 31 Jan 2007 11:17:54)
> I think the ASP can send DAUD in any way it sees fit, according to the RFC.
> 
> The following comments are my own and are not specified in the RFC.
> 
> I think assuming that state is always synchronized is a dangerous
> assumption.  For instance, what if the SG is in overload and discards a
> DAVA?

SCTP is a reliable transport.  DAVAs don't go missing without
loss of the association.

> What if there's a bug on one end or the other?

Bugs can cause failures: serious bugs, serious failures.
Rigorous software test and field testing comes to mind ;)

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

> 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.  Nevertheless, back to the first question, why would
an SG "miss" a DAVA?

I do not understand why the SG would be designed in such way
that it gets a positive response to an SST and yet somehow
"discards" the DAVA.

If it is going to lose simple management state it certainly
cannot provide service and the better course of action would be
sending ASP Inactive Ack, ASP Down Ack, or dropping the SCTP
association.

You see, if it cannot issue the DAVA message, how can it expect
to be able to handle data traffic for the AS?  If it cannot
issue the DAVA message, how is it to issue a DAUD response?

> >From an operational standpoint I'd be careful sending DAUD with a big
> wildcard, since it's difficult to estimate how many responses you might
> get and how fast, so it's hard to avoid potential overloads.  Also, you
> won't necessarily know when you have all the responses (if you care).

If an SGP cannot handle sending DAUD responses for, say, 1024
point codes, how could it expect to handle traffic for same?
(E.g, 80 messages per second for each of the 1024 point codes.)
Management message are rare compared to the data traffic and
only represent a very small percentage of the engineered
bandwidth use between SGP and ASP.  If there is insufficient
bandwidth for an SGP to send management messages, there is
insufficient bandwidth for normal operation.  In that case,
"delaying" (I don't agree with discarding) a DAVA message is a
good thing.

> 
> Other than that, it's more bandwidth efficient to send multiple affected
> PCs in one message, but that's only a concern if you're running over
> bandwidth constrained networks or auditing many PCs.  So, take your pick.

Again, management messages is a very small fraction of the
engineered bandwidth for data traffic.  If management messages
cannot be exchanged, neither can normal traffic.  Both the SGP
and ASP have all the protocol means necessary for indicating
same (ASP Inactive procedures, ASP Down procedures, and SCTP
communications lost procedures.)

--brian

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