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/