Subject: DIAMETER Base Protocol (18-Alpha 1)" draft / 5.0 Error Reporting

From: "Bob Kopacz" <[email-masked]>
Date: Tue, 16 Jan 2001 11:44:00 -0500

Hi Pat,

When reading section 5.0 "Error Reporting" in the "DIAMETER Base
Protocol (Alpha 1)" draft, I came up with a number of questions
about the handling of a bad reply message, which probably means
I'm missing something basic.

Maybe some clarifications could be added to this section.

I fear I'm all wet here, but here's some questions:

Case 1:  NAS -> HomeServer.  NAS detects error.
-----------------------------------------------

We have a NAS talking directly to his Home Server; no proxies
are involved.  The NAS originates a valid *-Request.  The
HomeServer sends a positive *-Answer which the NAS considers
erroneous (e.g. the *-Answer packet is syntactically incorrect;
or the *-Answer packet is syntactically correct but contains an
AVP with an inappropriate value).

I assume that an MRI is intended as a response not just to bad
*-Request and *-Ind packets, but also to bad *-Answer packets.

The NAS, I think, would send an MRI back to the home server with
an appropriate Result-Code.  If the MRI serves no other purpose,
it can at least make its way into the home server's log file, as
an aid to those investigating why sessions aren't being set up.

