Subject: [AAA-WG]: DCC: new issue to replace issues 16, 17 and 18

From: <[email-masked]>
Date: Thu, 12 Feb 2004 18:02:34 +0200

Hi,

as agreed in http://www.merit.edu/mail.archives/aaa-wg/msg00176.html and http://www.merit.edu/mail.archives/aaa-wg/msg00182.html we have beed working on an updated proposal to issues 16 and 17.

The outcome is a new issue to replace issues 16 and 17 that define the independent credit control of multiple services in a (sub-)session feature. There will be a following mail with a companion issue to replace the Flow X of draft 02 according the agreed mechanism.

Finally, it was agred in http://www.merit.edu/mail.archives/aaa-wg/msg00207.html that also the tariff time change issue (issue 18) can be solved as part of the independent credit control of multiple services feature.

To summarize, this new issue replaces issues 16, 17 and 18.

Regards
Marco

--------------------------------------------------------------------
Description of issue: Independent handling of services within a session 
Submitter name: Mark Watson/Chris Richards/Marco Stura/Harri Hakala 
Date first submitted: 12.02.2004 
Reference: 
Document: draft-ietf-aaa-diameter-cc-02.txt 
Comment type: T 
Priority: 1 
Section: Various 

Rationale/Explanation of issues: 

Handling of services or rating groups within a single session or sub-session 
can only be done 'en-bloc' according to the grouping of those services of 
rating groups into (sub-)sessions by the client. In particular:

- all services or rating groups must be re-authorised at the same time 
- adding an additional service or rating group requires re-authorisation of all 
other services/rating groups in the (sub-)session

- termination actions, particularly, redirect apply to the whole (sub-)session 
- state machine handling applies to the whole (sub-)session 

This has the following disadvantages: 
- unnecessary load on the server to perform re-rating for all services and 
rating groups, particularly when adding a new service will usually have no 
effect on the rating decision for the other services

- unnecessary (though less than above) load on the client to process other 
services just to add a new one 
- not possible to leave some services under credit control when others are 
terminated/redirected (the policy for how far 'into the red' a service can run 
will depend on the service).

- when a service or rating group has quotas in multiple units, it is not 
possible to have some of those handled independently and others 'pooled'

- the construction in which multiple quotas representing the *same* monetary 
allocation are passed down from client to server is counter-intuitive and 
liable to major mis-interpretation

The above restriction stems from the manner in which the 'pooling' of quotas 
for multiple services is framed within the protocol. The quotas provided for 
different services are not semantically independent and therefore operations on 
them must be carried out 'en-bloc'.

We propose to make the quotas provided semantically independent within the 
protocol, whilst maintaining the concept of a 'credit pool' which can apply to 
multiple services across the session. Additionally, as per our other proposal, 
we propose to decouple the 'pooling' of credit from the session/sub-session. 
Please see the other proposal for the rationale for this.

In order to handle quotas within a pool separately, it is necessary to be more 
explicit within the protocol about the relationship between quotas. This is 
presently communicated implicitly based on the assumption that all quotas are 
derived from the same credit reservation in the server.

For each service/rating group and unit, we provide a 'Multiplier' value which 
is used to express the ratios between services in terms of resource usage.

If service 1 has multiplier M1 and service 2 has multiplier M2 then resources 
from service 1 can be converted to those of service 2 by multiplying by M1/M2.

The formula for determining the exhaustion of the credit for a given pool of 
quotas at the client is modified as follows: the credit pool is exhausted when

    C1*M1 + C2*M2 + ... + Cn*Mn >= M 

Where M is the total credit for the credit-pool. M is initially calculated from 
the granted quotas in the pool as follows:

    M = Q1*M1 + Q2*M2 + ... + Qn*Mn 

This is pretty much equivalent to the existing formula (with Mi = M/Qi), with 
the following advantages: 
(i) new services can be added/removed without reference to the existing ones - 
M is simply modified by (Quota*Multiplier) for the added/removed service

(ii) all quotas returned in CC answers cleanly represent independent 
authorizations to use the indicated resource 
(iii) re-authorisation can be sought for an individual service/rating group 
(for example if another quota associated with the same service/rating group is 
exhausted)

(iv) flexibility, low signaling overhead and avoidance of credit fragmentation 
are maintained 

Note that where a Granted-Service-Unit contains more than one resource unit 
(e.g. Time and Volume) then multipliers can be provided for one or more of 
them. Where two multipliers are provided (e.g. M1t for time and M1v for volume) 
then the used resource from the pool is the sum C1t*M1t + C1v*M1v. Note that 
the draft at present does not include an explicit description of the handling 
of services with more than one resource unit with respect to credit pooling.

Finally, we propose to add the Final-Unit-Indication and Validity-Time AVPs to 
the Granted-Service-Unit APV to express independent handling of the different 
services in these respects.

Requested change: 

Overview: 

To implement the above mechanism, we extend the proposal made in Issue xxx on 
server control of credit pooling by adding the multiplier to the G-S-U-Pool-
Reference AVP. The multiplier is expressed using the Unit-Value AVP.

We therefore add the following AVPs: 

    G-S-U-Pool-Reference AVP - contains a reference to a credit pool, a unit-
type and a multiplier (using the Unit-Value AVP). It is used within Granted-
Service-Units AVP to indicate that credit of a particular type is pooled.

    CC-Unit-Type AVP - indicates the type of units (time, volume) that are 
pooled. 

    G-S-U-Identifier AVP - identifies the credit pool. 

Detailed changes:

-section 3.1 Credit-Control-Request (CCR) Command 

FROM:
 <Credit-Control-Request> ::= < Diameter Header: 272, REQ, PXY > 
                                      :
                             *[ Requested-Service-Unit ] 
                                      :
                             *[ Used-Service-Unit ]   
                                      :
TO:
 <Credit-Control-Request> ::= < Diameter Header: 272, REQ, PXY > 
                                      :
                              [ Requested-Service-Unit ] 
                                      :
                             *[ Used-Service-Unit ]  
                              [ Multiple-Services-Indicator ]   
                             *[ Multiple-Services-Credit-Control ]  

