Subject: [AAA-WG]: [issue] 3GPP2 Accounting Requirements

From: David Spence <[email-masked]>
Date: Fri, 18 May 2001 18:17:24 -0400

Subject: [issue] 3GPP2 Accounting Requirements

Submitter name: David Spence
Submitter email address: [email-masked]
Date first submitted: May 18, 2001
Reference: http://www.3gpp2.org/Public_html/specs/P.S0001-A-1.pdf
Document: Accounting, MobileIP
Comment type: T
Priority: ?
Section: 
Rationale/Explanation of issue:

    Is it an AAA WG requirement that we meet 3GPP2 requirements?  If so,
    then the following may be an issue.

    3GPP2 document P.S0001-A-1, "Wireless IP Network Standard" specifies
    use of a variety of public standards to realize wireless IP service.
    Included in the document is a specification for how RADIUS should be
    used.  A number of RADIUS vendor-specific attributes are defined
    including many accounting attributes.

    The standard realizes version 1 of an architecture defined in 3GPP2
    document P.R0001, "Wireless IP Architecture Based on IETF Protocols".
    Version 2 of the architecture specified in this document goes on to
    define a number of AAA requirements essentially all met by Diameter
    with the exceptions described below.

    The "Wireless IP Network Standard" defines quite a number of
    vendor-specific accounting attributes, many of which report Radio
    Network counters.  When a wireless handoff takes place, the counts
    collected at the old Radio Network need to be transmitted to the
    accounting server.  Thus, at the end of the Packet Data Session,
    there may be multiple accounting sub-records.  The standard specifies
    two ways to handle this in RADIUS.  The first is to bundle the
    attributes of a subsession into an Accounting-Container attribute
    (similar to a Grouped type AVP).  This requires these attributes to
    be held in the Packet Data Serving Node (PDSN -- the node that
    contains the FA) until the end of the session and then they are all
    sent to the AAA server in a single Accounting Stop message.  To allow
    subsession accounting data to be forwarded to the AAA servers as
    generated, the standard specifies a second method.  A vendor specific
    Correlation-ID attribute is defined to supplement the RADIUS
    Account-Session ID attribute.  They also define a Session-Continue
    attribute.  Each time during the session that a PDSN has accounting
    data to send, it generates an Accounting Stop message which includes
    a Session-Contine attribute with a value of True.  This is
    immediately followed by an Accounting Start message with a new
    Account-Session ID which begins the next sub-session.  All accounting
    messages sent for the Packet Data Session contain the same value of
    the Correlation-ID attribute which then becomes the session
    identifier that can be used to correlate accounting messages with
    authentication messages.  This is messy in RADIUS and would be worse
    in Diameter.

Requested change:

    1. Define all the 3GPP2 vendor specific accounting attributes as
       Diameter AVPs in the MIP extension.

    2. Invent a clean way to carry subsession accounting data in
       Diameter, perhaps by inventing a Subsession-Identifier AVP and a
       Subsession accounting message in the base protocol.

-- 
David Spence                            email: [email-masked]
Interlink Networks, Inc.                phone: (734) 821-1203
775 Technology Drive, Suite 200         fax:   (734) 821-1235
Ann Arbor, MI 48108           
U.S.A.

---

From: David Spence <[email-masked]>
Date: Wed, 30 May 2001 15:43:33 -0400

The following summarizes the discussion of this issue at the May
    interim meeting and raises further discussion.

    As discussed at the May interim meeting, the important part of this
    issue is how to handle multiple accounting records per authentication
    session.  At the meeting, we decided to see if we could use the
    Acct-Multi-Session-Id AVP for this purpose.

    We did not discuss the details, so the following is how I imagine
    this might work.  The idea is that the Acct-Multi-Session-ID AVP
    would replace the Correlation-ID attribute defined by 3GPP2.  It
    would be included both in the authentication/authorization request
    (AMR and HAR) messages and in the Accounting Request (ACR) message.
    The Session-ID AVP would take on a different value at each handoff.
    We would not use the Session-Continue attribute, because Diameter
    does not use accounting messages to control session state.

    At the interim meeting, we decided not to define IETF standard
    accounting AVPs to track the 3GPP2 accounting attributes, but to
    continue to allow 3GPP2 to define accounting attributes out of their
    vendor-specific numbering space.

    If we adopt this proposal then the Acct-Multi-Session-ID AVP should
    be specified in the base protocol.

    In thinking about this proposal since the interim meeting, I do have
    one reservation.  In the primary use of the Acct-Multi-Session-ID AVP
    to support PPP Multilink connections, there is an authentication/
    authorization request for each single link as it comes up.  Thus,
    each Accounting-Request message can be matched to an authentication/
    authorization message by using the Session-ID AVP.  With the 3GPP2
    standard, this will not be the case.  Successive accounting sessions
    do not have corresponding auth/auth sessions.  Instead, one long
    auth/auth session will match a series of shorter accounting sessions.

    For this reason, I think it might be better to use the auth/auth
    Session-ID for all of the Accounting-Request messages in the series,
    but to use some new AVP to indicate that this is one of a series of
    Accounting-Requests, and that all requests in the series are
    significant and need to be kept (that is, later messages are not
    updates to earlier messages which can then be thrown away).