Subject: [AAA-WG]: Issue #275: Changes to state machine for ASR/ASA messages

From: <[email-masked]>
Date: Wed, 27 Feb 2002 09:42:19 +0200

Hi Bob,

Some clarification needed:

The base spec has:

Open      Home server wants to           send ASR   Discon
          terminate the service

Open      ASR Received                   send ASA,  Discon
                                         STR

		.....

Discon    ASA Received                   Cleanup    Idle

Discon    ASR Received                   None       Discon

Discon    STR Received                   Send STA   Idle

Discon    STA Received                   Discon.    Idle
                                         user/device

What do you want done with this?

Open      ASR Received                   send ASA,  Discon
                                         STR

John

Issue #275
Issue : Changes to state machine for ASR/ASA messages
Submitter name: Bob Kopacz
Submitter email address: [email-masked] 
Date first submitted: 02-06-2002 
Reference: 
Document: base-08 
Comment type: Technical 
Priority: 1 
Section: 8.1
Rationale/Explanation of issue: 

  I believe there is an error in the "Authorization Session State
  Machine", in section 8.1 of the base draft, in the 1st state machine
  which represents the case where the server maintains session-state.

  If, for a session in OPEN state, the server wants the session to be be
  terminated, it sends an ASR and goes into DISCON state.  When the ASA
  is received, the server goes into IDLE state.  The state/events I am
  referring to are:

  |  The following state machine is used when state is maintained on the
  |  server:
  | 
  |     State     Event                          Action     New State
  |     -------------------------------------------------------------
  | 
  |     Open      Home server wants to           send ASR   Discon
  |               terminate the service
  | 
  |     Discon    ASA Received                   Cleanup    Idle
  
  This seems not quite right for a few reasons.

  (1) When the server subsequently receives the follow-up STR from the
  access device, the session will be either non-existent or in IDLE
  state.

  (2) An ASR is only a request to terminate a session.  It doesn't
  really go away until the session-timeout expires, the
  authorization-lifetime expires, or the access device sends an STR.  So
  sending an ASR should not affect the server's state (OPEN), and
  receiving an ASA should in general not affect the server's state
  (OPEN).

  (3) The state machine doesn't take into account the Result-Code
  returned in the ASA.  The draft indicates that an access device is not
  required to honor an ASR, i.e. the access device can just reply with
  "unable to comply" and not terminate the session.  In this case the
  server would have incorrectly terminated an active session when 
  receiving the negative ASA.

  When an ASR is sent, the Result-Code values likely to be returned in
  the ASA are:

  SUCCESS -- This means that the access device will be following the
  ASA with an STR, so the server can just wait for the STR.

  UNABLE_TO_COMPLY -- The access device has no intention of terminating
  the session.

  UNKNOWN_SESSION_ID -- The access device doesn't know about this
  session.  Somehow the access device and server have gotten out of
  sync.  The server can go ahead an clean up this phantom session.

  UNABLE_TO_DELIVER -- The ASR never made it to the access device, so
  the access device won't be terminating this session, if it even
  exists.

Requested change: 

  Replace the two entries:
    
  | State     Event                          Action     New State
  | -------------------------------------------------------------
  | 
  | Open      Home server wants to           send ASR   Discon
  |           terminate the service
  | 
  | Discon    ASA Received                   Cleanup    Idle

  With:

  | State     Event                          Action     New State
  | -------------------------------------------------------------
  |     
  | Open      Home server wants to           send ASR   Open
  |           terminate the service
  |     
  | Open      ASA Received                   Cleanup    Idle
  |           with Result-Code 
  |           = UNKNOWN-SESSION-ID
  |     
  | Open      ASA Received                   None       Open
  |           with Result-Code               (ignore)
  |           not = UNKNOWN-SESSION-ID
  |     
  | Not       ASA Received                   None       No Change.
  | Open

  Notes on the above four entries (this is FYI, not part of draft):

  Entry#1. The ASR doesn't do anything on its own, so just stay
  in OPEN state and wait for the ASA.

  Entry#2. This is the case where the server is out of sync with the access
  device.  This is a phantom session that the server can remove.

  Entry#3. If SUCCESS, the access device will soon send an STR, which
  will terminate the session.  If not SUCCESS, the access device won't
  be terminating the session, so it stays active.

  Entry#4. Here something happened to the session between the time the
  ASR was sent and the ASA was received.