Subject: Re: problem related to M2PA

From: Tom George <[email-masked]>
Date: Tue, 16 Oct 2001 10:55:54 -0500

Vladi,

1. I answered that it the other e-mail.

2. I think this came up in the conference call. We are not using
multihoming (at least for now), so the failure of the (only) path is a
failure of the association. The SCTP association is the M2PA link, so
the M2PA link fails. That results in a changeover. 

Thanks again for your comments.

tomG.

On Wed, 3 Oct 2001 Vladi Arbetov wrote:
> 
> Tom,
> 
> Our company will take a participance in the M2PA interop and I have few
> questions regarding the proposed tests.
> 
> 1. Test B5 says: "Establish a link and begin data transmission. Tell one
> side that it is in local processor outage. Remain in that state until
> the other side Stops (ABORT) the link."
> Question: what should cause the other side to Stop (ABORT) the link? As
> far as I understand - Processor Outage shouldn't cause to this. In SS7 -
> changeover due to Processor outage is done by timer and not by link
> failure.
> 
> 2. Test D2: why it is called changeover?  Formally the disconnection of
> the cable on the primary network will not cause to link failure. Traffic
> should be passed through the secondary SCTP association transparently to
> the M2PA layer. So the changeover shouldn't happen.
> 
> Thanks a lot in advance,
>    Vladimir Arbetov
>    Director, SS#7 Networking
>    Airslide Systems Ltd.
>    http://www.airslide.com/
>    Tel +972-9-9709805
>    Fax +972-9-9709843
>    Cell +972-54-416441

-- 
* Tom George        972-519-3168         [email-masked]   *
* PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Tom George <[email-masked]>
Date: Tue, 16 Oct 2001 10:54:08 -0500

I replied to Vladi by provate e-mail. I will put the 2 messages on the
list. Everyone please let me know if there are more questions.

A correction to what I wrote: We are going to keep test case B5, but
revise it so that it does not imply that the Proc Outage _causes_ the
link to fail.

tomG.

====================

Vladi,

Test B3: 

Option (b) would violate the M2PA draft version 3, section 4.1.4, 2nd
paragraph. I agree that M2PA should not be sending data while it is in
LPO.

Options (a) and (c) are both possible. How you get M2PA and MTP3's
states to stay synchronized, and what to do if they are not
synchronized, is in my opinion an implementation issue. 

Test B5: 

You are correct. Processor Outage does not cause the link to fail. So I
think we could eliminate this test case. If we do B4 and B6, that should
test the changeover capability. I will talk to Cliff Thomas about
updating this. 

Thanks for your comments. Please let me know if you have any more. 

tomG.

Vladi Arbetov wrote:
> 
> Waine,
> 
> The questions relating to the LPO was raised during the today's M2PA
> interop conference call.
> 
> Test B3: should the Test Driver stop the data transmission before
> entering the LPO and continue the data transmission after LPO recovery?
> If not - that should M2PA do getting the data message from the upper
> layer while in LPO state?
> 
> Test B5 says: "Establish a link and begin data transmission. Tell one
> the other side Stops (ABORT) the link." The same in B9.
> As far as I understand - Processor Outage shouldn't cause to this. In
> SS7 - changeover due to Processor outage is done by timer and not by
> link failure.
> What should cause the other side to Stop (ABORT) the link? Should it be
> a manual action?
> 
> My opinion is:
> LPO indicates the unavailability of the upper layer to the M2PA layer.
> Getting the message from the upper layer while LPO is abnormal and can
> indicate its availability to M2PA. This can happen when Local Processor
> Outage Recovered Request from the upper layer somehow wasn't treated
> properly. It means exists misfit the statuses of the M2PA and upper
> layer.
> a) Discarding the message just keeps the status misfit on and cause to
> discarding all follows messages.
> b) Sending the message to peer without LPO reset probably will cause
> just to discarding the message later at the peer because the RPO status
> and keeps the status misfit on.
> c) Reset LPO and send data to peer - corrects the status misfit and
> doesn't cause to message lost.
> 
> Option c) looks to me as a proper action.
> 
> Correct me if I'm wrong.
> 
> Thanks a lot in advance,
> 
>    Vladimir Arbetov

---