Subject: RE: [AAA-WG]: Proposed Session text

From: Yiwen Jiang <[email-masked]>
Date: Thu, 3 May 2001 17:58:42 -0400

Hi Pat,

Thanks for the update...

One thing I noticed is that there is a cut and paste error for 11.2 title,
should be accounting session state machine, rather than authorization state
machine? 

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Thursday, May 03, 2001 2:51 PM
> To: [email-masked]
> Subject: [AAA-WG]: Proposed Session text
> 
> 
> All,
> 
> As discussed in another thread, I am proposing the following text to 
> replace section 11.0 and 11.1 in the -02 version. This text 
> is to handle
> the fact that an application can make use of accounting only.
> 
> Comments?
> 
> PatC
> ----
> 11.0  "User" Sessions
> 
>    Diameter can provide two different type of services to 
> applications.
>    The first involves authentication and authorization, and can
>    optionally make use of accounting. The second only makes use of
>    accounting.
> 
>    When a service makes use of the authentication and/or authorization
>    portion of an extension, and a user requests access to the network,
>    the Diameter client issues an auth request to its local server. The
>    auth request is defined in a service specific Diameter extension
>    (e.g. NASREQ). The request contains a Session-Id AVP, which is used
>    in subsequent messages (e.g. subsequent authorization, accounting,
>    etc) relating to the user's session. The Session-Id AVP is a means
>    for the client and servers to correlate a Diameter message with a
>    user session.
> 
>    When a Diameter server authorizes a user to use network 
> resources, it
>    SHOULD add the Authorization-Lifetime AVP to the response. The
>    Authorization-Lifetime AVP defines the maximum amount of 
> time a user
>    MAY make use of the resources before another authorization 
> request is
>    to be transmitted to the server. If the server does not receive
>    another authorization request before the timeout occurs, it SHOULD
>    release any state information related to the user's session. Note
>    that the Authorization-Lifetime AVP implies how long the Diameter
>    server is willing to pay for the services rendered, therefore a
>    Diameter client SHOULD NOT expect payment for services 
> rendered past
>    the session expiration time.
> 
>    The base protocol does not include any authorization request
>    messages, since these are largely application-specific and are
>    defined in a Diameter protocol extension document. 
> However, the base
>    protocol does define a set of messages that are used to terminate
>    user sessions. These are used to allow servers that maintain state
>    information to free resources.
> 
>    When a service only makes use of the Accounting portion of the
>    Diameter protocol, even in combination with an extension, the
>    Session-Id is still used to identify user sessions. However, the
>    session termination messages are not used, since a session is
>    signalled as being terminated by issuing an accounting 
> stop message.
> 
> 
> 11.1  Authorization Session State Machine
> 
>    This section contains a finite state machine, representing the life
>    cycle of Diameter sessions, and MUST be observed by all Diameter
>    implementations that makes use of the authentication and/or
>    authorization portion of a Diameter extension. The term Service-
>    Specific below refers to a message defined in a Diameter extension
>    (e.g. Mobile IP, NASREQ).
> 
>    The following table contains the authorization session 
> state machine.
> 
>       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      Accounting message sent or     process    Open
>                 received
> 
>       Open      Failed Service-Specific        Discon.    Closed
>                 Authorization response         user/device
>                 received.
> 
>       Open      Session-Timeout Expires on     send STR   Discon
>                 Access Device
> 
>       Open      STI Received                   send STR   Discon
> 
>       Open      Session-Timeout Expires on     send STI   Discon
>                 home AAA server
> 
>       Discon    STI Received                   ignore     Discon
> 
>       Discon    STR Received                   Send STA   Closed
> 
>       Discon    STA Received                   Discon.    Closed
>                                                user/device
> 
      Closed    Transition to state            Cleanup
> 
>    When the Cleanup action is invoked, the Diameter node MAY 
> attempt to
>    release all resources for the particular session. Any event not
>    listed above MUST be considered as an error condition, and a
>    response, if applicable, MUST be returned to the originator of the
>    message.
> 
> 
> 11.2  Authorization Session State Machine
> 
>    For applications that only require accounting services, 
> the following
>    state machine MUST be supported.
> 
>       State     Event                          Action     New State
>       -------------------------------------------------------------
>       Idle      Client or device requests      send       Pending
>                 access                         accounting
>                                                start req.
> 
      Idle      Accounting start request       send       Open
>                 received, and successfully     accounting
>                 processed.                     start
>                                                answer
> 
      Pending   Successful accounting          grant      Open
>                 start answer received          access
> 
>       Open      User service terminated        send       Discon
>                                                accounting
>                                                stop req.
> 
      Open      Accounting stop request        send       Closed
>                 received, and successfully     accounting
>                 processed                      stop answer
> 
>       Discon    Successful accounting          discon.    Closed
>                 stop answer received           user/device
> 
>

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 3 May 2001 15:11:45 -0700

> should be accounting session state machine, rather than authorization state

I guess I should pay as much attention to headers as the rest of the text :)

PatC