Re: [M3UA] Action on Receipt of ERROR

Simon,

I would say that there has to be a serious protocol feature 
mismatch (or serious mis-implementation) for every DATA 
message to elicit an ERROR response.  This might not be
inherent in the M3UA layer itself, but perhaps the M3UA-user
is using a feature not mutually [externally] agreed with
its peer.  In such a case, it would be the M3UA-user
that needs to stop/change the DATA message, rather than
M3UA itself.  An example of this would be using [or not
using] Routing Context values with a peer that prohibits
[requires] Routing Context values.

I understand your concern with the lack of automatic 
correction, or deterministic resolution, but the 
issue may not be solvable within M3UA, but rather 
in the use thereof.

For the ASP case, one should note that the ASP does
not maintain its own state.  That is maintained by the
peer.  An ASP can merely request to its peer to change
the ASP-state, and the peer can refuse.

With thanks, from Chris Benson.

On Thu, 17 Mar 2011, Sporton, Simon, VF-Group wrote:

>>  Date: Thu, 17 Mar 2011 21:40:31 +0100
>>  From: "Sporton, Simon, VF-Group" <[email protected]>
>>  To: Michael Tüxen <[email protected]>
>>  Cc:  <[email protected]>
>>  Subject: Re: [Sigtran] [M3UA] Action on Receipt of ERROR
>>  
>>  Hi Michael,
>>  
>>  The particular cause value we found the problem with is cause 6 (Unexpected Message). It's quite a convoluted scenario, in essence the 2 cases we see are;
>>  
>>    -  a particular SGP merely logs receipt of an ERROR with Cause 6 when it received in response to DATA, and continues to send DATA towards the ASP which continues to return ERROR Cause 6, effectively black-holing traffic. I'd like to think that at some point the SGP would determine there is something wrong with ASP and send traffic to another, but that doesn't seem to be part of its logic.
>>  
>>   - An ASP which on receipt of an ERROR Cause 6  returns itself to the ASP-DOWN state without sending any indication to the SGP (e.g. an ASP-INACTIVE or ASP-DOWN), so the SGP continue to send traffic to a black-hole. Again, I'd like to think the ASP would have some logic to say; I'm receiving multiple DATA in ASP-DOWN there must be an inconsistency in the state machines on either side, so send an ASP-INACTIVE/ASP-DOWN.
>>  
>>  These are particular vendor issues, but the question for here is should the RFC allow such different error handling? I assume there is good reason for the RFC to leave it to vendor implementation, but I can't work out why!
>>  
>>  Cheers,
>>  
>>  Simon
>>  
>>  
>>  -----Original Message-----
>>  From: Michael Tüxen [mailto:[email protected]] 
>>  Sent: 16 March 2011 20:45
>>  To: Sporton, Simon, VF-Group
>>  Cc: [email protected]
>>  Subject: Re: [Sigtran] [M3UA] Action on Receipt of ERROR
>>  
>>  On Mar 16, 2011, at 5:06 PM, Sporton, Simon, VF-Group wrote:
>>  
>>  > Hi all,
>>  > 
>>  > We have been looking at various vendors implementation of M3UA and seen a significant divergence in the handling of M3UA ERROR messages, from one extreme of simply logging the event, to the other, (unilaterally) changing the state of the association (e.g. ASP-ACTIVE to ASP-DOWN). The RFC doesn't seem to provide much guidance on how to act on receipt of an ERROR message (except not to respond with an ERROR!!). Is it the deliberate intent of the authors to leave the behaviour on receipt of ERROR, or have I missed a critical paragraph in the spec?
>>  Hi Simon,
>>  
>>  I don't think you missed anything. Looking at the error causes, I could see that for some you might to ASP-DOWN, but not for others. I think the behavior is left implementation dependent. Could you provide some more details, for example which error causes result in problems?
>>  
>>  Best regards
>>  Michael
>>  > 
>>  > Thanks in advance for any guidance.
>>  > 
>>  > 
>>  > Simon Sporton
>>  > Vodafone Technology, Networks
>>  >  
>>  > 
>>  > _______________________________________________
>>  > Sigtran mailing list
>>  > [email protected]
>>  > https://www.ietf.org/mailman/listinfo/sigtran
>>  > 
>>  
>>  _______________________________________________
>>  Sigtran mailing list
>>  [email protected]
>>  https://www.ietf.org/mailman/listinfo/sigtran
>>

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