-Section 3.2 Credit-Control-Answer (CCA) Command 

FROM:
 <Credit-Control-Answer> ::= < Diameter Header: 272, PXY > 
                                     :
                            *[ Granted-Service-Unit ]  
                                     :

TO:
 <Credit-Control-Answer> ::= < Diameter Header: 272, PXY > 
                                     :
                             [ Granted-Service-Unit ]  
                            *[ Multiple-Services-Credit-Control]
                                     :
- Section 5, REMOVE fifth paragraph: 
   When multiple services are used within one user session and each 
   service or group of services are subject to different cost, 
   making use of credit control sub-sessions will result in increased
   signaling load and resources usage in both the credit control
   client and the credit control server. For instance, during one
   network access session the end user may use several http-services
   subject to different access cost. To optimally support these
   scenarios, the credit control application enables for multiple
   services credit control in a single credit control session. It is
   possible to request and allocate multiple quotas as a credit pool
   that is shared between multiple services. The services can be
   further grouped into rating groups in order to achieve even 
   further aggregation of credit allocation. It is also possible to
   request and allocate multiple quotas on a per service 
   basis. The mechanism is illustrated in Appendix A (Flow X).

ADD new heading "5.1 General Principles" immediately after 
heading 5. Session Based Credit-control

ADD new section 5.1.1 (at the end of the above new 5.1):

5.1.1 Credit-Control for Multiple Services within a (sub-)Session

   When multiple services are used within one user session and each 
   service or group of services are subject to different cost, it is
   necessary to perform credit-control for each of these services
   somewhat independently. Making use of credit control sub-sessions
   to achieve independent credit-control will result in increased
   signaling load and resources usage in both the credit control
   client and the credit control server. For instance, during one
   network access session the end user may use several http-services
   subject to different access cost, the network access specific
   attributes such as the quality of service (QoS) are common to all
   the services carried within the access bearer, but the cost of the
   bearer may vary dependent on its content. 
   
   To optimally support these scenarios, the credit control
   application enables for independent credit control of multiple
   services in a single credit control (sub-)session. This is
   achieved  by including the optional Multiple-Services-Credit- 
   Control AVP in Credit-Control-Request/Answer messages. It is
   possible to request and allocate resources as a credit pool that
   is shared between multiple services. The services can be further
   grouped into rating groups in order to achieve even further 
   aggregation of credit allocation. It is also possible to request
   and allocate quotas on a per service basis. Where quotas
   are allocated to a pool by means of the Multiple-Services-Credit-
   Control AVP, the quotas remain independent objects which can be
   re-authorised independently at any time. Quotas can also be given
   independent result codes, validity times and Final-Unit-
   indications.
   
   In case independent credit control of multiple services is used
   the validity-time and final-unit-indication SHOULD only be present
   either in the Multiple-Service-Credit-Control AVP(s) or at command 
   level as single AVPs.
   However, the Result-Code AVP MAY be present both on the command
   level and within the Multiple-Services-Credit-Control AVP. If the
   Result-Code on the command level indicates other value than
   SUCCESS then the Result-Code on command level takes precedence
   over the one(s) included in the Multiple-Services-Credit-Control
   AVP.

   The Credit-control client MUST indicate support for independent
   credit control of multiple services within a (sub-)session by
   including the Multiple-Services-Indicator AVP in the first
   interrogation. A Credit-Control-server not supporting the
   feature MUST treat the Multiple-Services-Indicator AVP and
   possibly received Multiple-Services-Credit-Control AVPs as 
   invalid AVPs.

   If the client indicated support for independent credit control of
   multiple services, a credit-control server that whishes to use the
   feature MUST return the granted units within the Multiple-
   Services-Credit-Control AVP associated to the corresponding
   service-identifier and/or rating-group.

   To avoid credit fragmentation and unnecessary load on the credit
   control server, it is possible for service units to be provided 
   to multiple services or rating groups as a pool. 
   This is achieved by providing the service units in the form of a
   quota for a particular service or rating group in the Multiple-
   Services-Credit-Control AVP, but also including a reference to a
   credit pool for that unit type. 
   The reference includes a multiplier derived from the rating
   parameter, which translates from service units of a specific type
   to the abstract service units in the pool. For instance if the
   rating parameter for service 1 is $1/MB and rating parameter for
   service 2 is $0.5/MB the multipliers could be 10 and 5 for service
   1 and service 2 respectively.

   If M is the total service units within the pool, M1, M2, ... , Mn
   are the multipliers provided for services 1, 2, ..., n and C1, C2,
   ... ,Cn are the used resources within the session, then the pool
   credit is exhausted and re-authorisation MUST be sought when: 
        C1*M1 + C2*M2 + ... + Cn*Mn >= M 
   The total credit in the pool, M, is calculated from the quotas
   which are currently allocated to the pool as follows: 
        M = Q1*M1 + Q2*M2 + ... + Qn*Mn    
    
   If services or rating groups are added to or removed from the
   pool, then the total credit is adjusted appropriately. Note that
   when the total credit is adjusted because services or rating
   groups are removed from the pool, the value that need to be
   removed is the consumed one (i.e. Cx*Mx).  
   Re-authorisation for an individual service or rating group may be
   sought at any time, for example if a 'non-pooled' quota is used up
   or the Validity-Time expires. 

   Where multiple G-S-U-Pool-Reference AVPs with the same G-S-U-Pool 
   Identifier are provided within a Multiple-Services-Credit-Control
   AVP together with the Granted-Service-Unit AVP, then these MUST
   have different CC-Unit-Type values and they all draw on the credit
   pool separately. For instance if one multiplier for time (M1t) and
   one multiplier for volume (M1v) are given, then the used resources
   from the pool is the sum C1t*M1t + C1v*M1v, where C1t are the time 
   units and C1v are the volume unit. 
   Where service units are provided within a Multiple-Services-
   Credit-Control AVP without a corresponding G-S-U-Reference AVP
   then these are handled independently from any credit pool and from
   any other services or rating groups within the session.

   The credit pool concept is an optimal tool to avoid the over-reservation 
   effect of the basic single quota tariff time change mechanism 
   (the mechanism described in section 5.1). Therefore, Diameter credit-
   control clients and servers implementing the independent credit control 
   of multiple services SHOULD leverage the credit pool concept when supporting 
   the tariff time change. The Diameter credit-control server SHOULD include 
   both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota 
   allocations in the answer message (i.e. two instances of the Multiple-
   Services-Credit-Control AVP). One of the granted units is allocated to be 
   used before the potential tariff change while the second granted units 
   are used after a tariff change. Both granted unit quotas MUST contain 
   the same Service-Identifier and/or Rating-Group values and MUST belong 
   to the same pool. 
   This dual quota mechanism ensures that the overall reported used units 
   would never exceed the credit reservation.  
   The Diameter credit-control client reports both the used units before 
   and after the tariff change in a single instance of the Multiple-Services
   -Credit-Control AVP.
   
   The failure handling for the credit control session is defined 
   in section 5.6 and reflected to the basic credit-control state 
   machine in section 7. Credit-control client and servers implementing 
   the independent credit control of multiple services in a (sub-)session 
   functionality MUST ensure a failure handling and general behavior 
   fully consistent with the above mentioned sections while capable of 
   handling parallel ongoing credit re-authorization within a (sub-)session. 
   It is then RECOMMENDED that Diameter credit-control clients maintain 
   a PENDING-U message queue and restarts the Tx timer every time a 
   CCR[Update] message is sent while in PENDING-U state. When answers 
   to all the pending messages are received the state machine moves to 
   OPEN and Tx is stopped. Naturally the action performed when a problem 
   is detected for the session according to section 5.6, affect all the 
   ongoing services (e.g. failover to a backup server if possible affect 
   all the CCR[Update] messages in the PENDING-U queue).

   Since the client may send CCR[Update] messages while in PENDING-U 
   (i.e. without waiting for an answer to ongoing credit re-authorization), 
   the time space between these requests may be very short and the server 
   may not have received the previous request(s) yet. Therefore in this 
   situation the server may receive out of sequence requests and SHOULD NOT 
   consider this as an error condition, a proper answer is to be returned 
   to each of those requests.

