Subject: Re: [Sigtran] Misc M2PA questions

From: [email-masked]
Date: Thu, 11 Sep 2003 12:39:17 +0530

Hi Brian

In my view, LS Ready is message corresponding to FISU sent after Proving
period in MTP2.

Sending LS Ready  in response to Processor Recovered would require a change
in description of LS Ready or 'Data Ack' can be used for synchronization,
as suggested by you.

Regards
Rohit Raghav
Hughes Software Systems
www.hssworld.com

"Brian F. G. Bidulock" <[email-masked]>@ietf.org on 09/11/2003
05:42:05 AM

Please respond to [email-masked]

Sent by:    [email-masked]

To:    Andrew Booth <[email-masked]>
cc:    Tom George <[email-masked]>, [email-masked]

Subject:    Re: [Sigtran] Misc M2PA questions

Andrew,

Andrew Booth wrote:
(Wed, 10 Sep 2003 18:41:39)
> Hi Tom,
>
> Some questions and comments below.
>
> Tom George wrote:
>
> >
> >
> > Andrew Booth wrote:
> >
> >> Hi Tom,
> >>
> >> While doing some work towards the plugtest I hit on some more
> >> questions. I'm going to ask Marc Beauchesne to try and get some
> >> feedback from other attendies at the plugtest about the following
> >> questions to see if clarifications to M2PA would be helpful.
> >>
> >> 1) In M2PA 9 we have a mechanism for resynching sequence numbers for
> >> the side in RPO, but not for the side in LPO.  I think this means the
> >> side in LPO cannot resynchronize sequence numbers, which is different
> >> from MTP2.  If we can get away with it for the side in LPO, why not
> >> also in RPO?  Sorry for bringing this up again, but it really has me
> >> wondering. I'm at least curious to hear what other implementers have
> >> to say.  In the meantime, I'll continue to implement it as in the
> >> draft. ;)
> >
> >
> > My revised version allows for resynching on both ends. But it does not
> > give much guidance about when to do it. As I said in another email, I
> > am as vague as Q.703.
> >
> > =====
> > If M2PA receives a Flush command from MTP3,
> >
> > [...]
> >    (c) If resynchronization of sequence numbers is required, M2PA MAY
> >        perform resynchronization of sequence numbers using the BSN
> >        from the received Link Status Processor Recovered message.
> >        However, during resychronization, M2PA SHALL NOT discard any
> >        received User Data messages that were sent after the processor
> >        outage ended.
> > =====
>
> The LS PR message is sent only by the side coming out of LPO, and
> received only by the side in RPO.  How is the side in LPO to resync
> sequence numbers?  Or is that not necessary?

Looks like we should send a LS Ready or Data Ack in response to LS PR.

>
> >
> >
> >>
> >> 2) In ANSI, if we receive a clear RTB should we also flush the RB?
> >> Assume yes, but I don't think this is mentioned in M2PA as a
> >> difference from MTP2...
> >
> >
> > I think that is clear in the revised version:
> >
> > =====
> > If M2PA receives a Flush command from MTP3,
> >
> >    (a) M2PA SHALL discard any incoming messages that were queued and
> >        unacknowledged during the processor outage condition.
> > [etc.]
> > =====
>
> My concern is just that in ANSI two primitives are described in the
> state transition diagrams, "Clear RTB" and "Clear Buffers", one flushed
> the RTB while the other clears the RB and TB also.   But this is a nit,
> I think you're correct that it's clear.

Clear RTB is in preparation for buffer updating for Emergency Changeover.
Clear Buffers is the equivalent of the "Flush" command.

>
> >
> >
> >
> >>
> >> 3) After an FSNC request is processed, the TB and RTB are empty.
> >> Should we empty the RB at this point?
> >
> >
> > That sounds right and I think it would be the same in MTP2. If you
> > answer the FSNC request to the upper layer MTP3, then you can't accept
> > any subsequent messages that are still in the RB. They would be
> > retransmitted on the alternate link by the peer, and thus would be
> > duplicated.
>
> Agreed, but I haven't found it in the MTP2 specs.  In the ANSI SDLs
> there is a reference to clearing the RTB after a changeover, but again
> in ANSI that doesn't clear the RB or TB, just the RTB.  Don't know if
> it's worth mentioning explicitly.

In both the Q.703 and ANSI SDLs, the only time the RB holds anyting is
during receive congestion.  Both documents consider what happends during
processor outage (local or remote) during congestion, because congestion
could often lead to processor outage on traditional systems.

