Subject: Re: [Sigtran] M2PA v6: Two Out of Three Valid BSN

From: [email-masked]
Date: Tue, 8 Oct 2002 15:48:54 +0530

Brian,

The situation you have described certainly need to be accomodated, but 2 out of
3 BSN is not a solution to this problem.
Firstly, FSN would also be out of sequence here and secondly the Number of
Packets stuck on the network cannot be assumed as 1.
So, I will suggest that we should not let this scenario be a criteria for not
removing 2 out of 3 BSN and drop 2 out of 3 from the M2PA Draft.

For the scenario that you have described, a mechanism similar to the one
described below can be used:

What I will suggest is that, M2PA should not reset the Seq Numbers when the Link
goes into Out Of Service.
This would mean that the FSN and BSN values in Link Status Messages exchanged
for bringing the Link into Inservice, would the values same as the ones in the
Last User Data Message sent when the Link was previously in InSerivce.
So when the Link is brought into Inservice and no User Data has been received,
The expected FSN value of the First User Data Message received should be
(FSN_In_READY_Recvd_From_Peer + 1) and
The expected BSN value should be (FSN_Sent_In_READY_To_Peer).
any Messages received before the expected FSN value arrives should be silently
discarded without taking the Link into Out of Service.
For Message received with the expected FSN and onwards, both FSN and BSN should
be validated as is normally done.
Accordingly, the First Out Going Data Message would have the value of FSN as the
(FSN_Sent_In_User_Data_When_Peer_was_Last_Inservice + 1) and BSN would be the
(FSN_In_READY_Recvd_From_Peer).
As the scenario you had described is possible only when the Link is first
brought into INSERVICE and the First Data Message has not been received, the
above mechanism should be able to solve the problem.

Regards
Anshoo.

Please respond to [email-masked]

To: 

       "May, Howard" <[email-masked]>
cc:        Anshoo Sharma/HSS@HSS, [email-masked], [email-masked]

Subject:        Re: [Sigtran] M2PA v6: Two Out of Three Valid BSN

Howard,

As you seem to have a problem with this, here is another reason
for 2 out of 3, (rather than the first BSN) and a general problem
regarding BSN treatment.  Consider the following:

An M2PA link aligns and goes into service.  Several data packets
get stuck in the network resulting in link failure (and LSOS is sent
and received successfully on stream 0).  The link realigns and goes
back into service (using stream 0).  The "stuck" packets from the
previous in-service are now delivered.

How is the receiver of the MSUs to tell the difference between MSUs
belonging the old in-service session and MSUs belonging to the new
in-service session?  By resetting the FSN/BSN when a link goes into
service?  Then the link will fail on the first abormal BSN unless
the 2 out of 3 is used.

As stuck packets are common in the network and SCTP will faithfully
deliver them late, this situation must be accomodated.

--brian

May, Howard wrote:                                (Mon, 07 Oct 2002 09:57:15)
> Anshoo,
>
> Brian has suggested a requirement that would be a reason for preserving the
> 2/3 procedure.  My understanding is M2PA may be used not to offer MTP2
> services directly to an MTP2 User but rather convert existing MTP2 messages
> into M2PA messages.  Preserving the  2/3 procedure supports transparent
> copying of the MTP2 SNs into M2PA SNs.
>
> It is not clear to me at the moment whether this is an appropriate reason
> for deciding M2PA Procedures.  I am concerned that  we are introducing new
> requirements to M2PA that have not been considered during the rest of the
> design process.  Perhaps the  Authors could comment on this?
>
> Howard
>

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

(Embedded image moved to file: pic23346.pcx)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 8 Oct 2002 04:35:51 -0600

Anshoo,

[email-masked] wrote:                        (Tue, 08 Oct 2002 15:48:54)
> above mechanism should be able to solve the problem.

Why not just discard unexpected BSN or FSN all the time?  Doing so is quite
accurate (3 x 10-8) and no special in-service sequence number procedure is
necessary.  It is simpler and accomplishes the same end.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran