Subject: RE: [SIGTRAN] M2PA - Local Processor Outage

From: Hecht Martin <[email-masked]>
Date: Wed, 11 Feb 2004 10:09:40 -0500

Brian,

Thank you for your answer.  Your answer leads me to further questions:

1) M2PA is sending User Data messages during LPO and the peer is ACKing
these messages.  This implies, according to the spec, that the M2PA in LPO
is processing the ACK but still buffering the incoming User Data messages.
Is this correct?

2) How "deep" should the buffering be?  If the buffer becomes full does M2PA
start to discard incoming messages?

3) Does resynchronization imply retransmission?  What of the case where
buffers were discarded due to "item 2 above" or some other reason such as a
packet in error? What if the peer provides a BSN that is less than the last
FSN transmitted?  Does M2PA retransmit at this point?

And a general question concerning the fact that there is no retransmission.
If a packet is discarded, due to Bad BSN or other reason, this packet is
lost?

Thanks for your time,
Martin

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, February 10, 2004 5:37 PM
To: Hecht Martin
Cc: SIGTRAN Mailing List (E-mail)
Subject: Re: [SIGTRAN] M2PA - Local Processor Outage

Hecht,

Hecht Martin wrote:
(Tue, 10 Feb 2004 16:00:05)
> To whomever is interested in answering this enquiry:
> 
> In Section 4.1.4 (draft 11) it states:
> 
> 	While in a local processor outage (LPO) condition:
> 
> 	   (c) M2PA SHOULD continue to transmit messages that have been sent
> by its upper layer MTP3.
> 
> Further on it states:
> 
> 	When the local processor outage condition ends,....
> 
> 	M2PA SHALL NOT resume transmitting User Data messages until it has
> received the Link Status Ready message.
> 
> So, I am trying to understand these two statements.
> 
> Does it mean:
> 
> a) That M2PA should transmit messages received from MTP3 prior to the LPO
> indication. But not transmit messages from its MTP3 received after LPO,
> until LPR (Processor Recovered).  Then, when the Ready is received to
start
> transmitting them.
> 
> or
> 
> b) That transmission continues throughout the LPO condition, but that when
> M2PA sends the Processor Recovered Link Status Message it must suspend
> transmission until the Ready is received from the peer.  At that time
> transmission will resume.

This one.  LSPR is sent in the data stream and no messages should be sent
after the LSPR until LSR is received (also in the data stream) and sequence
numbers sychronized.

Maybe we should have said more explicity that sending of data messages is
suppressed between sending of LSPR and reception of LSR.

> 
> or
> 
> c) Something else is meant.
> 
> Note:
> In our implementation of SS7 MTP2 messages are not transmitted at all
during
> LPO.  The only reason MSUs would be pending transmission (on the Transmit
> Buffer Queue) when the LPO started would be that the RTB was full and the
> LPO indication came prior to being able to transmit those messages..

The point is that you SHOULD continue to send those messages in the TB after
the LPO condition, unlike Q.703 which blocks them in the TB because it must
send continuous SIPO.  So, it is recomended to send messages during LPO.

In addition (c) in 4.1.4 was meant to handle the case (in some
implementations
where the data path and control path are independent) where there is a local
processor outage (control path), but M2PA continues to receive messages from
MTP3 (data path).

--brian

> 
> Thank you,
> Martin Hecht
>  
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
______________________________________________________________________
  This email message has been scanned by PineApp Mail-Secure and has been
found clean.

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Feb 2004 14:15:45 -0700

Hecht,

Hecht Martin wrote:                                                                  (Wed, 11 Feb 2004 10:09:40)
> is processing the ACK but still buffering the incoming User Data messages.

Yes.

> start to discard incoming messages?

No, messages are not discarded.  If the receiving M2PA can no longer
buffer messages it should stop servicing the read side of SCTP,
resulting in a closed arwnd at the peer and the peer's SCTP send buffer
will fill.  This should not persist for long (just while the LSPO is in
transit) because the peer M2PA will inform MTP3 of remote processor
outage and MTP3 will block the link.  To avoid link failure due to a
transmit congestion situation before LSPO is indicated, SCTP buffers
should have same sizing on both ends of the link.  The size of the M2PA
RB is not really the issue.

> FSN transmitted?  Does M2PA retransmit at this point?

M2PA does not retransmit.  SCTP (or MTP3) performs all necessary
retransmissions.

> If a packet is discarded, due to Bad BSN or other reason, this packet is

Packets are not discarded, in general.  A bad BSN is a strange event and
would likely be due to a broken peer or a late arriving message from a
restarted peer (where M2PA restarts but SCTP does not) and is likely a
cause for link failure.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/