Re: : RE: AAA Transport Profile and Application Failure
2005-04-01 16:41:52 GMT
As per section 6.1 of RFC 3588(as mentioned in this mail), even diameter stack is working in server mode; it can create DIAMETER_UNABLE_TO_DELIVER message with E bit set and send to proxy if local application is not available to process the message.
STURA Marco Consultant <Marco.STURA <at> consultant.vodafoneomnitel.it> wrote:
some comment in line.
From: m.hillier <at> telenet-ag.de [mailto:m.hillier <at> telenet-ag.de]
Sent: Wednesday, March 23, 2005 2:43 PM
To: aaa-wg <at> merit.edu
Subject: AAA Transport Profile and Application Failure
A question has come up concerning the detection of a failed Diameter
application and the consequences for the AAA client.
RFC 3588 suggests very strongly that Diameter stacks should be
in layers. Accordingly the possibility exists that in a Proxy agent or
server, the Diameter Base protocol handling process is functioning
but the application process has fallen over. I.e. The Diameter
connection is up and the watchdog commands (DWR/DWA) a re being sent and
[MSt] Yes, Diameter stack should be layered and inte rnal communication
between layers is left to the implementation. There was an attempt to
standardize a basic API, but this was shut down a while ago. I have seen
some discussion lately but probably nothing concrete yet.
In such a situation and on receipt of a Request from a AAA client, the
process in the Proxy (or Server) will either not send any response back
the client at all or reply with an error and Result-Code set to
DIAMETER_UNABLE_TO_DELIVER, depending on implementation and
of RFC 3588 and RFC 3599.
[MSt] A Diameter agent MUST always send an answer back to the client,
either success or failed. If the agent is acting as a relay for a
request, then the base protocol layer is mainly the one responsible for
the full handling of the request. However, if the agent is acting as
proxy for a request, the request ha ndling responsibility is typically
shared between layers (i.e. base protocol and possib ly proxy
Section 6.1 of RFC 3588 reads:
When a message is received, the message is processed in the following
1. If the message is destined for the local host, the procedures
listed in Section 6.1.4 are followed.
2. If the message is intended for a Diameter peer with whom the local
host is able to directly communicate, the procedures listed in
Section 6.1.5 are followed. This is known as Request Forwarding.
3. The procedures listed in Section 6.1.6 are followed, which is
known as Request Routing.
4. If none of the above is successful, an answer is returned with the
Result-Code set to DIAMETER_UNABLE_TO_DELIVER, with the E-bit set.
I think a proper implementation would work as follow:
- The base protocol layer receives the request. It decides as whe ther it
is acting as proxy or relay for the request (i.e. based on Local Action
in t he realm routing table).
- If the request is to be proxy (i.e. the agent is acting as proxy for
the request), the proxy application should process the request by
modifying the message according to its policy (e.g. add a
Destination-Host to force the request to be routed to a pre-defined
destination or other policy specific actions). Hence the base should
pass the request to the application layer and, if this one fails, it
should answer according to step 4 above. Basically, there should be
internal communication between layers in order to detect the failure
(i.e. if the proxy application process is down, and this is required for
the processing of the request, this should be internally detected and an
appropriate answer sent back to the originator of the request).
The AAA client is now faced with the situation that every single Request
a peer is failing. Depending on the application and mode of use, an
individual Request (e.g. at the start of a Session) can failover to a
secondary peer. However there seems to be no mechanism for the client
detect the general failure and thereby suspend the peer and send all
Requests directly to the alternative peer. It seems that this
can occur both in a Proxy Agent and in a Server.
[MSt] See my previous comment. In my example the agent is up and running
in relay mode, but perhaps not in proxy mode because the proxy
application process is down. Therefore every request for which the agent
has to act in proxy mode will possibly be answered with Result-Code
DIAMETER_UNABLE_TO_DELIVER. The AAA client receiving such an error, will
possibly re-send the request to an alternate peer (and the request may
eventually get a successful answer). That's all what the standard says.
Then, depending on the degree of complexity of yo ur implementation (but
this is up to your implementation I think), the client may decid e to
stop sending such requests (perhaps for a while) to a peer after a
number of failed request with this kind of result-code.
Have I miss-understood the mechanisms or even the architecture of a
Diameter node? Or is this "out-of-scope" of the RFCs, possibly being
[MSt] My feeling is that internal communication between software
components that build up your Diameter stack is definitely
Mobile +49 170 5454 121
M.Hillier <at> telenet-ag.de
Do you Yahoo!?
Yahoo! Sports - Sign up for Fantasy Baseball.