-Section 5.4 Server-Initiated Credit Re-Authorization

FROM

The Diameter Credit Control Application supports the server-initiated re-authorization. The credit control server MAY optionally initiate the credit re-authorization by issuing a Re-Auth-Request (RAR) as defined in the Diameter base protocol [DIAMBASE]. The Auth-Application-Id in the RAR message is set to 4 to indicate the Diameter Credit Control Application and the Re-Auth-Request-Type is set to AUTHORIZE_ONLY.

If a credit re-authorization is not already ongoing (i.e. the credit control session is in OPEN state), a credit control client that receives such a RAR message with Session-Id equal to a currently active credit control session acknowledges the request by sending the Re-Auth-Answer (RAA) message and MUST initiate the credit re-authorization towards the server by sending a Credit-Control-Request message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indicate an additional message (i.e. CCR[Update]) is required to complete the procedure. If a quota was allocated to the session, the credit control client MUST report the used quota in the Credit-Control-Request. Note that the end user does not need to be prompted for the credit re-authorization, since the credit re-authorization is transparent to the user (i.e it takes place exclusively between the credit control client and the credit control server).

If credit re-authorization is ongoing at the time when the RAR message is received (i.e. RAR-CCR collision), the credit control client successfully acknowledges the request but it does not initiate a new credit re-authorization. The Result-Code 2001 (DIAMETER_SUCCESS) SHOULD be used in the RAA message to indicate a credit re-authorization procedure is already ongoing (i.e. the client was in PendingU state when the RAR was received). The credit control server SHOULD process the Credit-Control-Request as if it was received in answer to the server initiated credit re-authorization, and should consider the server initiated credit re-authorization process successful upon reception of the Re-Auth-Answer message.

If several credit control sub-sessions are in use, a credit control client receiving the RAR command for a given session will trigger credit re-authorization for all the sub-session separately.

TO

The Diameter Credit Control Application supports the server-initiated re-authorization. The credit control server MAY optionally initiate the credit re-authorization by issuing a Re-Auth-Request (RAR) as defined in the Diameter base protocol [DIAMBASE]. The Auth- Application-Id in the RAR message is set to 4 to indicate the Diameter Credit Control Application and the Re-Auth-Request-Type is set to AUTHORIZE_ONLY.

Where multiple services in a user's session are supported as defined in section 5.1.1, the server MAY request credit re-authorization at: (sub-)session level, credit pool level granularity, service-identifier level granularity or rating-group granularity. To request credit re-authorization at credit pool granularity the server includes in the RAR message the G-S-U-Pool-Identifier AVP indicating the affected pool. 
To request credit re-authorization at service or rating-group granularity the server includes in the RAR message the Service-Identifier AVP or the Rating-Group AVP respectively. To request credit re-authorization for all the ongoing services within the (sub-)session the server does not include any of the above mentione AVPs in the RAR message.

If a credit re-authorization is not already ongoing (i.e. the credit control session is in OPEN state), a credit control client that receives a RAR message with Session-Id equal to a currently active credit control session acknowledges the request by sending the Re-Auth-Answer (RAA) message and MUST initiate the credit re- authorization towards the server by sending a Credit-Control-Request message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indicate an additional message (i.e. CCR[Update]) is required to complete the procedure. If a quota was allocated to the session, the credit control client MUST report the used quota in the Credit-Control-Request. Note that the end user does not need to be prompted for the credit re-authorization, since the credit re- authorization is transparent to the user (i.e it takes place exclusively between the credit control client and the credit control server).

Where multiple services in a user's session are supported, the procedure of the above paragraph will be executed at the granularity as requested by the server in the RAR message.

