Subject: Re: [Sigtran] (M2PA) LSPO and LSPR sent on stream 1 and LSPR used to re-synch resolves PO issue?

From: [email-masked]
Date: Tue, 30 Sep 2003 15:42:54 -0400

Hello Brian,

>It takes two FISUs to complete the flushing and
>resynchronization.

Not entirely true: FISUs or MSUs.
M2PA user data and ACK also suffice.

What M2PA text needs to change for this issue?
Anyone can read the M2PA norm references.

Regards,

Jeff

                      "Brian F. G.                                                                              
                      Bidulock"                To:      [email-masked]                               
                      <bidulock@openss         cc:      Andrew Booth <[email-masked]>, [email-masked]          
                      7.org>                   Subject: Re: [Sigtran] (M2PA) LSPO and LSPR sent on stream 1 and 
                                               LSPR used to re-synch resolves PO issue?                         
                      09/30/03 02:20                                                                            
                      PM                                                                                        
                      Please respond                                                                            
                      to bidulock                                                                               

jeffrey.craig,

See ANSI T1.111.3 Section 8.  It takes two FISUs to complete the flushing
and
resynchronization.  It is not a handshake.  The LSPR represents the first
FISU and the LSR the second.  That is all.

--brian

[email-masked] wrote:
(Tue, 30 Sep 2003 11:02:40)
>
> Hello Andrew,
>
> >I think there is still the question of whether the side experiencing LPO
> >is supposed to resynchronize sequence numbers after a flush and if so,
> how.
>
> What exactly (in detail) is the problem with M2PA's support of PO?
> Why is sending LSPR (or ACK) not sufficient to re-synch? (An example flow
> diagram with queues and sequence numbers would really help).
>
> I see nothing in the Q.703 SDL describing a three-way handshake
> in order to re-synch. All I see is the side experiencing LPO sending a
> FISU with updated BSN upon the recovered event, and the Flush/Clear event
> triggering entry to In Service (and enabling transmission of MSU/FISU).
> I see the RPO side exiting to In Service upon receipt of FISU and
> Clear/Flush.
>
> Questions regarding Brian's PO proposal:
>
> >Yes.  I propose sending LS Ready response to LSPR to accomplish this.
> >If LSPR is sent on stream 1, this LS Ready should be sent on stream 1 as
> >well, as follows:
> >
> >all on stream 1:
> >
> >   LSPR
> >   --------------->
> >   DATA (ACK)
> >   <---------------
> >   <---------------
> >   <---------------
> >   LSR
> >   <---------------
> >   resync
> >
> >   DATA ACK
> >   --------------->
> >   LSR
> >   --------------->
> >   resync
>
>
> Why must LSR be exchanged? (What information is lacking on the LPO side
> that requires receipt of LSR? Why is the LSPR insufficient to complete
> the re-synch?)
>
> Why must LSR, an alignment primitive, be used rather than an ACK?
>
> What does the LPO side do with data for transmit while waiting for LSR?
>
> How long should the LPO side wait for LSR?
>
> What does the LPO side do if no LSR is received prior to timeout?
>
> How long does the non-LPO side wait for a LSR after receiving LSPR?
>
> What does the non-LPO side do if no LSR is received after LSPR?
>
> What happens after LSPR receipt if non-ack data arrives prior to LSR?
>
>
> Regards,
>
> Jeff
>
>
>
>
>
>
>                       Andrew Booth
>                       <[email-masked]>          To:
[email-masked]
>                                                cc:      [email-masked]
>                       09/25/03 03:18           Subject: Re: [Sigtran]
(M2PA) LSPO and LSPR sent on stream 1 and LSPR used to
>                       PM                       re-synch resolves PO
issue?
>
>
>
>
>
>
> Hi Jeff,
>
> I think there is still the question of whether the side experiencing LPO
> is supposed to resynchronize sequence numbers after a flush and if so,
how.
>
> Andrew
>
> [email-masked] wrote:
>
> >Hello All,
> >
> >I also agree LSPO and LSPR should be sent on stream 1, and that LSPR
> >should be used to re-synch sequence numbers.
> >
> >Does this resolve all of M2PA's outstanding processor outage issues?
> >
> >Regards,
> >
> >Jeff
> >
> >
> >
> >
> >                      David Lehmann
> >                      <lehmann@ulticom         To:
> [email-masked]
> >                      .com>                    cc:
> [email-masked], Andrew Booth <[email-masked]>, Tom George
> >                      Sent by:                 <[email-masked]>,
> [email-masked]
> >                      sigtran-admin@ie         Subject: Re: [Sigtran]
Misc
> M2PA questions
> >                      tf.org
> >
> >
> >                      09/19/03 11:21
> >                      AM
> >
> >
> >
> >
> >
> >
> >Brian F. G. Bidulock wrote:
> >
> >
> >>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.
> >>
> >>
> >
> >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
> >
> >
> >_______________________________________________
> >Sigtran mailing list
> >[email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> >
> >
> >
> >
> >_______________________________________________
> >Sigtran mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/sigtran
> >
> >
>
> --
> 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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 30 Sep 2003 13:59:43 -0600

jeffrey.craig,

The problem is, of course, if a DATA is not forthcoming.

I proposed sending DATA ACK immediately, but then LSPR (on
stream "0") and DATA ACK (on stream "1") could be out of
sync with LSPR.  So I proposed LSR on stream "0" instead
of DATA ACK.  If LSPR is on stream 1, I suppose we could
go back to DATA ACK.

Point being is something needs to be sent if DATA is not
available, and it needs to be sent on the same stream as
LSPR.

If LSPR is on stream "1" we can go back to using DATA
ACK.

--brian

[email-masked] wrote:                                             (Tue, 30 Sep 2003 15:42:54)

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