Re: [M3UA] Action on Receipt of ERROR

On Mar 17, 2011, at 9:40 PM, Sporton, Simon, VF-Group wrote:

Hi Simon,

see my comments in-line.

Best regards
Michael

> 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.
So why is an ASP sending an ERROR(cause=6) in response to a DATA message. For me this looks like
a state mismatch between the SGP and the ASP.
> 
> - 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.
I think the bug here is that the ASP does not send an ASP-DOWN when it decides to go into that state due
to the reception of the ERROR.
> 
> 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!
I'm not one of the authors, so I can only guess here. My impression of the handling of ERROR messages
is that an implementation I would write would not take any serious actions when receiving an ERROR message.
The information contained in the ERROR messages is not defined in a way that I would be able to
process them. My understanding is that they might be helpful when looking at wireshark traces...

Best regards
Michael
> 
> 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
>> 
> 
>