Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in mul tiple services feature

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Mon, 1 Mar 2004 13:17:22 +0100

assigned issue 23.

/ harri

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: 1. maaliskuuta 2004 14:13
> To: [email-masked]
> Subject: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in
> multiple services feature
> 
> 
> Description of issue: clarification of R-S-U AVP usage in 
> multiple services feature
> Submitter name:  Marco Stura
> Date first submitted: 1.03.2004 
> Reference: 
> Document: draft-ietf-aaa-diameter-cc-03.txt 
> Comment type: T 
> Priority: 1 
> Section: 5.2, 5.3, 8.16 and Flow X 
> 
> Rationale/Explanation of issues: 
> 
> When independent credit control of multiple services within a 
> (sub-)session is used, the Requested-Service-Unit AVP is used 
> by the client to indicate to the server that quota is 
> requested for the service/rating-group associated to it.
> 
> The Requested-service-Unit AVP is to be present in all the 
> intermediate interrogations sent for the service/rating-group 
> if quota is still requested. If quota is not requested 
> anymore, for instance the client determined that the service 
> was terminated by the user, this is indicated by the absence 
> of the R-S-U AVP in the request command.
> 
> The usage of the R-S-U AVP is not clearly specified in draft 
> 03, thus different interpretation of its usage may cause 
> potential interoperability problems between client and 
> servers of different vendors. For instance, a client may send 
> an intermediate interrogation  without R-S-U AVP even though 
> it actually requests a new quota. The server may not returns 
> quota because it expects the R-S-U AVP to be present in the 
> request when quota is wanted.
> 
> Requested change:
> 
> -Section 5.2 second paragraph
> 
> FROM
> 
> 
>    If the Diameter credit-control client knows the cost of 
> the service 
>    event (e.g. a content server delivering ringing tones may 
> know their 
>    cost) the monetary amount to be charged is included in the 
> Requested-
>    Service-Unit AVP. If the Diameter credit-control client 
> does not know 
>    the cost of the service event, the Requested-Service-Unit AVP MAY 
>    contain the number of requested service events. The 
> Service-Identifier 
>    AVP, in case of multiple services the Service-Identifier 
> AVP or the 
>    Rating-Group AVP within the Multiple-Services-Credit-Control AVP, 
>    always indicates the concerned service.  Additional service event 
>    information to be rated MAY be sent as service specific 
> AVPs or MAY be 
>    sent within the Service-Parameter-Info AVP at command level.
> 
> TO
> 
>    If the Diameter credit-control client knows the cost of 
> the service 
>    event (e.g. a content server delivering ringing tones may 
> know their 
>    cost) the monetary amount to be charged is included in the 
> Requested-
>    Service-Unit AVP. If the Diameter credit-control client 
> does not know 
>    the cost of the service event, the Requested-Service-Unit AVP MAY 
>    contain the number of requested service events. Where the Multiple-
>    Services-Credit-Control AVP is used, it MUST contain the Requested-
>    Service-Unit AVP to indicate that quota for the associated service/
>    rating-group is requested. The Service-Identifier AVP, in case of 
>    multiple services the Service-Identifier AVP or the 
> Rating-Group AVP 
>    within the Multiple-Services-Credit-Control AVP, always 
> indicates the 
>    concerned service.  Additional service event information 
> to be rated 
>    MAY be sent as service specific AVPs or MAY be sent within the 
>    Service-Parameter-Info AVP at command level.
> 
> -Section 5.3 fifth paragraph
> 
> FROM
> 
> 
>    The Requested-Service-Unit AVP MAY contain the new amount 
> of requested 
>    service units. The Used-Service-Unit AVP contains the 
> amount of used 
>    service 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 same unit 
>    types that are used in the previous message MUST be used. 
> If several 
>    unit types were included in the previous answer message the used 
>    service units for each unit type MUST be reported.  
> 
> TO
> 
> 
>    The Requested-Service-Unit AVP MAY contain the new amount 
> of requested 
>    service units. Where the Multiple-Services-Credit-Control 
> AVP is used, 
>    it MUST contain the Requested-Service-Unit AVP if new 
> quota for the 
>    associated service/rating-group is requested. The 
> Used-Service-Unit AVP 
>    contains the amount of used service 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 same unit types that are used in the previous 
> message MUST 
>    be used. If several unit types were included in the 
> previous answer 
>    message the used service units for each unit type MUST be reported.
>  
> -Section 8.16
> 
> ADD after third paragrapf
> 
>    The Requested-Service-Unit AVP MAY contain the amount of requested 
>    service units or the requested monetary value. It MUST be 
> present in
>    the initial interrogation and within the intermediate 
> interrogations
>    where new quota is requested. If the credit-control client does not
>    include the Requested-Service-Unit AVP in a request command, for
>    instance because it has determined that the end-user terminated the
>    service, the server MUST debit the used amount from the 
> user's account
>    but MUST NOT return a new quota in the corresponding answer.
> 
> - Flow X add the R-S-U AVP in message 11 and 13 as follow.
> 
>      | +--------------+  |                                         |  
>      | |Validity time |  |(11)CCR(update,                          |  
>      | |expires for   |  |        Multiple-Services-CC (           |  
>      | |Service-Id    |  |        Requested-Units(),               |
>      | | access       |  |        Used-Units(In-Octets,Out-Octets),| 
>      | +--------------+  |        Service-Id access))              | 
>      |                   
> |---------------------------------------->|   
>      |                   |(12)CCA(Multiple-Services-CC (           | 
>      |                   |        Granted-Units(Total-Octets),     |  
>      |                   |        Service-Id access,               |  
>      |                   |        Validity-time,                   | 
>      |                   |        G-S-U-Pool-Reference(Pool-Id 1,  |  
>      |                   |          Multiplier 10)))               | 
>      |                   |<----------------------------------------|  
>      :                   :                                         :  
>      :                   :                                         :  
>      | +--------------+  |                                         |  
>      | |Total Quota   |  |(13)CCR(update,                          |  
>      | |elapses for   |  |       Multiple-Services-CC (            |  
>      | |pool 2:       |  |        Requested-Units(),               |
>      | |service 4 not |  |        Used-Units(In-Octets,Out-Octets),| 
>      | |allowed,      |  |        Service-Id 3, Rating-group 2),   | 
>      | |service 3 cont|  |       Multiple-Services-CC (            |  
>      | +--------------+  |        Used-Units(In-Octets,Out-Octets),| 
>      |                   |        Service-Id 4, Rating-group 3))   | 
>      |                   
> |---------------------------------------->|   
>      |                   |(14)CCA(Multiple-Services-CC (           | 
>      |                   |        Result-Code 4011,                |  
>      |                   |        Service-Id 3))                   | 
>      |                   |<----------------------------------------|  
> 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: "Christopher Richards" <[email-masked]>
Date: Mon, 1 Mar 2004 10:22:52 -0600