If credit re-authorization is ongoing at the time when the RAR message is received (i.e. RAR-CCR collision), the credit control client successfully acknowledges the request but it does not initiate a new credit re-authorization. The Result-Code 2001 (DIAMETER_SUCCESS) SHOULD be used in the RAA message to indicate a credit re- authorization procedure is already ongoing (i.e. the client was in PendingU state when the RAR was received). The credit control server SHOULD process the Credit-Control-Request as if it was received in answer to the server initiated credit re-authorization, and should consider the server initiated credit re-authorization process successful upon reception of the Re-Auth-Answer message.
Where multiple services in a user's session are supported, it may happen that the server requests credit re-authorization for a credit pool (or for the (sub-)session) and a credit re-authorization is already ongoing for some of the services or rating-groups. In this case the client acknowledges the server request with a RAA message and MUST send a new Credit-Control-Request message to perform re-authorization for the remaining services/rating-groups of the pool. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indicate an additional message (i.e. CCR[Update]) is required to complete the procedure. The server processes the received requests and returns an appropriate answer to both of the requests.
   
The above defined procedures are enabled for each of the possibly active Diameter credit-control sub-sessions. The server MAY request re-authorization for an active sub-session by including the CC-Sub-Session-Id AVP in the RAR message in addition to the Session-Id AVP.

-Section 5.5 Graceful Service Termination change second paragraph

FROM

This section defines the graceful service termination optional feature that MAY be supported by the credit control server. Credit control client implementations MUST support the Final-Unit-Indication with at least the tear down of the ongoing service session upon the subscriber has consumed all the final granted units.

TO

This section defines the graceful service termination optional feature that MAY be supported by the credit control server. Credit control client implementations MUST support the Final-Unit-Indication with at least the tear down of the ongoing service session upon the subscriber has consumed all the final granted units.
Where independent credit control of multiple services in a single credit control (sub-)session is supported, it is possible to use the graceful service termination for each of the services/rating-groups independently.

- Section 8 - add to the table: 
                                            +---------------------+  
                                            |    AVP Flag rules   |  
                                            |----+-----+----+-----|----+  
                  AVP  Section              |    |     |SHLD| MUST|    |  
   Attribute Name    Code Defined Data Type |MUST| MAY | NOT|  NOT|Encr|  
   -----------------------------------------|----+-----+----+-----|----|  
   G-S-U-Pool-       tbd  8.X     Unsigned32| M  | P   |    |  V  | Y  | 
      Identifier                            |    |     |    |     |    | 
   G-S-U-Pool-       tbd  8.Y     Grouped   | M  | P   |    |  V  | Y  | 
     Reference                              |    |     |    |     |    | 
   CC-Unit-Type      tbd  8.Z     Enumerated|    |     |    |     |    |      
   Multiple-Service- tbd  8.V     Grouped   | M  |  P  |    |  V  | Y  | 
   Credit-Control                           |    |     |    |     |    |
   Multiple-Services-tbd  8.W     Enumerated| M  |  P  |    |  V  | Y  | 
   Indicator                                |    |     |    |     |    |

-	Section 8  amend as follows: 

FROM: 
8.16 Granted-Service-Unit AVP  
        
   Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and 
   contains the amount of units that the Diameter credit-control
   client can provide to the end user until the service must be 
   released or the new Credit-Control-Request must be sent. A client
   is not required to implement all of the unit types, and must treat
   unknown or unsupported unit types in the answer message as an
   incorrect CCA answer. In that case the client shall terminate
   credit control session and indicate in the Termination-Cause AVP
   reason DIAMETER_BAD_ANSWER. 
    
   The Service-Identifier and the Rating-Group AVPs are used to
   associate the granted units to a given service or rating group. 
   In case both the Service-Identifier and the Rating-Group AVPs are 
   included, the target of the granted units is always the service(s) 
   indicated by the value of the Service-Identifier AVP. 
   A value of 0 (zero) granted service unit associated to a Service- 
   entifier(s) or Rating-Group indicates that the corresponding
   traffic MUST be denied. Note that in case the credit-control 
   server want to disconnect the user and close the credit-control 
   session, it SHOULD use the appropriate error code in the Credit-
   Control-Answer message rather than including n times the Granted-
   Service-Units AVPs with the value of  0 (zero).  
   In contrast, a value of max type granted service unit (e.g. max 
   Unsigned 32 is FFFFFFFF) associated to a Service-Identifier(s) or 
   Rating-Group indicates that the corresponding traffic is free-of- 
   charge. With unit type money, the value of the Exponent AVP is set
   to 0 (zero) when free-of-charge is indicated. With unit type
   service specific, the value of the CC-Service-Specific-Units AVP
   is set to FFFFFFFF to indicate free-of-charge. 
    
   The Granted-Service-Unit AVP has the following ABNF grammar:   
             
         Granted-Service-Unit ::= < AVP Header: 431 > 
                                  [ Tariff-Time-Change ]   
                                  [ CC-Time ] 
                                  [ CC-Money ]   
                                  [ CC-Total-Octets ] 
                                  [ CC-Input-Octets ] 
                                  [ CC-Output-Octets ] 
                                  [ CC-Service-Specific-Units ] 
                                 *[ Service-Identifier ] 
                                  [ Rating-Group ] 
TO: 
8.16 Granted-Service-Unit AVP  
        
   Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and 
   contains the amount of units that the Diameter credit-control
   client can provide to the end user until the service must be
   released or the new Credit-Control-Request must be sent. A client
   is not required to implement all of the unit types, and must treat
   unknown or unsupported unit types in the answer message as an
   incorrect CCA answer. In that case the client MUST terminate the
   credit control session and indicate in the Termination-Cause AVP
   reason DIAMETER_BAD_ANSWER. 
        
   The Granted-Service-Unit AVP has the following ABNF grammar:   
             
         Granted-Service-Unit ::= < AVP Header: 431 > 
                                  [ Tariff-Time-Change ]   
                                  [ CC-Time ] 
                                  [ CC-Money ]   
                                  [ CC-Total-Octets ] 
                                  [ CC-Input-Octets ] 
                                  [ CC-Output-Octets ] 
                                  [ CC-Service-Specific-Units ] 