If the home server maintains session state, he considers this to
be an active session, since he sent a positive reply.  Is the
MRI sufficient to stimulate the home server to release this
active session, or should the NAS also (or instead) send a
Session-Terminate-Request?  (The MRI may not contain enough
information for the home server to make a determination as to
the fate of this session.  For example, if the MRI was in
response to the home server's positive AA-Answer, the home
server can release the session.  If the MRI was in response to
the home server's Session-Terminate-Ind, then the home server
wouldn't release the session.  But the MRI doesn't indicate the
home server's offending packet.  The home server also doesn't 
know if the Identifier value is his or the NAS's).

According to the table in section 5.0, an MRI can be sent only
if the error is of type "Unknown Command".  If so, what can the
NAS send to the Home Server if the error is of type "Unknown
AVP", "Bad AVP Value", or "Extension Error"? According to the
table, the NAS should send some extension-specific error
response, but I don't see any candidates that can be sent in
response to a bad reply.

Does the NAS behave differently if he receives a bad negative
reply rather than a bad positive reply? (e.g. forego sending the
MRI)

Case 2:  NAS -> RoutingProxy -> HomeServer.  NAS detects error.
---------------------------------------------------------------

Same as case 1, but with a proxy in the middle: The NAS
originates a valid *-Request.  The HomeServer sends a positive
*-Answer, which passes through the proxy ok, but which the NAS
considers erroneous.

Assuming the NAS sent an MRI, what does the proxy do with it?

It seems like the proxy would want to route the MRI to the home
server, since the MRI was most likely a response to something
the home server sent, and not to something the proxy sent (the
proxy likely couldn't determine who was at fault anyway, so
would just forward the MRI in all cases and let the humans
figure out what went wrong).

However, if the proxy routes on Extension Id, he may be unable
to route the MRI, which lacks identification of the offending
extension. (I'm referring to Section 6.2.1 "Proxy and Redirect
Server handling of requests", which says "It is possible for a
routing entry to have a different destination based on the
extension identifier of the message. This field is typically
used as a secondary key field in routing table lookups.").

Here's a thought: Rename the Unrecognized-Command-Code AVP to
the "Failed-Command-Code AVP", and change its value to
contain the Command Code that was being processed when the error
was detected, be it recognized or not.  Include this new AVP in
all MRI messages.  The Result-Code value tells you if the
command was unrecognized.  This seems useful when debugging and
tracing.  And in this case the proxy can now determine the
extension of the offending packet and route the NAS's MRI
accordingly.

Case 3:  NAS -> RoutingProxy -> HomeServer.  PROXY detects error.
-----------------------------------------------------------------

Similar to case 1, but with a proxy in the middle: The NAS
originates a valid *-Request.  The HomeServer sends a positive
*-Answer which the PROXY considers erroneous.

Here the proxy might want to generate two messages, one to the
NAS and one to the home server.  The proxy would do what the NAS
would do in Case 2: send an MRI to the home server.  The proxy
would turn the home server's positive answer into a negative
answer, replace the Result-Code AVP, and send it on to the NAS.

When the NAS receives a negative reply to some request, there is
a Result-Code AVP which indicates the error, but there isn't an
indication of who originally generated the error, i.e. some
proxy along the path, or the home server.

It would be useful to know which machine originated the negative
Result-Code AVP.  It most cases this is indicated by the
Host-Name AVP, but in this case the Host-Name is the home server
while the proxy detected the error.

So a new "Error-Detecting-Server-Name" AVP (not a good name)
could be useful.  The AVP would contain the name of the machine
which originated the failure Reply-Code value, useful in tracing
and debugging.  This new AVP immediately points the technical
staff to the offended (possibly misconfigured) server.

Also, if the NAS knew that a negative answer came from some
proxy, he might try a different route to the home server;
but if the home server originated the reject, well then give up.

If the proxy receives a flawed negative reply from the home
server, rather than a flawed positive reply, does he act
differently?  For example, only override the home server's
Result-Code value if it was 2xxx SUCCESS; forego sending the MRI
to the home server.

Out-of-Range Result-Code values:
--------------------------------

Section 5.2 "Result-Code AVP" defines classes of error codes in
the range 1xxx-5xxx.  

What does a receiver do when receiving a Result-Code value
outside of the defined ranges?

I'm guessing an out-of-range Result-Code value would be treated
as a 5xxx (Permanent failure).  Should an MRI or error log entry
be generated?  Should a Result-Code value of zero be treated as
a 2xxx (Success) for compatibility with existing Diameter
implementations?

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 19 Jan 2001 13:33:49 -0800 (PST)

> Maybe some clarifications could be added to this section.

I would not be surprised that some clarifications are required.

> Case 1:  NAS -> HomeServer.  NAS detects error.

correct.

> an aid to those investigating why sessions aren't being set up.
correct. Also keep in mind that Dave Mitton also suggested adding a third
message to "ack" the reply. This is not something that we've ever discussed
in the DIAMETER list, but we should also consider such a scheme.

> response, but I don't see any candidates that can be sent in

So the spirit of the draft is that if there are no appropriate message
to be sent to return an error, an MRI is used. Again, see my above on
Dave's proposal, which would solve this problem in a cleaner way.

> reply rather than a bad positive reply? (e.g. forego sending the

Good question. Ideally, an MRI would be similar to how ICMP works, but I am
not sure that this solves all problems. So, if the above example were used
the MRI would have to be used as a real response to a reply.

Now I am even more convinced that Dave had a great idea.

> Case 2:  NAS -> RoutingProxy -> HomeServer.  NAS detects error.

Very good suggestion. It requires minimal changes, and solves a
real problem.

> Case 3:  NAS -> RoutingProxy -> HomeServer.  PROXY detects error.

I am not sure that I really like this. This just really stresses the need
for the three way message (of type -Ind, I would think). This would allow
the NAS to send it, and indicate whether an error had been added by
a middle proxy, or if it didn't like the message.

This seems to keep the proxies as dumb as we can.

> staff to the offended (possibly misconfigured) server.

hmmm... someone brought up the point of how to identify the server that
set the Result-Code AVP. Again, I think that this is a great suggestion
and will include it, since it solves a real problem.

> Result-Code value if it was 2xxx SUCCESS; forego sending the MRI

Well, see my comment above on the proxy sending MRIs, but I agree that if an
error is already set, further proxies MUST NOT change the value, and simply 
treat it as a failed request.

> be generated?  
This is probably a good assumption, and I will add clarifications to the text.

> Should a Result-Code value of zero be treated as
I do not think this is necessary.

PatC