Subject: [Sigtran] M2PA: resynchronization of sequence numbers after PO

From: Dario <[email-masked]>
Date: Thu, 15 Nov 2007 06:22:27 -0800 (PST)

Hi,

M2PA RFC 4165 state the following:

"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 is used 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).

   Upon receiving the Link Status Processor Recovered message, the M2PA
   in RPO SHALL respond with a Link Status Ready message on the User
   Data stream.  The BSN in the Link Status Ready message is set to the
   FSN of the last User Data message received (and not discarded) from
   the peer M2PA.

   Upon receiving the Link Status Ready message, the M2PA formerly in
   LPO SHALL respond with a Link Status Ready message on the User Data
   stream.  The BSN in the Link Status Ready message is set to the FSN
   of the last User Data message received (and not discarded) from the
   peer M2PA.

   M2PA (at both the LPO and RPO ends) uses the BSN value in the
   received Link Status Ready message to resynchronize its sequence
   numbers, if this is required by MTP2.  M2PA SHALL NOT resume
   transmitting User Data messages until it has sent the Link Status
   Ready message.

Could you please explain why the second Link Status Ready (stream 1) is
needed?
thanks!
Kind regards, Dario

-- 
View this message in context: http://www.nabble.com/M2PA%3A-resynchronization-of-sequence-numbers-after-PO-tf4812071.html#a13768339
Sent from the IETF - Sigtran mailing list archive at Nabble.com.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 15 Nov 2007 13:44:49 -0700

Dario,

Dario wrote:                                 (Thu, 15 Nov 2007 06:22:27)
-X--snip--X-
> Could you please explain why the second Link Status Ready (stream 1) is

To acknowledge the LSR sent from the other end and permit the peer to
again send MSUs.

--brian

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

---

From: Devayya BOPAIAH <[email-masked]>
Date: Thu, 15 Nov 2007 23:38:56 -0500

Brian,

Just curious,

What happens suppose the second link status ready message sent by the 
peer is not recieved by the host, may be bacause of some network reasons 
? I think this part is missing in rfc 4165.

Thanks,
devayya

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 16 Nov 2007 00:44:46 -0700

Devayya,

Devayya BOPAIAH wrote:           (Thu, 15 Nov 2007 23:38:56)
>    peer  is  not  recieved  by  the  host, may be bacause of some network
>    reasons ? I think this part is missing in rfc 4165.

SCTP is a reliable transport protocol: the message will
arrive or the association will fail.  In the later case,
RFC 4165 provides the procedures in the event that a
COMMUNICATIONS LOST indication is received by M2PA.

--brian

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

---

From: Devayya BOPAIAH <[email-masked]>
Date: Fri, 16 Nov 2007 04:29:33 -0500

So does this mean that the m2pa need not maintain a timer for second 
link status ready and entirely depends on SCTP ?for closing the 
communication. ?

regards,
devayya

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 16 Nov 2007 02:30:52 -0700

Devayya,

What timer?  There is no timer defined by Q.703 nor RFC 4165
for this message in this circumstance.  Nevertheless, if you
want to run a timer of your own, I suppose you can.

--brian

Devayya BOPAIAH wrote:                    (Fri, 16 Nov 2007 04:29:33)

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

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 16 Nov 2007 18:06:54 +0800

I think SCTP can ensure the messages be transferred without loss and wrong sequence( if required, in stream ), but SCTP CAN NOT ensure the messages be transferred in the time as ULP wished, which depend on the IP network.

So, if the ULP want to do something related to the time, it need a timer. 
  ----- Original Message ----- 
  From: Devayya BOPAIAH 
  To: [email-masked] 
  Cc: [email-masked] 
  Sent: Friday, November 16, 2007 5:29 PM
  Subject: Re: [Sigtran] M2PA: resynchronization of sequence numbers after PO

  So does this mean that the m2pa need not maintain a timer for second link status ready and entirely depends on SCTP ?for closing the communication. ?

  regards,
  devayya

    

--brian

------------------------------------------------------------------------------

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 16 Nov 2007 03:50:45 -0700

Xiangsong,

Xiangsong Cui wrote:                           (Fri, 16 Nov 2007 18:06:54)
> 
>    I  think  SCTP can ensure the messages be transferred without loss and
>    wrong  sequence( if required, in stream ), but SCTP CAN NOT ensure the
>    messages be transferred in the time as ULP wished, which depend on the
>    IP network.
> 
> 
> 

SCTP has many timers for this purpose.

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

---

From: Dario <[email-masked]>
Date: Fri, 16 Nov 2007 04:29:16 -0800 (PST)

Hi Brian,

Perhaps this was not clear from the description in section 4.1.4 of RFC,
however section 
5.4 brings more doubts:
In figure 16, the "B"-side (the side that receives Link Status Processor
Recovered message),
after receiving LS PR and after sending LS Ready (stream 1) message "has
completed synchronization
of sequence numbers and has sent LS Ready, so it is able to resume sending
data at this point with
the new sequence numbers".