FROM:
8.21 Requested-Service-Unit AVP  
     
   The Requested-Service-Unit AVP (AVP Code 437) is of type Grouped
   and contains the amount of requested units specified by the
   Diameter credit-control client. A server is not required to
   implement all of the unit types, and must treat unknown or 
   unsupported unit types as invalid AVPs. 
    
  The Service-Identifier and the Rating-Group AVPs are used to
  request units for a given service(s) or rating group when the
  service element supports credit control for multiple services in
  one credit control session.  
   
  If both the AVPs are present, the Rating-Group AVP indicates the 
  rating group to which the service(s) specified by the Service-
  Identifier(s) belongs. If only the Rating-Group-Id AVP is present, 
  this is a credit authorization request for all the services that 
  belongs to the specified rating group. 
   
  A server not implementing the Service-Identifier AVP and the
  Rating-Group AVP must treat them as invalid AVPs. 
    
  The Requested-Service-Unit AVP has the following ABNF grammar:   
            
         Requested-Service-Unit ::= < AVP Header: 437 > 
                                    [ CC-Time ] 
                                    [ CC-Money ]    
                                    [ CC-Total-Octets ] 
                                    [ CC-Input-Octets ] 
                                    [ CC-Output-Octets ] 
                                    [ CC-Service-Specific-Units ]  
                                   *[ Service-Identifier ] 
                                    [ Rating-Group ] 

TO:
8.21 Requested-Service-Unit AVP  
     
   The Requested-Service-Unit AVP (AVP Code 437) is of type Grouped
   and contains the amount of requested units specified by the
   Diameter credit-control client. A server is not required to
   implement all of the unit types, and must treat unknown or
   unsupported unit types as invalid AVPs. 

   The Requested-Service-Unit AVP has the following ABNF grammar:   
            
         Requested-Service-Unit ::= < AVP Header: 437 > 
                                    [ CC-Time ] 
                                    [ CC-Money ]    
                                    [ CC-Total-Octets ] 
                                    [ CC-Input-Octets ] 
                                    [ CC-Output-Octets ] 
                                    [ CC-Service-Specific-Units ]  

FROM:
8.30 Used-Service-Unit AVP  
  
   The Used-Service-Unit AVP is of type Grouped AVP (AVP Code 446)
   and contains the amount of used units measured from the point when
   the service became active or, in case of interim interrogations
   are used during the session, from the point when the previous
   measurement ended. 
    
   The Service-Identifier and the Rating-Group AVPs are used to
   associate the used units to a given service or rating group. 
   When granted service units are associated to a service or rating 
   group, the credit control client MUST report the corresponding
   used service units. If the granted units are associated to a
   rating group, the units used by each of the Service-Identifier
   belonging to that rating group SHOULD be reported if this
   information is available to the credit control client. Therefore,
   multiple instances of the Used-Service-Unit AVP MAY be present in
   a request, each associated to the relevant Rating-Group-Id and to
   the identifier of the service (i.e. Service-Identifier) that
   consumed some of the granted units. 
    
   The Used-Service-Unit AVP has the following ABNF grammar: 
    
         Used-Service-Unit ::= < AVP Header: 446 > 
                               [ Tariff-Change-Usage ]   
                               [ CC-Time ] 
                               [ CC-Money ]   
                               [ CC-Total-Octets ]  
                               [ CC-Input-Octets ] 
                               [ CC-Output-Octets ] 
                               [ CC-Service-Specific-Units ] 
                              *[ Service-Identifier ] 
                               [ Rating-Group ] 

TO:
8.30 Used-Service-Unit AVP  
  
   The Used-Service-Unit AVP is of type Grouped AVP (AVP Code 446)
   and contains the amount of used units measured from the point when
   the service became active or, in case of interim interrogations
   are used during the session, from the point when the previous
   measurement ended. 
        
   The Used-Service-Unit AVP has the following ABNF grammar: 
    
         Used-Service-Unit ::= < AVP Header: 446 > 
                               [ Tariff-Change-Usage ]   
                               [ CC-Time ] 
                               [ CC-Money ]   
                               [ CC-Total-Octets ]  
                               [ CC-Input-Octets ] 
                               [ CC-Output-Octets ] 
                               [ CC-Service-Specific-Units ] 

FROM

8.42 Tariff-Change-Usage AVP

The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and defines whether units are used before, after or straddled tariff change when a tariff change has occurred during the reporting period. Omission of this AVP means that no tariff change has been occurred.

Tariff-Change-Usage can be one of the following.

 UNIT_BEFORE_TARIFF_CHANGE                    					0

The used units contains the amount of the units before tariff change, that is units measured from the point when the previous measurement ended to the point when tariff change occurred.

 UNIT_AFTER_TARIFF_CHANGE                     					1

The used units contains the amount of the units after tariff change has been occurred.

 UNIT_INDETERMINATE									2

The used units contains the amount of units that straddle the tariff change (e.g. the metering process reports to the credit-control client in blocks of n octets and one block straddled the tariff change).

TO

8.42 Tariff-Change-Usage AVP

The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and defines whether units are used before or, after a tariff change, or the units straddled tariff change when a tariff change has occurred during the reporting period. 
Omission of this AVP means that no tariff change has been occurred.

In addition, when present in answer messages as part of the Multiple-Services-Credit-Control AVP, this AVP defines whether units are allocated to be used before or after a tariff change event.
Omission of this AVP in answer messages when the Tariff-Time-Change AVP is present means that the single quota mechanism applies.

Tariff-Change-Usage can be one of the following:

 UNIT_BEFORE_TARIFF_CHANGE                    					0

When present in the Multiple-Services-Credit-Control AVP, this value indicates the amount of the units allocated for use before a tariff change occurs. 

When present in the Used-Service-Unit AVP, this value indicates the amount of resource units used before a tariff change had occurred.

 UNIT_AFTER_TARIFF_CHANGE                     					1

