Subject: [Sigtran] Timer T7 and T6 in SIGTRAN

From: aditi someshwar <[email-masked]>
Date: Fri, 29 Jul 2011 18:15:41 +0530

Hi all,

Can somebody suggest one example of how SCTP determines that a congestion
has been encountered in the receiving direction?

Once SCTP does find congestion condition and communicates the same to M2PA,
& hence, sends Link Status Busy message to the peer, it is specified
(RFC4615, sec 4.1.5) that the peer shall start Timer T6. Before T6 expires,
the initiating node’s SCTP must send (& keep doing so periodically) another
"Link Status Busy" message.

It appears that unlike in MTP2, no timer like T7 is to be kept active at the
peer when M2PA is being used, & therefore, AS LONG AS (as many times as it
does) initiating end keeps sending Link Status Busy messages WITHIN T6
expiry, the LINK (in other word – the SCTP Association) shall NEVER be
forced “out of service”. Is this understanding correct?

Is there any situation specified when the peer is NOT supposed to even start
timer T6? Independent of all this, when the RFC4615 says (in section 4.1.5)
that “  . . . . . . . . T7 SHALL expire”, WHAT IS THE NEXT STEP AFTER T7
expires?? Is it that the link shall be considered OOS (or, for that matter,
would steps be initiated to put the link OOS?)

Thanks and Regards,
Aditi

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 29 Jul 2011 13:02:00 -0600

aditi,

aditi someshwar wrote:                        (Fri, 29 Jul 2011 18:15:41)
>    It appears that unlike in MTP2, no timer like T7 is to be kept active
>    at the peer when M2PA is being used, & therefore, AS LONG AS (as many
>    times as it does) initiating end keeps sending Link Status Busy
>    messages WITHIN T6 expiry, the LINK (in other word the SCTP
>    Association) shall NEVER be forced out of service. Is this
>    understanding correct?

No, it's not correct.  M2PA uses T7 in the same way as MTP2.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/