Subject: Re: [Sigtran] Misc M2PA questions

From: [email-masked]
Date: Sat, 13 Sep 2003 16:32:28 +0530

Hi Brian:

If we send LS PR after processing the Peer Data Messages buffered during
the PO state, then both LS PR message and Data Ack will contain the correct
BSN and FSN values (corresponding to the last message in the buffer).

Similar procedure at the node experiencing RPO would result in correct
behavior.

On both the nodes, Data Ack (from peer) on data streams will be processed
after processing all the messages queued in buffer. In addition, any data
received from the M2PA User will be buffered and transmitted after Data Ack
has been sent for all the buffered messages.

Since M2PAv9 and Q.703 describe  LS messages as highest priority, Data Ack
will be sent after sending LS PR but both will be held onto till clearing
the buffers.

Thus processing in order Buffers->Link Status->Data Ack->New Peer Data can
be a possible solution.

There is a query on these lines. In case of RPO, should data received from
User be buffered as in Q.703 clause 8 since no behavior deviation is
mentioned in M2PAv9 in this regard?

Comments???

Thanx 'n' Regards
Rohit Raghav
Hughes Software Systems
Plot 31, Electronic City
Sector 18
Gurgaon 122015
Haryana, India

Tel: +91-124-2346666/2455555 Extn:3254
Fax: +91-124-2455100/2455101
web : www.hssworld.com
e-mail : [email-masked]

"Brian F. G. Bidulock" <[email-masked]> on 09/11/2003 02:57:03 PM

Please respond to [email-masked]

To:    Rohit Raghav/HSS@HSS, Andrew Booth <[email-masked]>, Tom George
       <[email-masked]>, [email-masked]
cc:

Subject:    Re: [Sigtran] Misc M2PA questions

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)
> 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)
> >
> >
> >
> >
> >
> > 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
> >
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
>
> _______________________________________________
> 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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 13 Sep 2003 10:02:48 -0600

rraghav,

As Data Ack is sent on a different stream than LS PR there is
no guarantee that Data Ack will not arrive before LS PR, in which
case it must be treated as an error and may result in link
failure.  The only way to guarantee ordering is to send both on
the same ordered stream.

--brian

[email-masked] wrote:                                                         (Sat, 13 Sep 2003 16:32:28)

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