Subject: [AAA-WG]: Issue: Session State Machine for Diameter agents

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 13 Nov 2001 09:36:30 -0500

Description of issue
Submitter name: Yoshihiro Ohba
Submitter email address: [email-masked]
Date first submitted: November 13, 2001
Document: base
Comment type: E
Priority: 1
Section: 8.1, 8.2
Rationale/Explanation of issue:

Authorization Session State Machine and Accounting Session State
Machine seem to define FSM for Diameter clients and servers but not
for Diameter agents (i.e., relay, proxy, redirect and translation
agents).

For example, in section 8.1, when a Service-specific authorization
request is received from a peer in Idle state, there is no action to
*forward* the received request to the next-hop peer of the session and
move to Pending state, which would be a normal action for relay
agents.  Similarly, when a Service-specific authorization answer is
received from the next-hop peer of the session in Pending state, there
is no action to *return* the received answer to the previous-hop peer
of the session and move to Open state (in the case of stateful relay
agents) or Idle state (in the case of stateless relay agents), which
would also be a normal action for relay agents.

Requested change:

Additional state transitions need to be included in section 8.1 and
8.2 to support relay, proxy, redirect and translation agents.

---

From: Johan Johansson <[email-masked]>
Date: Tue, 13 Nov 2001 16:57:12 +0100

Session state is normally only kept at the actual endpoints. See section 
2.9 of the base draft, which among other things state that

"Relays inherent simplicity implies that they are stateless and therefore 
SHOULD NOT maintain session state, but MUST maintain transaction state"

Actually I seem to recall reading somewhere just this morning that they 
MUST NOT maintain session state, although I can't seem to locate that 
particular phrasing right now.

j

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 13 Nov 2001 13:32:54 -0500

Hi,

At Tue, 13 Nov 2001 16:57:12 +0100,
> particular phrasing right now.

Sorry, the example using relay agent was not good.   But how about other
agent such as proxy agent? 

If it is allowed for some agent to be stateful, then I think section
8.1 and 8.2 need to be revised to reflect that.

In addition, if section 8.1 and 8.2 describes only session state
without including transaction state, I think state machine for transaction
state would also be needed.

Yoshihiro Ohba

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 13 Nov 2001 20:12:33 -0800

Maintaining session state is optional in proxies only. Since proxies do all
kinds of weird things, and act as both a server and a client, I think that
the FSM is fine the way it is. Most functions a proxy does is implementation
specific.

Others?

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 13 Nov 2001 20:13:24 -0800

Why do we need to specify the details of how on keeps track of requests and
corresponding responses? This seems to get way too far into the bowels of
implementation.

PatC

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 14 Nov 2001 19:56:28 -0500

At Tue, 13 Nov 2001 20:13:24 -0800,
> corresponding responses? This seems to get way too far into the bowels of

It would be obvious for normal cases, but I'm not sure how it works in
errornous situation.  For examle, without seeing a transaction state
machine, it is not obvious to me how it works when multiple Diameter
nodes on a transaction path go down and then failover occurs at
multiple locations during the transaction.  (I thought a command 
would be needed to abort the transaction request to deal with such
cases, but I'm not sure...)

Yoshihiro Ohba

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 14 Nov 2001 21:02:18 -0800

Failover detection is described in the transport spec. The protocol does
not specify any abort command, and states that if a peer becomes unavailable,
the pending requests are sent to an alternate. This text is already in the 
base protocol spec, and transport spec.

I still don't understand what's missing in the spec.

Others?

PatC