Re: SIGTRAN Plugtest Day 3

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

Erickson, Mark wrote:                                                            (Thu, 19 Apr 2007 03:43:11)
> Brian:
> 
> It's not a question of SCTP.  What if the first one is refused by the SG
> for some reason - why shouldn't the ASP keep resending to try to bring
> the ASP into service?

Well, if the first one is refused, then an Error message MUST be
returned identifying the reason (e.g. Management Blocking).  If the ASP
considers this refusal to be of a transient nature, it is welcome to
issue another ASP Active attempt at any time (even immediately).  If the
ASP would like to simply ignore such ERROR messages and fall back on a
Tack timer, it is also welcome to do so.  However, I do not think that
it can be recommended that the timer be used when the Error message will
do and so the SHOULD keyword does not apply.

Tack was intended for the case where _no_ reply comes from the SGP
within the timer.  In this case either there is a significant delay on
the association (longer than Tack RTT) or the SGP does not comply with
the ASP Active procedures.  Both indicate a more serious problem and
that is why we said that Layer Management could be informed instead of
retransmitting another ASP Active into a black hole.

I don't think that recommending retransmission solves issues with SGP
that refuse to send Error messages or ASPs that refuse to process them.

--brian

> 
> If the SGP has been configured such that it refuses the ASP-ACTIVE
> request, if an operator changes the configuration as the SGP to permit
> the SGP to accept the request and bring the ASP active, there is no way
> to signal the ASP what has occurred at the SG, and both sides should not
> have to rely on some mechanism that forces the ASP to return to a DOWN
> state (such as restarting the association) to cause the process to be
> restarted automatically or require some manual intervention at the ASP
> end.
> 
> Mark
> 

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