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/