When present in the Multiple-Services-Credit-Control AVP, this value indicates the amount of the units allocated for use after a tariff change occurs. 

When present in the Used-Service-Unit AVP, this value indicates the amount of resource units used after tariff change had occurred.

 UNIT_INDETERMINATE									2

The used unit contains the amount of units that straddle the tariff change (e.g. the metering process reports to the credit-control client in blocks of n octets and one block straddled the tariff change). This value is to be used only in the Used-Service-Unit AVP.

ADD new section 8.x 
8.X G-S-U-Pool-Identifier AVP 
    The G-S-U-Pool-Identifier AVP (AVP code tbd) is of type
    Unsigned32 and identifies a 'credit pool' within the session. 

ADD new section 8.Y 
8.Y G-S-U-Pool-Reference AVP 
    The G-S-U-Pool-Reference AVP (AVP code tbd) is of type Grouped,
    it is used in the Credit-Control-Answer message and associates
    the Granted-Service-Units AVP within which it appears with a
    credit pool within the session. 

    The G-S-U-Pool-Identifier AVP specifies the credit pool from 
    which credit is drawn for this unit type.

    The CC-Unit-Type AVP specifies the type of units for which credit
    is pooled.  

    The Unit-Value AVP specifies the multiplier which converts
    between service units of type CC-Unit-Type and abstract service
    units within the credit pool (and hence to service units of any
    other service or rating group associated with the same pool).

    The G-S-U-Pool-Reference AVP has the following ABNF grammar:
 
         G-S-U-Pool-Reference    ::= < AVP Header: tbd > 
                                  { G-S-U-Pool-Identifier } 
                                  { CC-Unit-Type }
                                  { Unit-Value } 
ADD new section 8.z 
8.Z CC-Unit-Type AVP 
    The CC-Unit-Type AVP (AVP code tbd) is of type enumerated and
    specifies the type of units which are considered to be pooled
    into a credit pool.
    The following values are defined for the CC-Unit-Type AVP:

        TIME                    0 
        MONEY                   1 
        TOTAL-OCTETS            2 
        INPUT-OCTETS            3 
        OUTPUT-OCTETS           4 
        SERVICE-SPECIFIC-UNITS  5 

ADD new section 8.V 
8.V Multiple-Services-Credit-Control AVP  
        
   Multiple-Services-Credit-Control AVP (AVP Code tbd) is of type
   Grouped and contains the AVPs related to the independent credit
   control of multiple services feature. Note that each instance of
   this AVP carries units related to one or more services or related
   to a single rating-group.
    
   The Service-Identifier and the Rating-Group AVPs are used to
   associate the granted units to a given service or rating group. 
   In case both the Service-Identifier and the Rating-Group AVPs are 
   included, the target of the service units is always the service(s) 
   indicated by the value of the Service-Identifier AVP(s). If only
   the Rating-Group-Id AVP is present, the Multiple-Services-Credit-
   Control AVP relates to all the services that belongs to the
   specified rating group. 

   The G-S-U-Pool-Reference AVP allows the server to specify a G-S-U-
   Pool-Identifier identifying a credit pool within which the units
   of the specified type are considered to be pooled. If a G-S-U-
   Pool-Reference AVP is present then actual service units of the
   specified type MUST also be present. For example, if the G-S-U-
   Pool-Reference AVP specifies Unit-Type TIME, then the CC-Time AVP
   MUST be present.
 
   The Tariff-Change-Usage AVP SHOULD be included in a Credit-Control-
   Answer command when the Tariff-Time-Change AVP is present. It 
   instructs the client when the resources in the Granted-Service-Unit 
   AVP should be used. When both the Tariff-Time-Change and Tariff-
   Change-Usage AVPs are present, the server MUST include two separate 
   instances of the Multiple-Services-Credit-Control AVP with the 
   Granted-Service-Unit AVP associated to the same Service-Identifier 
   and/or Rating-Group and to the same pool identifier (but with 
   different multipliers).
   Note that these two quotas are grouped in the same pool, thus the 
   credit pooling mechanism as defined in section 5.1.1 applies.

   A server not implementing the independent credit control of
   multiple services functionality MUST treat the Multiple-Services-
   Credit-Control AVP as invalid AVP. 
    
   The Multiple-Services-Control AVP has the following ABNF grammar:   
             
    Multiple-Services-Credit-Control ::= < AVP Header: tbd > 
                                         [ Granted-Service-Unit ]
                                         [ Tariff-Change-Usage ]   
                                         [ Requested-Service-Units ] 
                                        *[ Used-Service-Units ] 
                                        *[ Service-Identifier ] 
                                         [ Rating-Group ] 
                                        *[ G-S-U-Pool-Reference ] 
                                         [ Validity-Time ] 
                                         [ Result-Code ] 
                                         [ Final-Unit-Indication ] 

ADD new section 8.W 
8.W Multiple-Services-Indicator AVP 
    
   The Multiple-Services-Indicator AVP (AVP Code tbd) is of type
   Enumerated and indicates whether the Diameter Credit-control
   client is capable of handling multiple services independently 
   within a (sub-)session. The absence of this AVP means that
   independent credit control of multiple services is not supported.

   A server not implementing the independent credit control of 
   multiple services MUST treat the Multiple-Services-Indicator AVP
   as invalid AVP. 

   The following values are defined for the Multiple-Services-
   Indicator AVP: 
    
         MULTIPLE_SERVICES_NOT_SUPPORTED                 0 
           Client does not support independent credit control of
           multiple servicess within a (sub-)session.
      
         MULTIPLE_SERVICES_SUPPORTED                     1 
           Client supports independent credit control of multiple
           services within a (sub-)session.

- section 10. AVP Occurrence Table 
ADD a new section: 10.1 Re-Auth-Request AVP Table

This section defines AVPs that are specific to Diameter Credit 
Control Application and MAY be included in the Diameter 
Re-Auth-Request (RAR) message [DIAMBASE]. 
    
