Re: Re: Question related with DAUD Message

Luke,

Luke Cai wrote:                                 (Fri, 02 Feb 2007 03:55:32)
> The problem is if the ASP totally depends on SG for the destination status,
> the SG has to have a way to guarantee that:

> 1) DAVA and DUNA won't get lost unless there is a bug in SG, however,
> although it is unlikely, we do need to have a "plan B", if it did happen.
> (It is possible that SG drops some messages due to defected overload
> management but does manage to recover without reset the link) 

An intelligent M3UA or SUA user at the ASP can protect against loss
by simply marking unavailable destinations as available ever so
often.

However, a legacy MTP- or SCCP-User will expect that the MTP or SCCP
is indeed reliable in what it reports.  That is simply the nature of
the MTP/MTP-User and SCCP/SCCP-User interface as defined by the
Standards and for which M3UA and SUA claim transparency.

The existing audit procedures provide the ASP with the means to
query the status of destinations.  Their precise use in relation to
the MTP- or SCCP-User at the ASP is a local implementation specific
matter.

> 2) After a association restarts, ASP would probably reset all the
> destination status that associated with this M3UA link to "unknown", and SG
> will have to send all the destination status to the ASP; the problem is if
> the SG uses some kind of default route, there is no way SG would know which
> destination status needs to report to ASP, in this case, ASP should probably
> send the DAUD to find out the status of destinations it cares.

Well, to follow SS7 and appropriate M3UA procedures, the ASP should
reset all the destination status to "available/uncongested/unrestricted"
(because this is the normal state of all destinations in the SS7
network).  If the ASP wishes, it can audit, or it can allow users to
blindly send messages to any destination.  If the SG does not want
to receive blindly sent messages, it can send status to newly
available ASPs per RFC4666/4.5.1:

   For the particular case that an ASP becomes active for an AS and
   destinations normally accessible to the AS are inaccessible,
   restricted, or congested, the SG MAY send DUNA, DRST, or SCON
   messages for the inaccessible, restricted, or congested destinations
   to the ASP newly active for the AS to prevent the ASP from sending
   traffic for destinations that it might not otherwise know that are
   inaccessible, restricted, or congested.  For the newly activating ASP
   from which the SGP has received an ASP Active message, these DUNA,
   DRST, and SCON messages MAY be sent before sending the ASP Active Ack
   that completes the activation procedure.

There is nothing in RFC 3868 precluding this behaviour of the SUA SG.
(Note that ASP Active Ack can be sent on stream 0 but SNMM and DATA
are not sent on stream 0, so even SNMM and DATA sent after ASP
Active Ack can arrive before ASP Active Ack.)

> So my personal opinion is for ASP to send the DAUD whenever it feels
> necessary (such as link restart). It is a safe way to make sure the ASP
> always know the most recent destination status with a little bit overhead,
> because if you have an ASP, you probably don't want to totally rely on the
> external NEs, especially there are third-party's products.

As the SG is actually connected to the SS7 network and must conform
to strict and rigorous standards, conformance and compliance
certification I would think it highly unlikely that a fielded SG would
be as unreliable as you portray.

--brian

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