Re: M3UA ASP UP message format

"Brian F. G. Bidulock" <[email protected]>
Newsgroups gmane.ietf.sigtran
Organization http://www.openss7.org/
Message-ID <[email protected]>
Edwin,

If you see traces like this every two seconds or so (or T(ack)):

  M3UA ASPUP
  M3UA ASPUP ASPUP
  M3UA ASPUP ASPUP ASPUP
  M3UA ASPUP ASPUP ASPUP ASPUP
  etc.

then the fact that the peer crashed probably means that the SCTP
association is dead and the sender just doesn't know about it yet.
Under the right conditions it could take several minutes for the
SCTP sender to mark the association down.

An SCTP stack that performs receipt verification could inform the
M3UA layer that the original ASPUP has not even been acknowleged
by SCTP at the peer and avoid sending all these ASPUPs.

Because there are so many ways in which the peer can crash (SCTP
alive M3UA dead, IP alive SCTP dead M3UA dead) it appears that the
implementation is behaving correctly.  It certainly is behaving
better than the peer that crashed.

--brian


[email protected] wrote:              (Sat, 11 Feb 2006 16:01:01)
> Brian,
> 
> Actually the traces were taken after the peer host crashed. 
> 
> Since the M3UA ASPUP message is sent only after the lower layer SCTP
> association is established (SCTP INIT and SCTP INIT ACK), does the
> sending of the M3UA ASPUP message in this scenario indicate that the
> SCTP association has been already established or is that undeterminable
> on account of the peer host crashing. 
> 
> Does it mean that the behavior of the ASP client in this case is normal
> considering that the host had crashed? 
> 
> Thanks 
> Edwin
> 

-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.