M2PA busy/lpo questions

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