Hi All,

Does this imply that the Rating-Group AVP needs to be part of the R-S-U AVP
in section 8.18?
I think Rating-Group AVP needs to be added to R-S-U AVP.

A client requests a resource allocation but does not request a certain
amount (or unit) of resource (This is the usual case in the NAS
environment). It leaves it up to the server to supply the amount and the
unit type.

Chris.

-----Original Message-----
From: Harri Hakala (TU/LMF) [mailto:[email-masked]]
Sent: Monday, March 01, 2004 6:17 AM
To: [email-masked]'; [email-masked]
Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in
mul tiple services feature

assigned issue 23.

/ harri

> - Flow X add the R-S-U AVP in message 11 and 13 as follow.

This communication is confidential and intended solely for the addressee(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If
you believe this message has been sent to you in error, please notify the
sender by replying to this transmission and delete the message without
disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption,
interruption, unauthorized amendment, tampering and viruses, and we only
send and receive e-mails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any
consequences thereof.

---

From: <[email-masked]>
Date: Mon, 1 Mar 2004 18:34:15 +0200

Hi Chris,
 
>Does this imply that the Rating-Group AVP needs to be part of the R-S-U AVP in section 8.18? 
 
No, it doesn't imply this. The Rating-Group AVP is associate to the R-S-U in the M-S-C-C AVP.
 
M-S-C-C (R-S-U, Rating-Group, Service-Id, U-S-U)
 
>A client requests a resource allocation but does not request a certain amount (or unit) of resource (This is the usual case in the NAS environment). It leaves it up to the >server to supply the amount and the unit type.
 
Yes, this is the usual case and it is achieved by an empty R-S-U AVP as also illustrated in Flow X by the notation R-S-U ( ). 
Note that all the AVPs in the R-S-U AVP structure are optional.
 
Regards
Marco

-----Original Message-----
From: ext Christopher Richards [mailto:[email-masked]]
Sent: 01 March, 2004 18:23
To: 'Harri Hakala (TU/LMF)'; Stura Marco (Nokia-NET/Helsinki); [email-masked]'
Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in mul tiple services feature

Hi All, 

Does this imply that the Rating-Group AVP needs to be part of the R-S-U AVP in section 8.18? 
I think Rating-Group AVP needs to be added to R-S-U AVP. 

A client requests a resource allocation but does not request a certain amount (or unit) of resource (This is the usual case in the NAS environment). It leaves it up to the server to supply the amount and the unit type.

Chris. 

-----Original Message----- 
From: Harri Hakala (TU/LMF) [ mailto:[email-masked]] 
Sent: Monday, March 01, 2004 6:17 AM 
To: [email-masked]'; [email-masked] 
Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in 

assigned issue 23. 

/ harri 

> [ mailto:[email-masked]]On Behalf Of 
> [email-masked]

---

From: "Christopher Richards" <[email-masked]>
Date: Mon, 1 Mar 2004 12:48:12 -0600

Thanks for the clarification Marco.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 01, 2004 10:34 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in mul
tiple services feature

Hi Chris,
 
in section 8.18? 
>I think Rating-Group AVP needs to be added to R-S-U AVP. 
 
No, it doesn't imply this. The Rating-Group AVP is associate to the R-S-U in
the M-S-C-C AVP.

amount (or unit) of resource (This is the usual case in the NAS
environment). It leaves it up to the >server to supply the amount and the
unit type.
 
Yes, this is the usual case and it is achieved by an empty R-S-U AVP as also
illustrated in Flow X by the notation R-S-U ( ). 
Note that all the AVPs in the R-S-U AVP structure are optional.
 
Regards
Marco

-----Original Message-----
From: ext Christopher Richards [mailto:[email-masked]]
Sent: 01 March, 2004 18:23
To: 'Harri Hakala (TU/LMF)'; Stura Marco (Nokia-NET/Helsinki);
[email-masked]'
Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in mul
tiple services feature

Hi All, 

Chris. 

-----Original Message----- 
From: Harri Hakala (TU/LMF) [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Monday, March 01, 2004 6:17 AM 
To: [email-masked]'; [email-masked] 
Subject: RE: [AAA-WG]: DCC Issue: clarification of R-S-U AVP usage in 
mul tiple services feature 

assigned issue 23. 

/ harri 

> [ mailto:[email-masked] <mailto:[email-masked]> ]On Behalf
Of