Re: M3UA : How to deal whit Unexpected ASPSM/ASTM Message (Jacky Chen)
"Brian F. G. Bidulock" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Organization | http://www.openss7.org/ |
| Message-ID | <[email protected]> |
chen.puran, [email protected] wrote: (Thu, 21 Jun 2007 14:17:52) > Thanks,brain > your anser: > > 1) Quite simply, when the ASP receives an unsolicited ASP Inactive Ack > message > it places the ASP in the ASP-INACTIVE State for the AS indicated in the ASP > Inactive Ack message. If the ASP was not already in the ASP-INACTIVE State > for the AS indicated in the unsolicited ASP Inactive Ack message, then the > ASP should initiate steps to return the ASP to the previous state for the > AS. > If that previous state was ASP-DOWN (for _all_ AS), the way to initiate > returning the ASP to the appropriate state for the AS is to send an ASP > Down > message. > > my question: > jack chen:if do as you say,Then One unsolicited ASP Inactive Ack(for > one AS) message will affet all AS(s)'s > status,it is good idea? No, because the ASP is ASP-DOWN for all the other AS. See the state diagram in RFC 4666 Figure 3 and the description above the diagram and the description in 4.3.4.1. Note that the only transition from ASP-INACTIVE to ASP-DOWN is using the ASP Down message which results in the ASP moving to the ASP-DOWN state for _all_ AS. So, if a given AS is in the ASP-DOWN state and the ASP receives an ASP Inactive Ack, _all_ the AS are in the ASP-DOWN state. Sending an ASP Down message in this case has precisely the desired effect. > > 2) Completely reasonable: the SGP is required to send ASP Up Ack in > response to ASP Up, in which case the ASP Up Ack is always expected > by the ASP, cf. RFC 4666 4.3.4.1. The only reason for an unexpected > ASP Up Ack is some sort of error, in which case the procedure will > attempt to properly resynchronize state. > > my question: > jack chen:because it is unexpected message,we can not think it is > expected message just only of sort ?! Whenever there is an ASP Up Ack outstanding for sent ASP Up message (no matter how many ASP Up messages were sent without an ASP Up Ack response), the ASP UP Ack message is "expected", because the specification REQUIRES the SGP to send it. > > maybe because of the error of the sgp' softward code. > so I think ASP should make itself stronger and not to affect all > AS's Status. Read the procedures from 4.3.4.1 for the _SGP_side. When the SGP sends ASP Up Ack it is required to place all of the AS for the ASP in the ASP-INACTIVE state. If the ASP does not do the same thing whenever it receives an ASP Up Ack, its state will not match that of the SGP. So, in fact the ASP makes itself stronger by synchronizing its state with the SGP in such an unexpected event rather than blindly assuming that the SGP should know its state by some telepathic means outside the protocol. --brian -- Brian F. G. Bidulock [email protected] http://www.openss7.org/