Timer T7 and T6 in SIGTRAN

aditi someshwar <[email protected]> Fri, 29 Jul 2011 18:15:41 +0530
Newsgroups gmane.ietf.sigtran
Message-ID <CAH62GXRRJC59RPE9btxoYD6YhEVpDBCYFXOJtdezKKT3o-yG+Q@mail.gmail.com>
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

_______________________________________________
Sigtran mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sigtran