Subject: [AAA-WG]: DIAMETER Sessions State Machine

From: Pat Calhoun <[email-masked]>
Date: Tue, 23 Jan 2001 16:21:05 -0800 (PST)

All,

At Dave Spence's request, I've put together a state machine that would explain
how sessions are created, and terminated, and how the various ST* messages are
used. I know that Barney typically doesn't like server internals to be
discussed, but Dave thought it would be necessary in the spec.

Here is what I've come up with, and I would solicit comments on whether it is
considered useful in the base protocol spec (again, this is not new
functionality, but rather clarification to ease interoperability).

3.1  State Machine

   This section contains a finite state machine, representing the life
   cycle of DIAMETER sessions, and MUST be observed by all DIAMETER
   implementations.  The term Service-Specific below refers to a message
   defined in a DIAMETER extension (e.g. Mobile IP, NASREQ).

      State     Event                          Action     New State
      -----     -----                          ------     ---------
      Idle      Client or Device Requests      send serv. Pending
                access                         specific
                                               auth req

      Idle      Service-Specific authorization send serv. Open
                request received, and          specific
                successfully processed         response

      Pending   Successful Service-Specific    Grant      Open
                Authorization response         Access
                received

      Open      Authorization-Lifetime expires send serv. Open
                                               specific
                                               auth req

      Open      Successful Service-Specific    Extend     Open
                Authorization response         Access
                received

      Open      Failed Service-Specific        Discon.    Cleanup
                Authorization response         user/device
                received.

      Open      Session-Timeout Expires on     send STR   Discon
                NAS

      Open      Session-Timeout Expires on     send STI   Discon
                home AAA server

      Discon    STI Received                   ignore     Discon

      Discon    STR Received                   Discon.    Cleanup
                                               user/device

      Discon    STA Received                   Discon.    Cleanup
                                               user/device

   When the Cleanup action is invoked, the DIAMETER node SHOULD attempt
   to release all resources for the particular session.

---

From: Barney Wolff <[email-masked]>
Date: Tue, 23 Jan 2001 19:51:05 -0500

A few comments.

1.  I have no problem with the state machine as it
describes required externally-visible actions.  I'd put
releasing resources as "may wish to" (note lower case)
rather than SHOULD, and Cleanup as an action, not a state,
but I won't be fanatic about it.

2.  A state machine description that does not include all
combinations of events x states is incomplete.  For example,
it is valid (for the NAS) to receive STI in Open, and action
is required.  Some other combinations are not valid, but
something needs to be specified, especially if a state
transition should result.

3.  If I'm not mistaken you've overloaded "auth" as both
authentication and authorization.  I sure wish we had
terms that could not be so confounded.

4.  Role-independent description makes me a little nervous.
A NAS should certainly treat an incoming access-request
quite differently than a server, and having one FSM
description buries this fundamental difference in the
notion of "successfully processed".

Barney

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 23 Jan 2001 16:55:37 -0800 (PST)

> but I won't be fanatic about it.

check. SHOULD->MAY, and cleanup as an action.

> transition should result.

OOps, missed the STI :(

I do not see any other valid combinations, so perhaps a statement that
anything outside the state machine is an error (as opposed to listing every
possible error condition)?

> terms that could not be so confounded.

Not really. I see authorization as granting access. Authentication is a means
towards authorization (in some cases).

> notion of "successfully processed".

I hated this one as well, but it was the ONLY line that was NAS specific. I
will look at changing it so it is cleaner, but I had to have two (nearly
identical) state machines.

Thanks,

PatC