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