Re: [M3UA] Action on Receipt of ERROR

Hi Chris,

I agree, certainly a number of serious 'mis-implementations' were discovered when we looked into this problem! These have been taken up with the vendors and are being resolved. What I'm asking here is if there is any guidance the RFC can provide to bring error handling implementations closer together... at the moment it seems to be open season for each vendor to implement the logic they think is right, which can lead to unexpected consequences when interworking with another stack. 

Our understanding was that the ASP was sending ERROR (Unexpected Message) because it was receiving DATA while in the ASP-DOWN or ASP-ACTIVE states. I agree, the RFC says the state of remote ASPs is maintained in the SGP, but I'd assume each ASP must maintain its own state even if not formally stated in the RFC. 

Simon


-----Original Message-----
From: Chris Benson [mailto:[email protected]] 
Sent: 17 March 2011 21:53
To: Sporton, Simon, VF-Group
Cc: Michael Tüxen; [email protected]
Subject: Re: [Sigtran] [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.

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