A side (the side that recovered from PO) sends the second LS Ready (stream
1) but it seems noone
does anything with that message: if the purpose of synchronization was to
send the last received BSN
to synchronize FSNs at remote peer, then two messages seem to be sufficient?

Best regards, Dario

-- 
View this message in context: http://www.nabble.com/M2PA%3A-resynchronization-of-sequence-numbers-after-PO-tf4812071.html#a13792229
Sent from the IETF - Sigtran mailing list archive at Nabble.com.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 16 Nov 2007 10:16:07 -0700

Dario,

What the side sending the first LSR does not know until it
receives an LSR is whether its choice of sequence number is
acceptable to the peer.  Once an LSR is received from the peer
it is known that not only have both sides chosen a new sequence
number, but that choice is acceptable at both sides of the link.
It is better to await this acknowledgement before restarting
traffic.  In the event that traffic is restarted early and the
peer does not accept the new sequence number (for example, it is
unable to synchronize at all), the link will be placed out of
service and the sender risks message lost and missequencing by
sending data when the situation could have been avoided.
Therefore, wait until you receive LSR before restarting traffic.

--brian

Dario wrote:                                                        (Fri, 16 Nov 2007 04:29:16)

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

---

From: Dario <[email-masked]>
Date: Tue, 20 Nov 2007 07:32:34 -0800 (PST)

Hi,
two more questions:
1. If both sides are in PO and one processor recovers and sends LS PR.
Should the other side respond with 
LS Ready (stream 1) although it is locally in PO?
2. again, both sides are in PO and both sides recover - each side sends LS
PR. Should both sides exchange just one pair of LS Ready (stream 1) messages
or should they perform resynchronization sequence independently?

thanks!
Regards, Dario
-- 
View this message in context: http://www.nabble.com/M2PA%3A-resynchronization-of-sequence-numbers-after-PO-tf4812071.html#a13858954
Sent from the IETF - Sigtran mailing list archive at Nabble.com.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Nov 2007 10:40:48 -0700

Dario,

Dario wrote:                                 (Tue, 20 Nov 2007 07:32:34)
> LS Ready (stream 1) although it is locally in PO?

No.  Ala Q.703 it sends LS PR when it recovers and only then both
sides exchange LSR.  Neither side resynchronizes until the link
becomes unblocks which requires no processor outage (local or remote).

> or should they perform resynchronization sequence independently?

Each side resynchronizes independently per Q.703.  The sequence when the
last terminal recovers is the same as though only one processor was out.

--brian

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

---

From: Dario <[email-masked]>
Date: Wed, 21 Nov 2007 03:59:57 -0800 (PST)

Hi Brian,

so if I understood correctly, the resinchronization takes place only when
there is no PO on either
side.
it would be good to clarify that in RFC since statement in RFC4165, section
4.1.4 has not been clear to me:
" Upon receiving the Link Status Processor Recovered message, the M2PA in
RPO SHALL respond
with a Link Status Ready message on the User Data stream."

This is then coniditionaly true, only if there is no local PO on that M2PA
side.

Regarding second question, how many LS Ready messages are then exchanged?

A side sends LS PR.
B side sends LS PR.
It seems to me that each side sending one LS Ready (stream 1) is sufficient
to resynchronize the sequence numbers.
Or is it 4 LS Ready messages (each side sending two LSR messages?).

thanks!
Best regards, Dario

-- 
View this message in context: http://www.nabble.com/M2PA%3A-resynchronization-of-sequence-numbers-after-PO-tf4812071.html#a13875827
Sent from the IETF - Sigtran mailing list archive at Nabble.com.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 21 Nov 2007 07:14:44 -0700

Dario,

Sorry, I was wrong.  Each side should respond LSR regardless of the state of
the local processor; however, because the local processor is out on the last
side recovering, it cannot necessarily synchronize sequence numbers (it takes
a flush from MTP3 to do that).

See Test Case 3.4.2 "RPO during LPO" and Test Case 3.4.3 "Clear LPO when "Both
processor outage" in draft-bidulock-sigtran-m2pa-test-08.txt

(It is no longer on the IETF servers, darn it expired again, but you can get a
copy here:

  http://www.openss7.org/docs/draft-bidulock-sigtran-m2pa-test-08.txt

)

--brian

Dario wrote:                                  (Wed, 21 Nov 2007 03:59:57)

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

---

From: sdjugum <[email-masked]>
Date: Sun, 18 Nov 2007 23:26:13 -0800 (PST)

Hi, Brian!

I am a little confused with statements "sequence number unacceptable" and
"unable to synhronize". Could you please explain what are the situations
when sequence number would be unacceptable for the peer or when the peer is
not able to synchronize at all?

Thanks.

Best regards,
Sasa

