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

From: [email-masked]
Date: Fri, 26 Sep 2003 11:29:04 -0400

Hello George,

I don't think it's okay. LSPO and LSPR on steam 1, yes... but as for the
rest....

I do not understand the need for a three-way handshake to re-synch.

What does the M2PA side that sent the LSPR after flush do if it receives
data for
transmit from MTP3 prior to receiving the LSR from the peer?

Is it supposed to buffer it until the LSR arrives?

If so, how long is it supposed to buffer? What does it do if its buffer
capacity is exceeded?

Can data be sent in lieu of the LSR?

Maybe we should reconsider M2PA's support of processor outage, and instead
just fail the link
like other HSLs do.

Regards,

Jeff

                      Tom George                                                                                                  
                      <Tom.George@alca         To:                                                                                
                      tel.com>                 cc:      [email-masked]                                                          
                      Sent by:                 Subject: Re: [Sigtran] (M2PA) LSPO and LSPR sent on stream 1 and LSPR used to      
                      sigtran-admin@ie         re-synch resolves PO issue?                                                        
                      tf.org                                                                                                      

                      09/26/03 10:56                                                                                              
                      AM                                                                                                          

This looks OK to me and everyone else seems to like it. I will go ahead
and put it into the draft.

tomG.

Brian F. G. Bidulock wrote:
> Andrew,
> Andrew Booth wrote:
(Thu, 25 Sep 2003 15:18:20)
>
>>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.
>
>
> 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
>
> --brian
>
>
>>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
>
>

--
* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
*   I actively disclaim speaking for Alcatel.  I do not purport to    *
*   advertise or represent its position, operations, or activities.   *

_______________________________________________
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: wayne taylor <[email-masked]>
Date: Fri, 26 Sep 2003 14:11:20 -0400

Tom,
i like Jeffrey's suggestion. why dont we just  reconsider  m2pa 
processor outage and fail the link the way HSL does ...

- wayne

---

From: David Lehmann <[email-masked]>
Date: Fri, 26 Sep 2003 14:33:11 -0400

> Maybe we should reconsider M2PA's support of processor outage, and instead

I agree with Jeff.

--

---

From: Tom George <[email-masked]>
Date: Fri, 26 Sep 2003 16:17:44 -0500

Removing support for PO would simplify the draft in some ways.

If anybody thinks this is not the way to go, now would be a good time to 
speak up.

tomG.

   [...]
> Maybe we should reconsider M2PA's support of processor outage, and instead
   [...]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 26 Sep 2003 19:47:09 -0600

Tom,

Processor outage is use for redundancy in the transition where one Signalling
Data Terminal is swapped for another without taking the link out of service.
The HDLC processor is configured to idle SIPO.  In addition, processor outage
is used as a maintenance facility for suppressing initial alignment attempts
from the remote signalling terminal (link is configured to idle SIPO instead
of SIOS) and is useful for management of signalling links.  Both techniques
are used in practice today for SS7 links.

For ATM it was not an issue because the ATM cell processor is tightly
integrated on the interface card and initial alignment attempts can be
suppressed by dropping the VC used for the link.

M2PA could drop the SCTP association and refuse to accept INIT of an
association in the same manner as suppressing the VC for ATM, however, the
signalling link state machine and the SCTP endpoint are not necessarily on the
same processor as is almost always the case for ATM.

Those that choose to support a Q.2210 model will not support PO anyway
(because it is not supported by MTP3b).  Based on a Q.2210 state machine, the
receiver of LSPO will respond with LSOS (or ABORT) just as MTP3b takes the
link out of service when it receives a local or remote processor outage
indication.

Those that choose to support a Q.703 model need to address processor outage
because the procedures are specified by Q.703.  In the last 20 years of SS7
there has been ample opportunity to remove processour outage from Q.703 (or
make it a national option) but it has never been removed.

Making M2PA support something in between Q.2210 and Q.703, or removing PO
from M2PA will require changes to Q.704 (just as Q.2210 needed to change
Q.704 to accomodate its differences from Q.703).  Our objectives for M2PA
was that it be able to be used with existing MTP3 implementations (both
Q.703-based and Q.2210-based).  It would be difficult to say that M2PA can
act as a replacement for Q.703 links without proper PO procedures.

But we did discuss this before at length and agreed to keep it.  We certainly
did not go to all that trouble fixing up the state machine diagram to
include PO for nothing.

AFAIK the only last call issue visa vi PO was sychronization of sequence
numbers in the reverse direction, not its presence in the protocol.

--brian

Tom George wrote:                                                                      (Fri, 26 Sep 2003 16:17:44)

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