The text on processor outage in ANSI T1.111.3 makes specific mention of
discarding messages not acknowledged due to receive congestion during
buffer
clearing (flushing).  This is the RB.  (Also there is a not there stating
that
the SDLs are not complete at least in one regard.)

What applies to receive congestion applies to the messages held but not
acknowledged in M2PA's RB.

>
> >
> >
> >
> >>
> >> 4) If we do a sequence changeover during PO and then bring the link
> >> back in service, what FSN should we send next?  What FSN should we
> >> expect next?  I assume we treat this like MTP2.
> >
> >
> > Andrew, you are going to have to explain this to me. I did not think
> > MTP would do a changeover on a link that was in LPO.
>
> Q.704 and T1.111.4 are clear that the side in RPO should not initiate a
> sequence changeover, but I believe the side in LPO can initiate a
> sequence changeover.  Also, it seems a reasonable approach to take if
> you know the processor outage will be long term (implementation
> dependent), since then you don't lose messages.  There are comments in
> Q.703 section 8 that while in Processor outage MTP3 may still be able to
> control L2, and q.703 figure 8 (sheet 12/14) indicates that Retrieval
> Request and FSNC is a valid primitive from MTP3 while MTP2 is in the PO
> state.

There are a numebr of places that say that buffer updating is performed if
possible.  Whether it is possible is implementation depenedent and the
MTP2/MTP3 interface is not a hard and fast one anyway.

However, that does not change much: if buffer updating can be completed it
is
completed according to the normal procedures.

What was your point here?

--brian

>
> What do you think?
> Andrew
>
> >
> >
> >
> >>
> >> Thoughts?
> >> Andrew
> >>
> >
> >
>
> --
> Andrew Booth, Software Developer
> Signaling Systems Group, Performance Technologies
> 613-237-4344
>
> Visit www.pt.com/mailing.html to subscribe to our Packets & Signals
eLetter.
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

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

_______________________________________________
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: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 11 Sep 2003 02:17:56 -0600

rraghav,

Rather than syncronizing off LS PR one way and Data Ack the other, perhaps
we should require a Data Ack in both directions for synchronization.  The
difference, of course, is LS PR is on stream '0' and the Data Ack is on
stream '1'.  Meaning that the Data Ack is synchronized with data on the
data stream whereas LS PR is not.

I still don't know how the LS PR is to be correlated with the Data in the
data stream, as the sycnchronization of sequence numbers using LS PR or
after LS PR cannot be make synchronous with the data stream.  If the sequence
number is also changing, examining the sequence numbers in the LS PR might be
of no use in resynchronizing the LS PR with the data stream.  I still think
that LS PO and LS PR (or maybe just LS PR) should be sent on stream '1' to
avoid problems in the wild.

--brian

[email-masked] wrote:                                                         (Thu, 11 Sep 2003 12:39:17)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 11 Sep 2003 02:27:03 -0600

rraghav,

Here's a thought:

If the sequence is as follows:

     LS PR  --------------------->
            <--------------------- LS Ready
  LS Ready  ---------------------->

instead of using Data Ack at all.  Then, it would be easy to identify
the messages to use for synchronization.  (The LS Ready messages.)

For both processors recovering:

     LS PR  ------------------+-->
            <--+--------------|--> LS PR
            <--|--------------+--- LS Ready
  LS Ready  ---+------------------>

The problem is that data could still be out of sync with the
new sequence numbers.  Meaning that the link may fail on resynchronization
of sequence numbers.

Perhaps these two LS Ready's should be sent in the data stream.  Then
it is clear where they are with respect to data.  Also, using Data Ack
would be bad, because it cannot be correlated to the LS PR and ther may
be many Data Acks in flight at the time that a processor recovers.

--brian

Brian F. G. Bidulock wrote:                                                        (Thu, 11 Sep 2003 02:17:56)

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

---

From: David Lehmann <[email-masked]>
Date: Fri, 19 Sep 2003 11:21:11 -0400

Brian F. G. Bidulock wrote:
> I still think

I agree that both LSPO and LSPR should be on the data stream.
Was there any resolution on this matter?

-- 

David Lehmann                          Ulticom, Inc.
AOL/Yahoo IM: davidULCM                1020 Briggs Road
1-856-787-2729                         Mt. Laurel, NJ 08054   USA