Re-Auth-Request command MAY include the following additional AVPs:

                              +---------------+  
                              | Command Code  | 
                              |-------+-------+  
Attribute Name                |  RAR  |  RAA  |  
------------------------------+-------+-------+  
CC-Sub-Session-Id             |  0-1  |  0-1  |  
G-S-U-Pool-Identifier         |  0-1  |  0-1  |
Service-Identifier            |  0-1  |  0-1  |
Rating-Group                  |  0-1  |  0-1  |
------------------------------+-------+-------+

---

From: <[email-masked]>
Date: Fri, 13 Feb 2004 09:42:03 +0200

Hi all,

Assigned issue 19.  Issues 16, 17, 18 are marked as rejected
and replaced by issue 19.

John
> 
> as agreed in 
> http://www.merit.edu/mail.archives/aaa-wg/msg00176.html and 
> http://www.merit.edu/mail.archives/aaa-wg/msg00182.html we 
> have beed working on an updated proposal to issues 16 and 17.
> 
> The outcome is a new issue to replace issues 16 and 17 that 
> define the independent credit control of multiple services in 
> a (sub-)session feature. There will be a following mail with 
> a companion issue to replace the Flow X of draft 02 according 
> the agreed mechanism.
> 
> Finally, it was agred in 
> http://www.merit.edu/mail.archives/aaa-wg/msg00207.html that 
> also the tariff time change issue (issue 18) can be solved as 
> part of the independent credit control of multiple services feature.
> 
> The Diameter Credit Control Application supports the 
> server-initiated re-authorization. The credit control server 
> MAY optionally initiate the credit re-authorization by 
> issuing a Re-Auth-Request (RAR) as defined in the Diameter 
> base protocol [DIAMBASE]. The Auth-Application-Id in the RAR 
> message is set to 4 to indicate the Diameter Credit Control 
> Application and the Re-Auth-Request-Type is set to AUTHORIZE_ONLY.
> 
> If a credit re-authorization is not already ongoing (i.e. the 
> credit control session is in OPEN state), a credit control 
> client that receives such a RAR message with Session-Id equal 
> to a currently active credit control session acknowledges the 
> request by sending the Re-Auth-Answer (RAA) message and MUST 
> initiate the credit re-authorization towards the server by 
> sending a Credit-Control-Request message with the 
> CC-Request-Type AVP set to the value UPDATE_REQUEST. The 
> Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in 
> the RAA message to indicate an additional message (i.e. 
> CCR[Update]) is required to complete the procedure. If a 
> quota was allocated to the session, the credit control client 
> MUST report the used quota in the Credit-Control-Request. 
> Note that the end user does not need to be prompted for the 
> credit re-authorization, since the credit re-authorization is 
> transparent to the user (i.e it takes place exclusively 
> between the credit control client and the credit control server).
> 
> If credit re-authorization is ongoing at the time when the 
> RAR message is received (i.e. RAR-CCR collision), the credit 
> control client successfully acknowledges the request but it 
> does not initiate a new credit re-authorization. The 
> Result-Code 2001 (DIAMETER_SUCCESS) SHOULD be used in the RAA 
> message to indicate a credit re-authorization procedure is 
> already ongoing (i.e. the client was in PendingU state when 
> the RAR was received). The credit control server SHOULD 
> process the Credit-Control-Request as if it was received in 
> answer to the server initiated credit re-authorization, and 
> should consider the server initiated credit re-authorization 
> process successful upon reception of the Re-Auth-Answer message.
> 
> If several credit control sub-sessions are in use, a credit 
> control client receiving the RAR command for a given session 
> will trigger credit re-authorization for all the sub-session 
> separately.
> 
> TO
> 
> The Diameter Credit Control Application supports the 
> server-initiated re-authorization. The credit control server 
> MAY optionally initiate the credit re-authorization by 
> issuing a Re-Auth-Request (RAR) as defined in the Diameter 
> base protocol [DIAMBASE]. The Auth- Application-Id in the RAR 
> message is set to 4 to indicate the Diameter Credit Control 
> Application and the Re-Auth-Request-Type is set to AUTHORIZE_ONLY.
> 
> Where multiple services in a user's session are supported as 
> defined in section 5.1.1, the server MAY request credit 
> re-authorization at: (sub-)session level, credit pool level 
> granularity, service-identifier level granularity or 
> rating-group granularity. To request credit re-authorization 
> at credit pool granularity the server includes in the RAR 
> message the G-S-U-Pool-Identifier AVP indicating the affected pool. 
> To request credit re-authorization at service or rating-group 
> granularity the server includes in the RAR message the 
> Service-Identifier AVP or the Rating-Group AVP respectively. 
> To request credit re-authorization for all the ongoing 
> services within the (sub-)session the server does not include 
> any of the above mentione AVPs in the RAR message.
> 
> If a credit re-authorization is not already ongoing (i.e. the 
> credit control session is in OPEN state), a credit control 
> client that receives a RAR message with Session-Id equal to a 
> currently active credit control session acknowledges the 
> request by sending the Re-Auth-Answer (RAA) message and MUST 
> initiate the credit re- authorization towards the server by 
> sending a Credit-Control-Request message with the 
> CC-Request-Type AVP set to the value UPDATE_REQUEST. The 
> Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in 
> the RAA message to indicate an additional message (i.e. 
> CCR[Update]) is required to complete the procedure. If a 
> quota was allocated to the session, the credit control client 
> MUST report the used quota in the Credit-Control-Request. 
> Note that the end user does not need to be prompted for the 
> credit re-authorization, since the credit re- authorization 
> is transparent to the user (i.e it takes place exclusively 
> between the credit control client and the credit control server).
> 
> Where multiple services in a user's session are supported, 
> the procedure of the above paragraph will be executed at the 
> granularity as requested by the server in the RAR message.
> 
> If credit re-authorization is ongoing at the time when the 
> RAR message is received (i.e. RAR-CCR collision), the credit 
> control client successfully acknowledges the request but it 
> does not initiate a new credit re-authorization. The 
> Result-Code 2001 (DIAMETER_SUCCESS) SHOULD be used in the RAA 
> message to indicate a credit re- authorization procedure is 
> already ongoing (i.e. the client was in PendingU state when 
> the RAR was received). The credit control server SHOULD 
> process the Credit-Control-Request as if it was received in 
> answer to the server initiated credit re-authorization, and 
> should consider the server initiated credit re-authorization 
> process successful upon reception of the Re-Auth-Answer message.
> Where multiple services in a user's session are supported, it 
> may happen that the server requests credit re-authorization 
> for a credit pool (or for the (sub-)session) and a credit 
> re-authorization is already ongoing for some of the services 
> or rating-groups. In this case the client acknowledges the 
> server request with a RAA message and MUST send a new 
> Credit-Control-Request message to perform re-authorization 
> for the remaining services/rating-groups of the pool. The 
> Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in 
> the RAA message to indicate an additional message (i.e. 
> CCR[Update]) is required to complete the procedure. The 
> server processes the received requests and returns an 
> appropriate answer to both of the requests.
>    
> The above defined procedures are enabled for each of the 
> possibly active Diameter credit-control sub-sessions. The 
> server MAY request re-authorization for an active sub-session 
> by including the CC-Sub-Session-Id AVP in the RAR message in 
> addition to the Session-Id AVP.
> 
> This section defines the graceful service termination 
> optional feature that MAY be supported by the credit control 
> server. Credit control client implementations MUST support 
> the Final-Unit-Indication with at least the tear down of the 
> ongoing service session upon the subscriber has consumed all 
> the final granted units.
> 
> TO
> 
> This section defines the graceful service termination 
> optional feature that MAY be supported by the credit control 
> server. Credit control client implementations MUST support 
> the Final-Unit-Indication with at least the tear down of the 
> ongoing service session upon the subscriber has consumed all 
> the final granted units.
> Where independent credit control of multiple services in a 
> single credit control (sub-)session is supported, it is 
> possible to use the graceful service termination for each of 
> the services/rating-groups independently.
> 
>       Identifier                            |    |     |    | 
>     |    | 
>      Reference                              |    |     |    | 
>     |    | 
>    Indicator                                |    |     |    | 
>     |    |
> The Tariff-Change-Usage AVP (AVP code 452) is of type 
> Enumerated and defines whether units are used before, after 
> or straddled tariff change when a tariff change has occurred 
> during the reporting period. Omission of this AVP means that 
> no tariff change has been occurred.
> 
> The used units contains the amount of the units before tariff 
> change, that is units measured from the point when the 
> previous measurement ended to the point when tariff change occurred.
> 
>  UNIT_AFTER_TARIFF_CHANGE                     		
> 			1
> 
>  UNIT_INDETERMINATE						
> 			2
> The used units contains the amount of units that straddle the 
> tariff change (e.g. the metering process reports to the 
> credit-control client in blocks of n octets and one block 
> straddled the tariff change).
> 
> TO
> 
> The Tariff-Change-Usage AVP (AVP code 452) is of type 
> Enumerated and defines whether units are used before or, 
> after a tariff change, or the units straddled tariff change 
> when a tariff change has occurred during the reporting period. 
> In addition, when present in answer messages as part of the 
> Multiple-Services-Credit-Control AVP, this AVP defines 
> whether units are allocated to be used before or after a 
> tariff change event.
> Omission of this AVP in answer messages when the 
> Tariff-Time-Change AVP is present means that the single quota 
> mechanism applies.
> 
> When present in the Multiple-Services-Credit-Control AVP, 
> this value indicates the amount of the units allocated for 
> use before a tariff change occurs. 
> 
> When present in the Used-Service-Unit AVP, this value 
> indicates the amount of resource units used before a tariff 
> change had occurred.
> 
>  UNIT_AFTER_TARIFF_CHANGE                     		
> 			1
> 
> When present in the Multiple-Services-Credit-Control AVP, 
> this value indicates the amount of the units allocated for 
> use after a tariff change occurs. 
> 
> When present in the Used-Service-Unit AVP, this value 
> indicates the amount of resource units used after tariff 
> change had occurred.
> 
>  UNIT_INDETERMINATE						
> 			2
> 
> The used unit contains the amount of units that straddle the 
> tariff change (e.g. the metering process reports to the 
> credit-control client in blocks of n octets and one block 
> straddled the tariff change). This value is to be used only 
> in the Used-Service-Unit AVP.
> 
> ADD new section 8.x