Brian F. G. Bidulock wrote:
>> to synchronize FFrom [email-masked] Tue Nov 27 11:41:11 2007
Date: Sun, 18 Nov 2007 23:26:13 -0800 (PST)
From: sdjugum <[email-masked]>
To: [email-masked]
Subject: Re: [Sigtran] M2PA: resynchronization of sequence numbers after PO

Hi, Brian!

I am a little confused with statements "sequence number unacceptable" and
"unable to synhronize". Could you please explain what are the situations
when sequence number would be unacceptable for the peer or when the peer is
not able to synchronize at all?

Thanks.

Best regards,
Sasa

Brian F. G. Bidulock wrote:
>> View this message in context:
>> http://www.nabble.com/M2PA%3A-resynchronization-of-sequence-numbers-after-PO-tf4812071.html#a13792229

-- 
View this message in context: http://www.nabble.com/M2PA%3A-resynchronization-of-sequence-numbers-after-PO-tf4812071.html#a13828923
Sent from the IETF - Sigtran mailing list archive at Nabble.com.

---

From: sdjugum <[email-masked]>
Date: Fri, 16 Nov 2007 10:29:32 -0800 (PST)

Hi Brian,

Since the question remained open I would just like to repeat it so that it
is not left unanswered.

The example metioned below clearly indicates that side B uses BSN received
in LS Processor Recovered message to sSNs at remote peer, then two messages seem to be
>> sufficient?

---

From: sdjugum <[email-masked]>
Date: Fri, 16 Nov 2007 10:29:32 -0800 (PST)

Hi Brian,

The example metioned below clearly indicates that side B uses BSN received
in LS Processor Recovered message to synchronize it's sequence numbers and
that it begins sending messages after it has sent LSR (stream 1). 
So, the question is - what should it do at reception of LSR (stream 1) from
peer? Example clearly shows that LSR is ignored and that BSN received in it
is not used.

So, which message should be used for synchronization and sending resume at
side leaving RPO - LS PR or LSR (stream 1)?

Best regards,
Sasa

-- 
View this message in context: http://www.nabble.com/M2PA%3A-resynchronization-of-sequence-numbers-after-PO-tf4812071.html#a13797998
Sent from the IETF - Sigtran mailing list archive at Nabble.com.

ynchronize it's sequence numbers and
that it begins sending messages after it has sent LSR (stream 1). 
So, the question is - what should it do at reception of LSR (stream 1) from
peer? Example clearly shows that LSR is ignored and that BSN received in it
is not used.

So, which message should be used for synchronization and sending resume at
side leaving RPO - LS PR or LSR (stream 1)?

Best regards,
Sasa

-- 
View this message in context: http://www.nabble.com/M2PA%3A-resynchronization-of-sequence-numbers-after-PO-tf4812071.html#a13797998
Sent from the IETF - Sigtran mailing list archive at Nabble.com.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 27 Nov 2007 10:52:04 -0700

sdjugum,

Syncrhonization is not performed only at level 2.  It requires a signal from
Level 3 to initate resynchronization (flushing of the retransmit and transmit
buffers).  Upon receiving LSR the peer may by "unable to synchronize" because
it discovered upon going to issue remote processor recovered signal to its
local MTP3 that MTP3 is unreachable.

--brian

sdjugum wrote:                                   (Sun, 18 Nov 2007 23:26:13)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 27 Nov 2007 11:24:53 -0700

sdjugum,

Figure 16 is consistent with the text in section 4.1.4.  Each side shall not
send data messages until it has sent LSR (and then only when other conditions
permit).  It is, however, better to wait until LSR is both sent and received
before starting traffic.  Consider the following:

   LSPO -----------\
   LSPR -----------\\
   LSPO -----------\\\
                    \\\--------> LSPO ---> RPO
                     \\--------> LSPR ---> RPR  ------+
                      \--\                            |
                       /--\----- LSR  <--- Continue <-+
                      //---\---- DATA
                     ///----\--- DATA <--- DATA
    LSR <-----------///      \-> LSPO ---> RPO
   DATA <-----------//
   DATA <-----------/

Which is sending data immediately after sending LSR.  Note that the DATA is
now in the RTB and therefore will be lost on changeover.

Contrast that with the following:

   LSPO -----------\
   LSPR -----------\\
   LSPO -----------\\\
                    \\\--------> LSPO ---> RPO
                     \\--------> LSPR ---> RPR  ------+
                      \--\                            |
                       /--\----- LSR  <--- Continue <-+
                      /    \
                     /      \    (TB) <--- DATA
    LSR <-----------/        \-> LSPO ---> RPO

Which is waiting for received LSR before sending data.  Note that the DATA is
either in Level 3 or in the TB at Level 2 and is therefore not lost on
changeover.

Therefore, waiting for both LSR sent and received reduces message loss and
missequencing.

All that the RFC requires is that DATA not be sent _before_ sending LSR, it
does not place any requirements on how long one waits after sending LSR before
restarting traffic.

--brian

sdjugum wrote:                                   (Fri, 16 Nov 2007 10:29:32)

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