Re: [M3UA] Action on Receipt of ERROR

"Sporton, Simon, VF-Group" <[email protected]> Thu, 17 Mar 2011 21:40:31 +0100
Newsgroups gmane.ietf.sigtran
Message-ID <957B5237851DB74283AFD29B017683D007384860@EITO-MBX01.internal.vodafone.com>
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
>