---

From: <[email-masked]>
Date: Fri, 13 Feb 2004 19:10:05 +0200

Hi John,
 
>If I understand the new mechanism correctly, there is a monetary reservation for each quota that is allocated as part of the 
>session, and there is a conversion factor that could be used by the client to transfer between quotas of sub-sessions. 
 
>Would this lead to more funds being reserved on the server?  Certainly, I've been focusing on credit fragmentation across 
>multiple types of clients rather than on a single client and anything which leads to a higher monetary value being reserved 
>for a session on one client would make credit fragmentation worse.  If my understanding is correct, that would be my 
>concern. 
 
There is a monetary reservation for each quota, but this is on demand only when the service is really requested by the user. The server most likely consider always one single reservation per credit pool, and updates this reservation according to the needs. The reservation is then reflected to the client by means of the pool-id and the multiplier. This means that the smallest possible chunk of credit is added in real time as needed.
 
Note that in principle the report occur only when the whole reserved amount (100%) has been consumed by the end user as before. 
 
With the previous mechanism it was not possible to update the *reservation* to the client at all, as a consequence the server did need to reserve a bigger chunk of credit as soon as a request for a non-authorized rating-group was received just in case the end-user issued one or more new service requests for that rating-group. But without certainty that any service request would have come!
 
So, the new mechanism ensure the smallest possible money allocation on a per real need bases, hence minimizing the credit fragmentation effect that in practice was worse with the previous mechanism. 
 
This has been actually one of the rational behind the new mechanism, I hope this explanation addresses  your concern.
 
Regards
Marco