Re: : RE: AAA Transport Profile and Application Failure

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.

 
I believe this should be true for client side also, because the same scenario can occur for client side. can any person verify for me please??? 

Thanks,

Rakesh

STURA Marco Consultant <[email protected]> wrote:
Mike,

some comment in line.

Regards
Marco

-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Wednesday, March 23, 2005 2:43 PM
To: [email protected]
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
implemented
in layers. Accordingly the possibility exists that in a Proxy agent or
a
server, the Diameter Base protocol handling process is functioning
properly
but the application process has fallen over. I.e. The Diameter
Transport
connection is up and the watchdog commands (DWR/DWA) are being sent and
received.

[MSt] Yes, Diameter stack should be layered and internal 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
Base
process in the Proxy (or Server) will either not send any response back
to
the client at all or reply with an error and Result-Code set to
DIAMETER_UNABLE_TO_DELIVER, depending on implementation and
interpretation
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 handling responsibility is typically
shared between layers (i.e. base protocol and possibly proxy
application).

Section 6.1 of RFC 3588 reads:

[start fragment]

When a message is received, the message is processed in the following
order:

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.

[end fragment]

I think a proper implementation would work as follow:

- The base protocol layer receives the request. It decides as whether it
is acting as proxy or relay for the request (i.e. based on Local Action
in the 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
to
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
to
detect the general failure and thereby suspend the peer and send all
future
Requests directly to the alternative peer. It seems that this
situation
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 your implementation (but
this is up to your implementation I think), the client may decide 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
"implementation dependent"?

[MSt] My feeling is that internal communication between software
components that build up your Diameter stack is definitely
implementation dependent.

Best Regards

Mike Hillier


Michael Hillier
Mobile +49 170 5454 121
[email protected]



		
---------------------------------
Do you Yahoo!?
 Yahoo! Sports -  Sign up for Fantasy Baseball.