Subject: [AAA-WG]: Issue #1: Routing of Indication messages

From: Pat Calhoun <[email-masked]>
Date: Tue, 15 May 2001 06:45:50 -0700

All,

I have just begun to code the failover portion of the protocol (I was 
waiting because of the uncertainty of the current text), and have
discovered a problem.

The base protocol introduces the fact that nodes  need to maintain a
queue of pending request, which is used for failover purposes. Here is
a snippet of text:

"7.3  Failover/Failback Procedures

   In the event that a transport failure is detected with a peer, it is
   necessary for all pending request and indication messages to be
   forwarded to an alternate server, if possible. This is commonly
   referred to as failover.

   In order for a Diameter node to perform failover procedures, it is
   necessary for the node to maintain a pending message queue for a
   given peer. When a response is received, the message is removed from
   the queue. The Hop-by-Hop Identifier field MAY be used to match the
   corresponding response with the queued request."

Furthermore, the following diagram from the specification is very useful
in understanding how it works:

"                     Request         +--------+ Link Broken
          +-------------------------->|Diameter|----///----+
          |     +---------------------|        |           v
   +-----+---+  |         DSI         | Server |     +--------+
   |Diameter |<-+ (Unable to Forward) +--------+     |Diameter|
   |Client or|                                       |        |
   | Server  |--+                     +--------+     | Server |
   +---------+  |      Request        |Diameter|     +--------+
                +-------------------->|        |           ^
                                      | Server |-----------+
                                      +--------+
               Figure 1 - Example of Per-Hop Error Condition"

In the above figure, a Diameter node sends a packet to a server, an
error is received, via a DSI, and this causes the request (or ind) to be
sent to the alternate server.

Section 7.3 states that the message is removed from the queue only once
a response is received. So obviously this isn't much of an issue for the
request/answer messages, but what about indication messages?

There are three options:
1. Indication messages *always* have a response. A response to an -ind is
quite simple, it only includes a minimum number of AVPs (e.g. Session-Id,
Result-Code). So all Indication messages have a response, and we can 
transform the Failed-Ind to be this response. Call it an -Ack. 
2. Write some specialized text in the document to handle -Ind messages
differently from -Request. Perhaps have messages timeout from the queue.
I really think this is the wrong approach, and would lead to much more
complicated text.
3. Elimination of Indications altogether, and only make use of -Request
and -Answer. I don't particularly like this approach because Indication
messages are useful, and have a different connotation than do -Requests.

So just as a clarification, Indication messages use to work fine, but with
the introduction of the queueing of pending packets, it has become a 
problem. So, a resolution is required.

Thanks,

PatC

---

From: David Frascone <[email-masked]>
Date: Tue, 15 May 2001 09:03:22 -0500

On Tue, May 15, 2001 at 06:45:50AM -0700, Pat Calhoun wrote:
[snip]
> transform the Failed-Ind to be this response. Call it an -Ack.

I'd prefer this one.  I like having a response to all messages.  It just
makes life easier.

-Dave

---

From: Tony Johansson <[email-masked]>
Date: Wed, 16 May 2001 15:23:00 -0700

Hey Pat,

> in understanding how it works:

I agree, explaining figures is really helpful.

>    +---------+  |      Request        |Diameter|     +--------+

Maybe I have misunderstood you, but why you would like to see a response sent
back on the DSI in the example that you show above? I don't see any reason why
the server issuing the DSI needs to get a response back in this case? It has
already identified that it can't forward the request be cause of the link
failure, so when it  issues the DSI to the originating node it would also
remove the request from it's queue (it can't proxy this request anyway).
Right? Furthermore, I think the DSI would always be issued as a response.
Right?

However, for the STI case I do agree with you. The STI is issued like a
request, so in that case we really have the need for a response. See figure
below.

       Please view in a fixed-width font such as Courier.

                                             (store in queue in
                                              in case of DSI??!!)
       Link    +---------+ STI    +--------+  STI   +---------+
       Broken  | Diameter|<-------+Diameter|<-------+Diameter |
       +--///--+         |        |        |        |         |
       |       |  Server +------->|Server  |        |Server   |
       |       +---------+ DSI    +-- +----+        +---------+
       |           (Unable to Forward)|
       V                              |
    +---------+                       |
    |Diameter |                       |
    |         |                       |STI
    |Client   |                       |
    +---------+                       |
       ^                              |
       |          +---------+         |
       | STI      |Diameter |         |
       +----------+         |<--------+
                  |Server   |
                  +---------+

BR,

/Tony