Re: [M2UA]Clarify M2UA flow control/congestion procedure
"Brian F. G. Bidulock" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Organization | http://www.openss7.org/ |
| Message-ID | <[email protected]> |
Steven, An SG implementation could, for example, detect flow control toward the ASP at SCTP by checking and thresholding the amount of send buffer fill for SCTP. Another is to set lifetimes on SCTP messages and detect messages that are acknowledged beyond the reasonable lifetime. Either could be translated into receive congestion or processor outage as you surmize. Processor outage is better because not only data transmission but control between MTP2 and MTP3 has been impaired, and simply because some operators require that SS7 equipment not issue SIB. Another approach would be to have one mechanism (e.g. M2UA HEARTBEAT on an IID stream) cause SIB (for that IID) but another mechanism (e.g. M2UA HEARTBEAT on stream 0) detect command flow control which could separately trigger SIPO (for all IIDs). Application HEARTBEAT is likely the most portable approach. --brian ZHOU Minggang wrote: (Wed, 01 Jul 2009 09:48:20) > > Hello Brian, > > According to RFC3331 procedures, which reads: > 1.5.6 Flow Control / Congestion > > It is possible for the M2UA layer to be informed of the IP network > congestion onset and abatement by means of an implementation > dependent function (i.e. an indication from the SCTP). The handling > of this congestion indication by M2UA is implementation dependent. > However, the actions taken by the SG should be in accordance with the > appropriate MTP specification and should enable SS7 functionality > (e.g. flow control) to be correctly maintained. > Question: As a SGP, How to implement this function? Is it appropriate for SGP > to send out SIB or SIPO? > Which choise is better? Or is there any other advice? > Thanks a lot! > > Steven -- Brian F. G. Bidulock [email protected] http://www.openss7.org/