RE: M2PA busy/lpo questions
"Davidson, Mark" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Brian, >Q1) I think it is clear that LSPO does not clear LSB, only LSBE does. It is clear how a busy clear condition is signaled, but not when it ends. There is a difference. > Under M2PA both PO and Busy conditions can exist at the same time. Works for me, but where does it say that? >Q2) I think buffered messages are buffered messages, regardless of > what condition prevailed when they were buffered. When M2PA exits v PO state and Busy still prevails, I think the text is clear with > regard to how data messages are treated before LSBE is sent or > received, in the passages you quoted. The text I quoted says NOTHING about buffering received msgs, so I don't see how it can be clear on the subject. Anyway, I think this is your interpretation: During local busy OR LPO (or both) buffer and do not acknowledge received MSUs. When BOTH conditions are cleared, process and acknowledged buffered messages. This is handled explicitly by PO procedures, for local busy an ack must be sent if there was at least one data message buffered (per other text requiring immediate ack). Local busy can continue during LPO and still be in effect after LPO ends. -Mark > >--brian > >Davidson, Mark wrote: (Wed, 02 Nov 2005 08:21:20) >> >> Flow control RFC text included at bottom for convenience... >> >> >> >> Trying to sort out Busy/Busy End and LPO/ LPO End interactions. >> >> >> >> The Level 2 flow control text doesn't say anything about buffering >> >> during local busy (just says don't ack), but I'm assuming that's >> >> the intent, i.e. to avoid retransmissions since M2PA doesn't >> >> retransmit. (I'm a little confused as to why LPOR needs those >> >> LSRs afterwards but LSBE doesn't, but that's not my real question.) >> >> >> >> Anyway, it gets really interesting when you have a (local) >> >> busy condition, then LPO condition. MTP2 spec is clear - Stop >> >> T5, move to PO state. When PO ends, MSUs may again trigger >> >> Busy condition, but if there's no traffic, then no Busy condition. >> >> >> >> The reverse, LPO followed by Busy does not occur in MTP2 because >> >> MSUs are discarded in LPO, so busy is not triggered. >> >> >> >> Question 1. In M2PA , should an LSBE be expected in the case where >> >> there is a local busy followed by LPO? It seems unnecessary to >> >> me - the LSPO message should imply an end to the Busy condition. >> >> Buffered Busy messages can become buffered LPO messages that are >> >> acked during LPO recovery. >> >> >> >> Question 2. Assuming traffic is buffered in M2PA during local busy, >> >> it is possible that the busy condition may not subside during a >> >> transient LPO condition. I.e. LPO ends but queues are still backed >> >> up. Should the Busy resume? What should be acked? Should we wait >> >> for the LSRs to be exchanged before sending LSB? >> >> >> >> -Mark Davidson >> >> >> > From the RFC: > > > > 4.1.5. Level 2 Flow Control > > > > The Link Status Busy message replaces the SIB message of MTP2. The > message SHOULD NOT be transmitted continuously. M2PA SHALL send a > Link Status Busy message to its peer at the beginning of a receive > congestion condition where MTP2 would send SIB. M2PA MAY send > additional Link Status Busy messages as long as that condition > persists. When the condition ends, M2PA SHALL send a Link Status > Busy Ended message to its peer. > > > > M2PA SHALL continue transmitting messages while it is in receive > congestion, but MUST NOT acknowledge the message that triggered the > sending of the Link Status Busy message, nor any messages received > before the sending of Link Status Busy Ended. > > > > When the peer M2PA receives the first Link Status Busy message, it > SHALL start the Remote Congestion timer T6 if there are messages in > the retransmission buffer awaiting acknowledgement (i.e., T7 is > running). M2PA SHALL stop the T7 timer if it is running. > Additional > Link Status Busy messages received while T6 is running do not cause > T6 to be reset and do not cause T7 to be started. While T6 is > running, T7 SHALL NOT be started. > > > > When the peer M2PA receives the Link Status Busy Ended message and > T6 > has not expired, it SHALL stop T6 (if T6 is running) and start T7 > (if > there are messages awaiting acknowledgement in the retransmission > buffer). > > > > The peer M2PA SHOULD continue receiving and acknowledging messages > while the other end is busy, but MUST NOT send User Data messages > after receiving Link Status Busy and before receiving Link Status > Busy Ended. > _______________________________________________ > Sigtran mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock [email protected] http://www.openss7.org/