Re: What are the chances that SG may not send Notify messages to AS (M3UA)

Hi Brian,



Thanks a lot for the detailed explanation. On the first instance reading RFC 4666, I thought that the Notify is must and we implemented the ASP based on it. It all worked fine until one day while using a tool from leading vendor we encountered this issue.



We discussed this issue with the vendor and he told us that it's not a must condition and they may send the Notify after two or more state changes. Also as per their comment they have seen "MANY" implementation which do not sends Notify which is itself very strange as we have also tested our system with two SG implementation which do sends Notify messages as expected.



But if such faulty implementation is present it will block our ASP from sending ASP-ACTIVE as we always wait for Notify (AS-INACTIVE) and will lead us to a deadlock situation. Also in our simulated environment no other ASP was active and hence state at AS should have been AS-DOWN and no other state should have been possible.



While going through the RFC in section 4.3.4.5, I found bit contradictory or would say confusing statements and where I could interpret Notify in some circumstances could be optional but as per your explanation I can clearly see that it is a must condition.



Right now I don't think very good reason why SG may take a deviation but will surely ask our vendor to provide some good reason for their implementation.



Thanks a lot.



Regards

Deepak



-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]]
Sent: Wednesday, December 23, 2009 7:12 PM
To: Deepak Gunjal
Cc: Chris Benson; [email protected]
Subject: Re: [Sigtran] What are the chances that SG may not send Notify messages to AS (M3UA)



Deepak,



AS state is maintained on an SG-wide basis.  That is, there is one

coordinated AS state that is the same for all SGP that make up an

SG.  When this AS state changes, each ASP that is not in the

ASP-Down state (for some SGP) must be sent a notify message

informing the ASP of the change of AS state.



When an ASP moves from the ASP-DOWN to ASP-INACTIVE state within an

AS, the SG should inform the ASP of the coordinated AS state

provided that it hasn't done so already.  It is not optional.  It is

recommended and you need a very good reason not to do so in each

circumstance.



What are some reasons for not sending a Notify message when an

ASP-DOWN to ASP-INACTIVE transition occurs:



1. ASP-DOWN to ASP-INACTIVE transitions are per-SGP.  AS state is

   coordinated SG-wide.  The SG need only inform the ASP of AS state

   once (not once for each SGP in the SG).



2. The ASP-DOWN to ASP-INACTIVE transition causes the AS state to

   move from AS Down to AS Inactive.  In this case a Notify message

   must be send to signal the AS state transition and a separate

   message to inform the ASP of the current state is unnecessary.



I can't think of any more of the top of my head.



So what can you do if you are faced with a broken SG implementation

that ignores this recommendation?  First, tell them to fix it or

present the very good reasons why they are not sending it.  Then, if

you are forced to deal with such a broken implementation, consider

the following:



If the ASP-DOWN to ASP-INACTIVE state transition causes the AS to

change state from AS-DOWN to AS-INACTIVE then the Notify message

MUST be sent per 4.3.4.5.  Therefore, if the ASP does not receive a

Notify message, the SG is either terribly broken or the AS was not

in the AS-DOWN state previously: that is, the ASP is not the first

ASP in the AS.  This is actually a lot of information.  If no Notify

is received, there exists some other ASP in the AS that is aware of

the SG's view of AS state.  ASPs in an AS need to coordinate

themselves.  The ASP might obtain the AS state from this other ASP.



I actually brought this passage up as a last call issue on M3UAv02

(where is was added).  The issue was not resolved at last call.  In

fact there were many issues brought up at last call that were not

resolved.  The issue was that the ASP-DOWN to ASP-INACTIVE state

transition is not necessarily due to the ASP Up procedure  (it can

also occur as a result of the Registration procedure).  Therefore,

mention of the "ASP-UP receptor" is misleading.



When an ASP transitions from the ASP-DOWN to ASP-INACTIVE state for

the first time in a particular AS (for whatever reason) the ASP

should be informed by the SG of the current AS state with a Notify

message, unless it has already or will otherwise be notified of the

AS state.



Can you think of any good reason not to do that in a given

circumstance?



The danger of an SG not sending this Notify message is that the

ASP might sit around waiting for one.  This could be a bad thing

if the current AS state happens to be AS-ACTIVE (with insufficient

ASPs active), AS-PENDING or AS-INACTIVE.



--brian









Deepak Gunjal wrote:                         (Wed, 23 Dec 2009 12:39:16)

>

>    Hi Chris,

>

>

> Thanks for your detailed reply. From the same section, 2^nd

> paragraph "When an ASP moves from ASP-DOWN to ASP-INACTIVE within

> a particular AS, a Notify message SHOULD be sent, by the ASP-UP

> receptor, after  sending the ASP-UP-ACK, in ord er to inform the

> ASP of the current AS state."

>

>

>    Now as per the above statement when an ASP moves from ASP-DOWN

>    to ASP-INACTIVE it seems that the Notify could be optional

>    (SHOULD clause) and this is the cause of my doubt which a bit

>    is an contradictory statement what has been written in the

>    beginning of this section 4.3.4.5.

>

>

>    Can you please confirm if there is some misinterpretation from

>    my side?

>

>

>    Thanks

>

>    Deepak

>





--

Brian F. G. Bidulock

[email protected]

http://www.openss7.org/

________________________________
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

_______________________________________________
Sigtran mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sigtran