Subject: [AAA-WG]: [issue] Proposal to modify STI

From: Paul Funk <[email-masked]>
Date: Sat, 26 May 2001 20:45:35 -0400

Submitter name: Paul Funk 
Submitter email address: [email-masked] 
Date first submitted: May, 20001 
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00881.html 
Document: Base 
Comment Type: Technical 
Priority: 1 
Section: (throughout) 
Rationale/Explanation of issue: 
There is a desire to eliminate the STI message. Currently, a 
server that wishes to terminate a session requires 1.5 round 
trips (STI, STR, STA). 

Requested change:

The conclusion at the interim meeting was that notification by the access 
device to the authorizing server that a session has ended (STR/STA) should 
be treated independently from a session management sort of request by 
some server (possibly the authorizing one) to the access device to abort
the session (STI).

In addition, since the interim meeting is proposing that one-way transactions 
(Indications) should be eliminated, the abort request would be two-way, i.e., 
Request/Answer, rather than STI.

Other situations are also covered in the suggested language below, 
such as sessions that never start and proxy interceptions.

Suggested language:

10.8  Session Termination

It is necessary for a Diameter server that authorized a session to be 
notified when that session is no longer active, both for tracking purposes 
as well as to allow the Diameter server to release any resources that it 
may have provided for the user session.

When a user session that required Diameter authorization terminates, the 
access device that provided the service MUST issue a Session-Termination-
Request (STR) message to the Diameter server that authorized the service, 
to notify it that the session is no longer active. An STR MUST be issued 
when a user session terminates for any reason, including user logoff, 
expiration of Session-Timeout, administrative action, termination upon 
receipt of an Abort-Session-Request (see below), orderly shutdown of the 
access device, etc.

The access device also MUST issue an STR for a session that was 
authorized but never actually started. This could occur, for example, due 
to a sudden resource shortage in the access device, or because the 
access device is unwilling to provide the type of service requested in the
authorization, or because the access device does not support a 
mandatory AVP returned in the authorization, etc.

It is also possible that a session that was authorized is never actually 
started due to action of a proxy. For example, a proxy may modify an 
authorization answer, converting the result from success to failure, prior 
to forwarding the message to the access device. A proxy that causes 
an authorized session not to be started MUST issue an STR to the 
Diameter server that authorized the session, since the access device has 
no way of knowing that the session had been authorized.

A Diameter server that receives an STR message MUST clean up 
resources (e.g., session state) associated with the Session-Id specified 
in the STR, and return a Session-Termination-Answer.

A Diameter server also MUST clean up resources when the Session-
Timeout expires, or when the Authorization-Lifetime expires without 
re-authorization, regardless of whether an STR for that session is 
received. The access device is not expected to provide service beyond 
the expiration of these timers; thus, expiration of either of these timers 
implies that the access device may have unexpectedly shut down.

10.8.1  Session-Termination-Request

The Session-Termination-Request (STR), indicated by the Command-
Code set to 275 and the message flags' 'R' bit set, is sent by the access
device to inform the Diameter Server that an authenticated and/or 
authorized session is being terminated.

Message Format

      <Session-Termination-Request>  ::= < Diameter Header: 275, R >
                                         < Session-Id >
                                         { Origin-FQDN }
                                         { Origin-Realm }
                                         { User-Name }
                                         { Destination-Realm }
                                         { Destination-FQDN }
                                         [ Max-Wait-Time ]
                                       * [ AVP ]
                                       * [ Proxy-Info ]
                                       * [ Route-Record ]

10.8.2  Session-Termination-Answer

The Session-Termination-Answer (STA), indicated by the Command-
Code set to 275 and the message flags' 'R' bit clear, is sent by the
Diameter Server to acknowledge the notification that the session has 
been terminated. The Result-Code AVP MUST be present, and MAY 
contain an indication that an error occurred while servicing the STR.

Upon sending or receipt of the STA, the Diameter Server MUST 
release all resources for the session indicated by the Session-Id AVP. 
Any intermediate server in the Proxy-Chain MAY also release any
resources, if necessary.

Message Format

      <Session-Termination-Answer>  ::= < Diameter Header: 275 >
                                        < Session-Id >
                                        { Result-Code }
                                        { Origin-FQDN }
                                        { Origin-Realm }
                                        { Destination-FQDN }
                                        { User-Name }
                                      * [ AVP ]
                                      * [ Proxy-Info ]
                                      * [ Route-Record ]

10.9  Aborting a Session

A Diameter server may request that the access device stop providing 
service for a particular session by issuing an Abort-Session-Request 
(ASR).

For example, the Diameter server that originally authorized the session 
may be required to cause that session to be stopped for credit or other 
reasons that were not anticipated when the session was first authorized. 
Or, an operator may maintain a management server for the purpose of 
issuing ASRs to administratively remove users from the network.

An access device that receives an ASR with Session-ID equal to a 
currently active session MAY stop the session. Whether the access 
device stops the session or not is implementation- and/or configuration-
dependent. For example, an access device may honor ASRs from 
certain servers only. In any case, the access device MUST respond with 
an Abort-Session-Answer, including a Result-Code AVP to indicate what 
action it took.

Note that if the access device does stop the session upon receipt of an 
ASR, it issues an STR to the authorizing server (which may or may not 
be the server issuing the ASR) just as it would if the session were 
terminated for any other reason.

10.9.1  Abort-Session-Request

The Abort-Session-Request (ASR), indicated by the Command-Code set 
to [nnn] and the message flags' 'R' bit set, may be sent by any server to 
the access device that is providing session service, to request that the 
session identified by the Session-Id be stopped.

      <Abort-Session-Request>  ::= < Diameter Header: nnn, R >
                                   < Session-Id >
                                   { Origin-FQDN }
                                   { Origin-Realm }
                                   { Destination-Realm }
                                   { Destination-FQDN }
                                 * [ AVP ]
                                 * [ Proxy-Info ]
                                 * [ Route-Record ]

10.9.2  Abort-Session-Answer

The Abort-Session-Answer (ASA), indicated by the Command-Code set 
to [nnn] and the message flags' 'R' bit clear, is sent in response to the 
ASR. The Result-Code AVP MUST be present, and indicates the 
disposition of the request.

If the session identified by Session-Id in the ASR was successfully 
terminated, Result-Code is set to DIAMETER_SUCCESS. If the session 
is not currently active, Result-Code is set to 
DIAMETER_UNKNOWN_SESSION_ID. If the access device does not 
stop the session for any other reason, Result-Code is set to [what? 
should there be a generic failure result code?].

      <Abort-Session-Answer>  ::= < Diameter Header: nnn >
                                  < Session-Id >
                                  { Result-Code }
                                  { Origin-FQDN }
                                  { Origin-Realm }
                                  { Destination-FQDN }
                                * [ AVP ]
                                * [ Proxy-Info ]
                                * [ Route-Record ]

Paul

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]