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