Re: M2PA busy/lpo questions

Mark,

A couple comments:

Q1) I think it is clear that LSPO does not clear LSB, only LSBE does.
   Under M2PA both PO and Busy conditions can exist at the same time.

Q2) I think buffered messages are buffered messages, regardless of
   what condition prevailed when they were buffered.  When M2PA exits
   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.

--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/