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

From: Tom George <[email-masked]>
Date: Mon, 01 Mar 2004 09:13:24 -0600

The next time I get to edit the document, I will add the last sentence 
to this paragraph in 4.1.4 (version 11):

=====
When the local processor outage condition ends, M2PA SHALL send a Link
Status Processor Recovered message to its peer on the User Data
stream. This message is used to signal the end of the processor outage
condition, instead of an MSU or FISU as in MTP2. The BSN in the Link
Status Processor Recovered message is set to the FSN of the last User
Data message received (and not discarded) from the peer M2PA. *** M2PA
SHALL cease transmitting User Data messages after sending the Link
Status Processor Recovered message, until it has received the Link
Status Ready message (see below). ***
=====

tomG.

Brian F. G. Bidulock wrote:
> 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
> 
> 

-- 
* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
*   I actively disclaim speaking for Alcatel.  I do not purport to    *
*   advertise or represent its position, operations, or activities.   *

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