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

From: "Bob Kopacz" <[email-masked]>
Date: Wed, 6 Feb 2002 10:22:41 -0500

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.

---

From: Johan Johansson <[email-masked]>
Date: Wed, 06 Feb 2002 21:48:28 +0000

I agree with essentially everything, but I am not so sure about this:

 >  receiving the negative ASA.
I am not sure what would be gained by not terminating the session at the
server and I think keeping it can be harmful. The server has already
stated that the session must go, so any client not heeding the ASR would
be on its own. How would you get rid of the session *ever* on the server
if the client refuses to terminate it?

In the mobile ip application you have at least two sessions for each
user. If the HA session is terminated the session in the FA will receive
an ASR. Whether the FA complies or not the session is for all practical
purposes defunct once the HA terminates its end.

Please, someone, explain to me why ASRs don't have termination cause
codes when STRs do.

j

---

From: "Bob Kopacz" <[email-masked]>
Date: Thu, 7 Feb 2002 11:29:16 -0500

Hi Johan,

> From: Johan Johansson [[email-masked]]
> Sent: Wednesday, February 06, 2002 4:46 PM
> To: Bob Kopacz
> Subject: Re: [AAA-WG]: [issue] Changes to state machine for ASR/ASA
> messages
> 
> be on its own. 

My thinking, and I could be wrong, was that the server's session state
should reflect the reality of the session, rather than what the server
wishes.  So in the case where the HA responds with "unable to comply",
the session is still going on.  

Also, if the server terminates the session in this case, and then the
session (still alive from the MN, FA, and HA's standpoint) undergoes a
handoff, the server will incorrectly see this as a new session and
issue a new Session-Id and Acct-Multi-Session-Id to the HA.  I don't
know if this would confuse things.

> How would you get rid of the session *ever* on the server 

My thinking is also that the server has some a tool where an
administrator can force the server to clear a session if the ASR
doesn't work, this being useful in the case where the server is
hanging on to a phantom session because it got out of sync with the
HA, or the server is unable to reach the HA.

> an ASR. 

I'm not sure the FA would receive an ASR.  My understanding is that
the AAAH issues his ASR to the HA, and it is up to the AAAF to issue
any ASRs to the FA.  So I think what would happen here is that:
1. The AAAH issues an ASR to the HA.
2. The HA clears the session, sending an ASA and STR to the AAAH, and
a issues a session-clearing Mobile-IP message to the FA.  The FA then
clears his session and issues an STR.

> Whether the FA complies or not the session is for all practical 

True.  But I was thinking about the case where the HA didn't terminate
its end.

> Please, someone, explain to me why ASRs don't have termination cause 

I think a terminate cause for an ASR would be useful, though not quite
as useful as the STR's termination cause.  For many circumstances
where the AAAH clears a session, e.g. session-timeout or authorization
lifetime expiration, an ASR isn't sent.  So I'm guessing that many
ASRs would just carry a termination-cause of "Administrative action"
or something like that.

Would probably have to submit an issue for this to be considered
rather than ignored.

> j 

Bob K.

---

From: Johan Johansson <[email-masked]>
Date: Thu, 07 Feb 2002 21:42:32 +0000

>know if this would confuse things.
This depends. If both the HA and FA agree that the session is still 
going on and the AAAH attempts to start a new "multi session" the HA 
will inform it of its mistake as specified in the mip draft. If only the 
FA thinks that the session is still going on it is mistaken - it is not. 
If only the HA thinks the session is still up it will connect the old 
and the new sessions by returning what it considers to be the valid 
multi session id.

>HA, or the server is unable to reach the HA.
Of course. The question is how often you want the adminstrator to weed 
the sessions. How would he even know which ones to kill in the first place?

>any ASRs to the FA.
This is incompatible with my understanding. This *may* be the case if 
the HA is in the foreign net. I have not examined that scenario. The 
AAAF doesn't seem to be even needed if the HA is in the home network.

>  So I think what would happen here is that:
Sure, this would work. There is no specification of the interaction 
between mobile ip and diameter in this respect - feel free to correct me 
of course - but terminating the diameter session through diameter would 
probably rely on other network paths, and possibly even communicate an 
explanation.

>Would probably have to submit an issue for this to be considered
If I could be sure that it is a mistake and not something done on 
purpose I would post an issue. I wish it was possible to discuss things 
before you have to claim that something is wrong. This doesn't seem to 
be the case though.

j