Subject: RE: [Sigtran] M2PA : LS messages on stream 0

From: [email-masked]
Date: Tue, 23 Jul 2002 09:23:43 -0400

Hello Anshoo,

I have encountered several scenarios of out-of-sequence link status
messages during testing of my M2PA v5 implementation.

I addressed the problem in the following manor:

1) The FSN of a link status message is ignored.
2) The FSN of a user data message must be in-sequence,
otherwise it is a protocol error.
3) The BSN of any message is validated. If valid, it is
used to drain the retransmit queue (an ACK) and update
link L2 data. If not valid, then the BSN is simply ignored.

Regards,

Jeff

[email-masked]@ietf.org on 07/23/2002 02:38:39 AM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  RE: [Sigtran] M2PA : LS messages on stream 0

Hi all,

There is an issue with having two different streams for MSU and LSU in
M2PA.
The issue relates to FSN and BSN sequencing that are being sent along with
LSU
as well as MSU.
LSUs and MSUs are sent on different SCTP Streams and no guarantee on the
order
of arrival at the Peer can be given.
This could cause the out of order arrival of FSN and BSN values at the
Peer,
which in turn would lead
to rejecting of the current association according to M2PA Draftv5.

Here is a short example to illustrate this:

          A                        B
       +--------+                     +---------+
       |        |                     |         |
       |        +---------------------+         |
       +--------+                     +---------+

1) MSU with FSN values 1, 2, 3 and BSN value 0 are sent from A to B. The
message
is received at B.
2) MSU with FSN value 1 and BSN value 3 is sent from B to A. The message is
received at A.
3) Some time elapses with no message from B, A now sends an INSERVICE LSU
to B
with FSN as 3 and BSN as 1. This message is sent on Stream 0
    and is in transit on the Network.
4) B sends another MSU with FSN as 2 and BSN as 3. The message is received
at A.
5) A sends another MSU with FSN as 4 and BSN as 2. The message is received
at B.
6) The LSU that had been sent in (3) now reaches B and has both its FSN and
BSN
values out of sync. According to the current draft the association should
be
discarded.

I guess the above consideration was missed out while adding FSN and BSN to
Dual
Stream M2PA.
Now either we should allow only a single stream for a link or else we
should
explicitly define a mechanism for handling the above scenario.

Regards
Anshoo.

----- Original Message -----

Al Varney <[email-masked]> on 07/23/2002 08:44:16 AM

To:   [email-masked]

Subject:  RE: [Sigtran] M2PA : LS messages on stream 0

At 11:28 AM 7/22/02 -0400, Tolga Asveren wrote:
>And here an example where using stream0 for LS messages is not a good
idea:
>(although in my opinion, to have a model where responsibilities of layers
>are not mixed is a more important argument)

    I don't believe there is a "right" answer to this particular issue --
either one works well, considering the inadequacy of STCP to exactly
emulate a "wire".  But since you are the one arguing "layer purity", I
think you need reconsider your argument ... see below.

>A was sending Data to B. Then it decides to send LS OOS, and it is
delivered
>to the receiving M2PA before some Data messages, which were sent before LS
>OO. So, those messages, which have already reached receiving SCTP
>successfully won't be delivered to M2PA. So, after changeover they need to
>be retransmitted. If sequence was preserved -like in the case with a
>physicall wire-, there wouldn't be a need to retransmit those, because
>during changeover, B would inform A that it received those messages.

    But the exact same thing can happen with SS7 MTP2 -- if you respect the
protocol layering.  If A (MTP3 layer) sends "Data" to B, MTP2 will
typically place "Data" in the transmit buffer of the specified link.  If A
(MTP3 layer) then indicates "send LS OOS" for the same link, the MPT2
priority rules state that LS OOS will be sent IN FRONT OF the "Data"
message.  And thus "Data" will not be delivered to the far-end MTP3 -- nor
will those messages in the re-transmit buffer (or SCTP equivalent).  (This
presumes "Data" isn't in the process of being sent when the LS OOS
indication arrives at MTP2.)

    So if you look at it from the MTP3 layer rather than the wire itself
(Layer 1), you have the same potential out-of-order processing possible
with both SS7 and with M2PA using Stream 0 for LS messages.  SS7 does NOT
promise to deliver LSSUs and MSUs in the same order indicated by the
sending MTP3.

    I don't claim there aren't other arguments for a single-stream for all
M2PA data (simplicity of reading 1 stream vs. 2, for example).  I'm not
sure they are sufficient to remove the ability to "expedite" LS messages
using Stream 0.  (Presuming SCTP will send a new Stream 0 message before a
whole buffer full of Stream 1 messages, that is.)

Al Varney

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

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

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

---

From: Al Varney <[email-masked]>
Date: Tue, 23 Jul 2002 11:43:50 -0500

>link L2 data. If not valid, then the BSN is simply ignored.

    I think you should address the "problem" by following Q.703 
requirements.  Both the FSN AND BSN of LSSUs are effectively ignored by 
MTP2 (see Q.703 5.2.2(b) and Figure 14, Sheet 2 for BEC method and Q.703 
section 6.3.1 and Figure 16, Sheet 2 for PCR method).

    So you should not validate the FSN or the BSN of any LS message, per 
Q.703.  M2PA doesn't contradict this, does it?

Al Varney

---

From: Tom George <[email-masked]>
Date: Thu, 25 Jul 2002 15:10:02 -0500

Al,

I think you are right that the FSN should be ignored for the Link Status
messages. The FSN should be bumped up only for the User Data messages.

It was intended that the BSN in the Link Status message be used to ack
messages just like the BSN in the User Data messages. 

tomG.

-- 
* Tom George          972-519-3168           [email-masked]   *
* PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *