Subject: [Dime] RFC 4006 bis

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Mon, 13 Jun 2016 20:39:36 +0000

All,

We have submitted an RFC 4006 bis (draft-bertz-dime-rfc4006bis-00) for your consideration.  At this time the document is a conversion from the text format to the xml format with the following changes (also noted in Appendix C of the document):

-          Updated references to 6733 from 3588

-          Updated references to 7155 from 4005

-          Updated references to "TLS/TCP, DTLS/SCTP or IPSec" from "IPSec or TLS"

-        Update AVP per Errata ID 3329

Per discussion regarding the LS we will need to discuss a few other matters but wanted to get the document out to the group today to begin the discussion.

Enclosed is a diff file between RFC 4006 and the I-D.  Most of the file reflects the page changes between the text and generated text from the XML format.

Please use the mailing list for any noting errors, omissions and requests.

Thank you

I-D Authors (Dave, Yuval & myself)

Links
I-D: https://datatracker.ietf.org/doc/draft-bertz-dime-rfc4006bis/
Git Repo: https://github.com/lbertz02/rfc4006bis

________________________________
Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off<http://sprint.com/50off> for details.

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Mon, 13 Jun 2016 20:41:43 +0000

Resending with the hope the attachment is not removed.

From: Bertz, Lyle T [CTO]
Sent: Monday, June 13, 2016 3:40 PM
To: [email-masked]
Cc: [email-masked]; 'Dave Dolson' <[email-masked]>; 'Yuval Lifshitz' <[email-masked]>
Subject: RFC 4006 bis

All,

Thank you

Links

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
5,9c5,12
< 
< 
< Network Working Group                                          H. Hakala
< Request for Comments: 4006                                    L. Mattila
< Category: Standards Track                                       Ericsson
---
> Network Working Group                                      L. Bertz, Ed.
> Internet-Draft                                                    Sprint
> Intended status: Standards Track                          D. Dolson, Ed.
> Expires: December 15, 2016                              Y. Lifshitz, Ed.
>                                                                 Sandvine
>                                                                H. Hakala
>                                                               L. Mattila
>                                                       Oy L M Ericsson Ab
11a15
>                                                           Nokia Networks
13,14c17,22
<                                                                    Nokia
<                                                              August 2005
---
>                                                    Nokia Research Center
>                                                            June 13, 2016
> 
> 
>                   Diameter Credit-Control Application
>                      draft-bertz-dime-rfc4006bis-00
15a24
> Abstract
17c26,29
<                  Diameter Credit-Control Application
---
>    This document specifies a Diameter application that can be used to
>    implement real-time credit-control for a variety of end user services
>    such as network access, Session Initiation Protocol (SIP) services,
>    messaging services, and download services.
21,25c33,46
<    This document specifies an Internet standards track protocol for the
<    Internet community, and requests discussion and suggestions for
<    improvements.  Please refer to the current edition of the "Internet
<    Official Protocol Standards" (STD 1) for the standardization state
<    and status of this protocol.  Distribution of this memo is unlimited.
---
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current Internet-
>    Drafts is at http://datatracker.ietf.org/drafts/current/.
> 
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
> 
>    This Internet-Draft will expire on December 15, 2016.
29c50,51
<    Copyright (C) The Internet Society (2005).
---
>    Copyright (c) 2016 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
31d52
< Abstract
33,36c54,81
<    This document specifies a Diameter application that can be used to
<    implement real-time credit-control for a variety of end user services
<    such as network access, Session Initiation Protocol (SIP) services,
<    messaging services, and download services.
---
> 
> 
> Bertz, et al.           Expires December 15, 2016               [Page 1]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>    (http://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>    carefully, as they describe your rights and restrictions with respect
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4.e of
>    the Trust Legal Provisions and are provided without warranty as
>    described in the Simplified BSD License.
> 
>    This document may contain material from IETF Documents or IETF
>    Contributions published or made publicly available before November
>    10, 2008.  The person(s) controlling the copyright in some of this
>    material may not have granted the IETF Trust the right to allow
>    modifications of such material outside the IETF Standards Process.
>    Without obtaining an adequate license from the person(s) controlling
>    the copyright in such materials, this document may not be modified
>    outside the IETF Standards Process, and derivative works of it may
>    not be created outside the IETF Standards Process, except to format
>    it for publication as an RFC or to translate it into languages other
>    than English.
40,185c85,244
<    1.  Introduction.................................................   4
<        1.1.   Requirements Language.................................   5
<        1.2.   Terminology...........................................   5
<        1.3.   Advertising Application Support.......................   7
<    2.  Architecture Models..........................................   7
<    3.  Credit-Control Messages......................................   9
<        3.1.   Credit-Control-Request (CCR) Command..................   9
<        3.2.   Credit-Control-Answer (CCA) Command...................  11
<    4.  Credit-Control Application Overview..........................  11
<        4.1.   Service-Specific Rating Input and Interoperability....  13
<    5.  Session Based Credit-Control.................................  15
<        5.1.   General Principles....................................  15
<        5.2.   First Interrogation...................................  21
<        5.3.   Intermediate Interrogation............................  27
<        5.4.   Final Interrogation...................................  29
< 
< 
< 
< Hakala, et al.              Standards Track                     [Page 1]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
<        5.5.   Server-Initiated Credit Re-Authorization..............  30
<        5.6.   Graceful Service Termination..........................  32
<        5.7.   Failure Procedures....................................  38
<    6.  One Time Event...............................................  41
<        6.1.   Service Price Enquiry.................................  42
<        6.2.   Balance Check.........................................  42
<        6.3.   Direct Debiting.......................................  43
<        6.4.   Refund................................................  44
<        6.5.   Failure Procedure.....................................  44
<    7.  Credit-Control Application State Machine.....................  46
<    8.  Credit-Control AVPs..........................................  55
<        8.1.   CC-Correlation-Id AVP.................................  58
<        8.2.   CC-Request-Number AVP.................................  58
<        8.3.   CC-Request-Type AVP...................................  58
<        8.4.   CC-Session-Failover AVP...............................  59
<        8.5.   CC-Sub-Session-Id AVP.................................  59
<        8.6.   Check-Balance-Result AVP..............................  60
<        8.7.   Cost-Information AVP..................................  60
<        8.8.   Unit-Value AVP........................................  61
<        8.9.   Exponent AVP..........................................  61
<        8.10.  Value-Digits AVP......................................  61
<        8.11.  Currency-Code AVP.....................................  62
<        8.12.  Cost-Unit AVP.........................................  62
<        8.13.  Credit-Control AVP....................................  62
<        8.14.  Credit-Control-Failure-Handling AVP...................  62
<        8.15.  Direct-Debiting-Failure-Handling AVP..................  63
<        8.16.  Multiple-Services-Credit-Control AVP..................  64
<        8.17.  Granted-Service-Unit AVP..............................  65
<        8.18.  Requested-Service-Unit AVP............................  66
<        8.19.  Used-Service-Unit AVP.................................  66
<        8.20.  Tariff-Time-Change AVP................................  67
<        8.21.  CC-Time AVP...........................................  67
<        8.22.  CC-Money AVP..........................................  67
<        8.23.  CC-Total-Octets AVP...................................  68
<        8.24.  CC-Input-Octets AVP...................................  68
<        8.25.  CC-Output-Octets AVP..................................  68
<        8.26.  CC-Service-Specific-Units AVP.........................  68
<        8.27.  Tariff-Change-Usage AVP...............................  68
<        8.28.  Service-Identifier AVP................................  69
<        8.29.  Rating-Group AVP......................................  69
<        8.30.  G-S-U-Pool-Reference AVP..............................  69
<        8.31.  G-S-U-Pool-Identifier AVP.............................  70
<        8.32.  CC-Unit-Type AVP......................................  70
<        8.33.  Validity-Time AVP.....................................  70
<        8.34.  Final-Unit-Indication AVP.............................  71
<        8.35.  Final-Unit-Action AVP.................................  72
<        8.36.  Restriction-Filter-Rule AVP...........................  72
<        8.37.  Redirect-Server AVP...................................  73
< 
< 
< 
< Hakala, et al.              Standards Track                     [Page 2]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
<        8.38.  Redirect-Address-Type AVP.............................  73
<        8.39.  Redirect-Server-Address AVP...........................  74
<        8.40.  Multiple-Services-Indicator AVP.......................  74
<        8.41.  Requested-Action AVP..................................  74
<        8.42.  Service-Context-Id AVP................................  75
<        8.43.  Service-Parameter-Info AVP............................  76
<        8.44.  Service-Parameter-Type AVP............................  76
<        8.45.  Service-Parameter-Value AVP...........................  77
<        8.46.  Subscription-Id AVP...................................  77
<        8.47.  Subscription-Id-Type AVP..............................  77
<        8.48.  Subscription-Id-Data AVP..............................  78
<        8.49.  User-Equipment-Info AVP...............................  78
<        8.50.  User-Equipment-Info-Type AVP..........................  78
<        8.50.  User-Equipment-Info-Value AVP.........................  79
<    9.  Result Code AVP Values.......................................  79
<        9.1.   Transient Failures....................................  79
<        9.2.   Permanent Failures....................................  80
<    10. AVP Occurrence Table.........................................  80
<        10.1.  Credit-Control AVP Table..............................  81
<        10.2.  Re-Auth-Request/Answer AVP Table......................  82
<    11. RADIUS/Diameter Credit-Control Interworking Model............  82
<    12. IANA Considerations..........................................  85
<        12.1.  Application Identifier................................  86
<        12.2.  Command Codes.........................................  86
<        12.3.  AVP Codes.............................................  86
<        12.4.  Result-Code AVP Values................................  86
<        12.5.  CC-Request-Type AVP...................................  86
<        12.6.  CC-Session-Failover AVP...............................  86
<        12.7.  CC-Unit-Type AVP......................................  87
<        12.8.  Check-Balance-Result AVP..............................  87
<        12.9.  Credit-Control AVP....................................  87
<        12.10. Credit-Control-Failure-Handling AVP...................  87
<        12.11. Direct-Debiting-Failure-Handling AVP..................  87
<        12.12. Final-Unit-Action AVP.................................  87
<        12.13. Multiple-Services-Indicator AVP.......................  87
<        12.14. Redirect-Address-Type AVP.............................  88
<        12.15. Requested-Action AVP..................................  88
<        12.16. Subscription-Id-Type AVP..............................  88
<        12.17. Tariff-Change-Usage AVP...............................  88
<        12.18. User-Equipment-Info-Type AVP..........................  88
<    13. Credit-Control Application Related Parameters................  88
<    14. Security Considerations......................................  89
<        14.1.  Direct Connection with Redirects......................  90
<    15. References...................................................  91
<        15.1.  Normative References..................................  91
<        15.2.  Informative References................................  92
<    16. Acknowledgements.............................................  93
<    Appendix A Credit-Control Sequences..............................  94
< 
< 
< 
< Hakala, et al.              Standards Track                     [Page 3]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
<        A.1.   Flow I................................................  94
<        A.2.   Flow II...............................................  96
<        A.3.   Flow III..............................................  98
<        A.4.   Flow IV...............................................  99
<        A.5.   Flow V................................................ 100
<        A.6.   Flow VI............................................... 102
<        A.7.   Flow VII.............................................. 103
<        A.8.   Flow VIII............................................. 105
<        A.9.   Flow IX............................................... 107
<    Authors' Addresses............................................... 112
<    Full Copyright Statement......................................... 114
---
>    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
>      1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   6
>      1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
>      1.3.  Advertising Application Support . . . . . . . . . . . . .   7
>    2.  Architecture Models . . . . . . . . . . . . . . . . . . . . .   8
>    3.  Credit-Control Messages . . . . . . . . . . . . . . . . . . .   9
>      3.1.  Credit-Control-Request (CCR) Command  . . . . . . . . . .  10
>      3.2.  Credit-Control-Answer (CCA) Command . . . . . . . . . . .  11
>    4.  Credit-Control Application Overview . . . . . . . . . . . . .  12
>      4.1.  Service-Specific Rating Input and Interoperability  . . .  14
>        4.1.1.  Specifying Rating Input AVPs  . . . . . . . . . . . .  14
>        4.1.2.  Service-Specific Documentation  . . . . . . . . . . .  15
>        4.1.3.  Handling of Unsupported/Incorrect Rating Input  . . .  16
>        4.1.4.  RADIUS Vendor-Specific Rating Attributes  . . . . . .  16
>    5.  Session Based Credit-Control  . . . . . . . . . . . . . . . .  16
>      5.1.  General Principles  . . . . . . . . . . . . . . . . . . .  16
>        5.1.1.  Basic Tariff-Time Change Support  . . . . . . . . . .  17
>        5.1.2.  Credit-Control for Multiple Services within a
>                (sub-)Session . . . . . . . . . . . . . . . . . . . .  18
>      5.2.  First Interrogation . . . . . . . . . . . . . . . . . . .  22
>        5.2.1.  First Interrogation after Authorization and
>                Authentication  . . . . . . . . . . . . . . . . . . .  24
>        5.2.2.  Authorization Messages for First Interrogation  . . .  25
>      5.3.  Intermediate Interrogation  . . . . . . . . . . . . . . .  28
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016               [Page 2]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
>      5.4.  Final Interrogation . . . . . . . . . . . . . . . . . . .  30
>      5.5.  Server-Initiated Credit Re-Authorization  . . . . . . . .  31
>      5.6.  Graceful Service Termination  . . . . . . . . . . . . . .  33
>        5.6.1.  Terminate Action  . . . . . . . . . . . . . . . . . .  35
>        5.6.2.  Redirect Action . . . . . . . . . . . . . . . . . . .  35
>        5.6.3.  Restrict Access Action  . . . . . . . . . . . . . . .  37
>        5.6.4.  Usage of the Server-Initiated Credit Re-Authorization  38
>      5.7.  Failure Procedures  . . . . . . . . . . . . . . . . . . .  39
>    6.  One Time Event  . . . . . . . . . . . . . . . . . . . . . . .  41
>      6.1.  Service Price Enquiry . . . . . . . . . . . . . . . . . .  42
>      6.2.  Balance Check . . . . . . . . . . . . . . . . . . . . . .  43
>      6.3.  Direct Debiting . . . . . . . . . . . . . . . . . . . . .  43
>      6.4.  Refund  . . . . . . . . . . . . . . . . . . . . . . . . .  44
>      6.5.  Failure Procedure . . . . . . . . . . . . . . . . . . . .  45
>    7.  Credit-Control Application State Machine  . . . . . . . . . .  47
>    8.  Credit-Control AVPs . . . . . . . . . . . . . . . . . . . . .  55
>      8.1.  CC-Correlation-Id AVP . . . . . . . . . . . . . . . . . .  58
>      8.2.  CC-Request-Number AVP . . . . . . . . . . . . . . . . . .  58
>      8.3.  CC-Request-Type AVP . . . . . . . . . . . . . . . . . . .  58
>      8.4.  CC-Session-Failover AVP . . . . . . . . . . . . . . . . .  59
>      8.5.  CC-Sub-Session-Id AVP . . . . . . . . . . . . . . . . . .  59
>      8.6.  Check-Balance-Result AVP  . . . . . . . . . . . . . . . .  60
>      8.7.  Cost-Information AVP  . . . . . . . . . . . . . . . . . .  60
>      8.8.  Unit-Value AVP  . . . . . . . . . . . . . . . . . . . . .  61
>      8.9.  Exponent AVP  . . . . . . . . . . . . . . . . . . . . . .  61
>      8.10. Value-Digits AVP  . . . . . . . . . . . . . . . . . . . .  61
>      8.11. Currency-Code AVP . . . . . . . . . . . . . . . . . . . .  61
>      8.12. Cost-Unit AVP . . . . . . . . . . . . . . . . . . . . . .  62
>      8.13. Credit-Control AVP  . . . . . . . . . . . . . . . . . . .  62
>      8.14. Credit-Control-Failure-Handling AVP . . . . . . . . . . .  62
>      8.15. Direct-Debiting-Failure-Handling AVP  . . . . . . . . . .  63
>      8.16. Multiple-Services-Credit-Control AVP  . . . . . . . . . .  64
>      8.17. Granted-Service-Unit AVP  . . . . . . . . . . . . . . . .  65
>      8.18. Requested-Service-Unit AVP  . . . . . . . . . . . . . . .  66
>      8.19. Used-Service-Unit AVP . . . . . . . . . . . . . . . . . .  66
>      8.20. Tariff-Time-Change AVP  . . . . . . . . . . . . . . . . .  67
>      8.21. CC-Time AVP . . . . . . . . . . . . . . . . . . . . . . .  67
>      8.22. CC-Money AVP  . . . . . . . . . . . . . . . . . . . . . .  67
>      8.23. CC-Total-Octets AVP . . . . . . . . . . . . . . . . . . .  68
>      8.24. CC-Input-Octets AVP . . . . . . . . . . . . . . . . . . .  68
>      8.25. CC-Output-Octets AVP  . . . . . . . . . . . . . . . . . .  68
>      8.26. CC-Service-Specific-Units AVP . . . . . . . . . . . . . .  68
>      8.27. Tariff-Change-Usage AVP . . . . . . . . . . . . . . . . .  68
>      8.28. Service-Identifier AVP  . . . . . . . . . . . . . . . . .  69
>      8.29. Rating-Group AVP  . . . . . . . . . . . . . . . . . . . .  69
>      8.30. G-S-U-Pool-Reference AVP  . . . . . . . . . . . . . . . .  69
>      8.31. G-S-U-Pool-Identifier AVP . . . . . . . . . . . . . . . .  70
>      8.32. CC-Unit-Type AVP  . . . . . . . . . . . . . . . . . . . .  70
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016               [Page 3]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
>      8.33. Validity-Time AVP . . . . . . . . . . . . . . . . . . . .  70
>      8.34. Final-Unit-Indication AVP . . . . . . . . . . . . . . . .  71
>      8.35. Final-Unit-Action AVP . . . . . . . . . . . . . . . . . .  72
>      8.36. Restriction-Filter-Rule AVP . . . . . . . . . . . . . . .  73
>      8.37. Redirect-Server AVP . . . . . . . . . . . . . . . . . . .  73
>      8.38. Redirect-Address-Type AVP . . . . . . . . . . . . . . . .  73
>      8.39. Redirect-Server-Address AVP . . . . . . . . . . . . . . .  74
>      8.40. Multiple-Services-Indicator AVP . . . . . . . . . . . . .  74
>      8.41. Requested-Action AVP  . . . . . . . . . . . . . . . . . .  74
>      8.42. Service-Context-Id AVP  . . . . . . . . . . . . . . . . .  75
>      8.43. Service-Parameter-Info AVP  . . . . . . . . . . . . . . .  76
>      8.44. Service-Parameter-Type AVP  . . . . . . . . . . . . . . .  76
>      8.45. Service-Parameter-Value AVP . . . . . . . . . . . . . . .  77
>      8.46. Subscription-Id AVP . . . . . . . . . . . . . . . . . . .  77
>      8.47. Subscription-Id-Type AVP  . . . . . . . . . . . . . . . .  77
>      8.48. Subscription-Id-Data AVP  . . . . . . . . . . . . . . . .  78
>      8.49. User-Equipment-Info AVP . . . . . . . . . . . . . . . . .  78
>      8.50. User-Equipment-Info-Type AVP  . . . . . . . . . . . . . .  78
>      8.51. User-Equipment-Info-Value AVP . . . . . . . . . . . . . .  79
>    9.  Result Code AVP Values  . . . . . . . . . . . . . . . . . . .  79
>      9.1.  Transient Failures  . . . . . . . . . . . . . . . . . . .  79
>      9.2.  Permanent Failures  . . . . . . . . . . . . . . . . . . .  80
>    10. AVP Occurrence Table  . . . . . . . . . . . . . . . . . . . .  80
>      10.1.  Credit-Control AVP Table . . . . . . . . . . . . . . . .  81
>      10.2.  Re-Auth-Request/Answer AVP Table . . . . . . . . . . . .  82
>    11. RADIUS/Diameter Credit-Control Interworking Model . . . . . .  82
>    12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  85
>      12.1.  Application Identifier . . . . . . . . . . . . . . . . .  86
>      12.2.  Command Codes  . . . . . . . . . . . . . . . . . . . . .  86
>      12.3.  AVP Codes  . . . . . . . . . . . . . . . . . . . . . . .  86
>      12.4.  Result-Code AVP Values . . . . . . . . . . . . . . . . .  86
>      12.5.  CC-Request-Type AVP  . . . . . . . . . . . . . . . . . .  86
>      12.6.  CC-Session-Failover AVP  . . . . . . . . . . . . . . . .  86
>      12.7.  CC-Unit-Type AVP . . . . . . . . . . . . . . . . . . . .  86
>      12.8.  Check-Balance-Result AVP . . . . . . . . . . . . . . . .  87
>      12.9.  Credit-Control AVP . . . . . . . . . . . . . . . . . . .  87
>      12.10. Credit-Control-Failure-Handling AVP  . . . . . . . . . .  87
>      12.11. Direct-Debiting-Failure-Handling AVP . . . . . . . . . .  87
>      12.12. Final-Unit-Action AVP  . . . . . . . . . . . . . . . . .  87
>      12.13. Multiple-Services-Indicator AVP  . . . . . . . . . . . .  87
>      12.14. Redirect-Address-Type AVP  . . . . . . . . . . . . . . .  87
>      12.15. Requested-Action AVP . . . . . . . . . . . . . . . . . .  88
>      12.16. Subscription-Id-Type AVP . . . . . . . . . . . . . . . .  88
>      12.17. Tariff-Change-Usage AVP  . . . . . . . . . . . . . . . .  88
>      12.18. User-Equipment-Info-Type AVP . . . . . . . . . . . . . .  88
>    13. Credit-Control Application Related Parameters . . . . . . . .  88
>    14. Security Considerations . . . . . . . . . . . . . . . . . . .  89
>      14.1.  Direct Connection with Redirects . . . . . . . . . . . .  90
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016               [Page 4]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
>    15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  91
>      15.1.  Normative References . . . . . . . . . . . . . . . . . .  91
>      15.2.  Informative References . . . . . . . . . . . . . . . . .  92
>    Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  93
>    Appendix B.  Credit-Control Sequences . . . . . . . . . . . . . .  93
>      B.1.  Flow I  . . . . . . . . . . . . . . . . . . . . . . . . .  93
>      B.2.  Flow II . . . . . . . . . . . . . . . . . . . . . . . . .  96
>      B.3.  Flow III  . . . . . . . . . . . . . . . . . . . . . . . .  98
>      B.4.  Flow IV . . . . . . . . . . . . . . . . . . . . . . . . .  98
>      B.5.  Flow V  . . . . . . . . . . . . . . . . . . . . . . . . . 100
>      B.6.  Flow VI . . . . . . . . . . . . . . . . . . . . . . . . . 101
>      B.7.  Flow VII  . . . . . . . . . . . . . . . . . . . . . . . . 102
>      B.8.  Flow VIII . . . . . . . . . . . . . . . . . . . . . . . . 104
>      B.9.  Flow IX . . . . . . . . . . . . . . . . . . . . . . . . . 106
>    Appendix C.  Changes relative to RFC4006  . . . . . . . . . . . . 111
>    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 112
203,205c262,264
<    example, the 3GPP Charging and Billing requirements [3GPPCHARG] state
<    that an application must be able to rate service information in
<    real-time.  In addition, it is necessary to check that the end user's
---
>    example, the 3GPP Charging and Billing requirements [TGPPCHARG] state
>    that an application must be able to rate service information in real-
>    time.  In addition, it is necessary to check that the end user's
218,222d276
<    prepaid users.  The credit authorization shall be generic and
<    applicable to all the service environments required to support
<    prepaid services.
< 
< 
226c280
< Hakala, et al.              Standards Track                     [Page 4]
---
> Bertz, et al.           Expires December 15, 2016               [Page 5]
228c282
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
230a285,288
>    prepaid users.  The credit authorization shall be generic and
>    applicable to all the service environments required to support
>    prepaid services.
> 
241,243c299,301
<    In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
<    "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
<    described in [KEYWORDS].
---
>    In this document, the key words "MAY", "MUST", "MUST NOT",
>    "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be
>    interpreted as described in [RFC2119].
247,257c305
<    AAA
< 
<    Authentication, Authorization, and Accounting
< 
<    AA answer
< 
<    AA answer generically refers to a service specific authorization and
<    authentication answer.  AA answer commands are defined in service
<    specific authorization applications, e.g., [NASREQ] and [DIAMMIP].
< 
<    AA request
---
>    AAA  Authentication, Authorization, and Accounting
259,261c307,330
<    AA request generically refers to a service specific authorization and
<    authentication request.  AA request commands are defined in service
<    specific authorization applications e.g., [NASREQ] and [DIAMMIP].
---
>    AA answer  AA answer generically refers to a service specific
>       authorization and authentication answer.  AA answer commands are
>       defined in service specific authorization applications, e.g.,
>       [RFC7155] and [RFC4004].
> 
>    AA request  AA request generically refers to a service specific
>       authorization and authentication request.  AA request commands are
>       defined in service specific authorization applications e.g.,
>       [RFC7155] and [RFC4004].
> 
>    Credit-control  Credit-control is a mechanism that directly interacts
>       in real-time with an account and controls or monitors the charges
>       related to the service usage.  Credit-control is a process of
>       checking whether credit is available, credit-reservation,
>       deduction of credit from the end user account when service is
>       completed and refunding of reserved credit that is not used.
> 
>    Diameter Credit-control Server  A Diameter credit-control server acts
>       as a prepaid server, performing real-time rating and credit-
>       control.  It is located in the home domain and is accessed by
>       service elements or Diameter AAA servers in real-time for purpose
>       of price determination and credit-control before the service event
>       is delivered to the end-user.  It may also interact with business
>       support systems.
263d331
<    Credit-control
265,270d332
<    Credit-control is a mechanism that directly interacts in real-time
<    with an account and controls or monitors the charges related to the
<    service usage.  Credit-control is a process of checking whether
<    credit is available, credit-reservation, deduction of credit from the
<    end user account when service is completed and refunding of reserved
<    credit that is not used.
272,330d333
<    Diameter Credit-control Server
< 
<    A Diameter credit-control server acts as a prepaid server, performing
<    real-time rating and credit-control.  It is located in the home
<    domain and is accessed by service elements or Diameter AAA servers in
< 
< 
< 
< 
< 
< Hakala, et al.              Standards Track                     [Page 5]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
<    real-time for purpose of price determination and credit-control
<    before the service event is delivered to the end-user.  It may also
<    interact with business support systems.
< 
<    Diameter Credit-control Client
< 
<    A Diameter credit-control client is an entity that interacts with a
<    credit-control server.  It monitors the usage of the granted quota
<    according to instructions returned by credit-control server.
< 
<    Interrogation
< 
<    The Diameter credit-control client uses interrogation to initiate a
<    session based credit-control process.  During the credit-control
<    process, it is used to report the used quota and request a new one.
<    An interrogation maps to a request/answer transaction.
< 
<    One-time event
< 
<    Basically, a request/answer transaction of type event.
< 
<    Rating
< 
<    The act of determining the cost of the service event.
< 
<    Service
< 
<    A type of task performed by a service element for an end user.
< 
<    Service Element
< 
<    A network element that provides a service to the end users.  The
<    Service Element may include the Diameter credit-control client, or
<    another entity (e.g., RADIUS AAA server) that can act as a Credit-
<    control client on behalf of the Service Element.  In the latter case,
<    the interface between the Service Element and the Diameter credit-
<    control client is outside the scope of this specification.  Examples
<    of the Service Elements include Network Access Server (NAS), SIP
<    Proxy, and Application Servers such as messaging server, content
<    server, and gaming server.
< 
<    Service Event
< 
<    An event relating to a service provided to the end user.
332a336,381
> Bertz, et al.           Expires December 15, 2016               [Page 6]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
>    Diameter Credit-control Client  A Diameter credit-control client is
>       an entity that interacts with a credit-control server.  It
>       monitors the usage of the granted quota according to instructions
>       returned by credit-control server.
> 
>    Interrogation  The Diameter credit-control client uses interrogation
>       to initiate a session based credit-control process.  During the
>       credit-control process, it is used to report the used quota and
>       request a new one.  An interrogation maps to a request/answer
>       transaction.
> 
>    One-time event  Basically, a request/answer transaction of type
>       event.
> 
>    Rating  The act of determining the cost of the service event.
> 
>    Service  A type of task performed by a service element for an end
>       user.
> 
>    Service Element  A network element that provides a service to the end
>       users.  The Service Element may include the Diameter credit-
>       control client, or another entity (e.g., RADIUS AAA server) that
>       can act as a Credit- control client on behalf of the Service
>       Element.  In the latter case, the interface between the Service
>       Element and the Diameter credit- control client is outside the
>       scope of this specification.  Examples of the Service Elements
>       include Network Access Server (NAS), SIP Proxy, and Application
>       Servers such as messaging server, content server, and gaming
>       server.
> 
>    Service Event  An event relating to a service provided to the end
>       user.
> 
>    Session based credit-control  A credit-control process that makes use
>       of several interrogations: the first, a possible intermediate, and
>       the final.  The first interrogation is used to reserve money from
>       the user's account and to initiate the process.  The intermediate
>       interrogations may be needed to request new quota while the
>       service is being rendered.  The final interrogation is used to
>       exit the process.  The credit-control server is required to
>       maintain session state for session-based credit- control.
333a383
> 1.3.  Advertising Application Support
334a385,388
>    Diameter nodes conforming to this specification MUST advertise
>    support by including the value of 4 in the Auth-Application-Id of the
>    Capabilities-Exchange-Request and Capabilities-Exchange-Answer
>    command [RFC6733].
338c392
< Hakala, et al.              Standards Track                     [Page 6]
---
> Bertz, et al.           Expires December 15, 2016               [Page 7]
340,354c394
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
<    Session based credit-control
< 
<    A credit-control process that makes use of several interrogations:
<    the first, a possible intermediate, and the final.  The first
<    interrogation is used to reserve money from the user's account and to
<    initiate the process.  The intermediate interrogations may be needed
<    to request new quota while the service is being rendered.  The final
<    interrogation is used to exit the process.  The credit-control server
<    is required to maintain session state for session-based credit-
<    control.
< 
< 1.3.  Advertising Application Support
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
356,359d395
<    Diameter nodes conforming to this specification MUST advertise
<    support by including the value of 4 in the Auth-Application-Id of the
<    Capabilities-Exchange-Request and Capabilities-Exchange-Answer
<    command [DIAMBASE].
364c400
<    [RFC2866] and Diameter base [DIAMBASE] are not sufficient for real-
---
>    [RFC2866] and Diameter base [RFC6733] are not sufficient for real-
367c403
<    authorization applications, [NASREQ] and [DIAMMIP], only provide
---
>    authorization applications, [RFC7155] and [RFC4004], only provide
392,398d427
< 
< 
< Hakala, et al.              Standards Track                     [Page 7]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
415a445,452
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016               [Page 8]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
419c456
<                    Service Element   AAA and CC
---
>                   Service Element   AAA and CC
433c470,471
<               Figure 1: Typical credit-control architecture
---
> 
>                Figure 1: Typical credit-control architecture
446,454d483
< 
< 
< 
< 
< Hakala, et al.              Standards Track                     [Page 8]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
461c490
<    [DIAMBASE], section 2.8.
---
>    [RFC6733], section 2.8.
473,488d501
<    Command-Name                  Abbrev.    Code     Reference
<    -----------------------------------------------------------
<    Credit-Control-Request        CCR        272      3.1
<    Credit-Control-Answer         CCA        272      3.2
< 
<    Diameter Base [DIAMBASE] defines in the section 3.2 the Command Code
<    ABNF specification.  These formats are observed in Credit-Control
<    messages.
< 
< 3.1.  Credit-Control-Request (CCR) Command
< 
<    The Credit-Control-Request message (CCR) is indicated by the
<    command-code field being set to 272 and the 'R' bit being set in the
<    Command Flags field.  It is used between the Diameter credit-control
<    client and the credit-control server to request credit authorization
<    for a given service.
490,491d502
<    The Auth-Application-Id MUST be set to the value 4, indicating the
<    Diameter credit-control application.
492a504,506
> Bertz, et al.           Expires December 15, 2016               [Page 9]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
494a509,514
>           +------------------------+---------+------+-----------+
>           | Command-Name           | Abrrev. | Code | Reference |
>           +------------------------+---------+------+-----------+
>           | Credit-Control-Request | CCR     | 272  | 3.1       |
>           | Credit-Control-Answer  | CCA     | 272  | 3.2       |
>           +------------------------+---------+------+-----------+
495a516
>                      Table 1: Credit-Control Commands
496a518,520
>    Diameter Base [RFC6733] defines in the section 3.2 the Command Code
>    format specification.  These formats are observed in Credit-Control
>    messages.
497a522
> 3.1.  Credit-Control-Request (CCR) Command
498a524,528
>    The Credit-Control-Request message (CCR) is indicated by the command-
>    code field being set to 272 and the 'R' bit being set in the Command
>    Flags field.  It is used between the Diameter credit-control client
>    and the credit-control server to request credit authorization for a
>    given service.
499a530,531
>    The Auth-Application-Id MUST be set to the value 4, indicating the
>    Diameter credit-control application.
500a533
>    Message Format
506,508d538
< Hakala, et al.              Standards Track                     [Page 9]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
511d540
<    Message Format
513,541d541
<       <Credit-Control-Request> ::= < Diameter Header: 272, REQ, PXY >
<                                    < Session-Id >
<                                    { Origin-Host }
<                                    { Origin-Realm }
<                                    { Destination-Realm }
<                                    { Auth-Application-Id }
<                                    { Service-Context-Id }
<                                    { CC-Request-Type }
<                                    { CC-Request-Number }
<                                    [ Destination-Host ]
<                                    [ User-Name ]
<                                    [ CC-Sub-Session-Id ]
<                                    [ Acct-Multi-Session-Id ]
<                                    [ Origin-State-Id ]
<                                    [ Event-Timestamp ]
<                                   *[ Subscription-Id ]
<                                    [ Service-Identifier ]
<                                    [ Termination-Cause ]
<                                    [ Requested-Service-Unit ]
<                                    [ Requested-Action ]
<                                   *[ Used-Service-Unit ]
<                                    [ Multiple-Services-Indicator ]
<                                   *[ Multiple-Services-Credit-Control ]
<                                   *[ Service-Parameter-Info ]
<                                    [ CC-Correlation-Id ]
<                                    [ User-Equipment-Info ]
<                                   *[ Proxy-Info ]
<                                   *[ Route-Record ]
<                                   *[ AVP ]
559a560,562
> Bertz, et al.           Expires December 15, 2016              [Page 10]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
562,564c565,593
< Hakala, et al.              Standards Track                    [Page 10]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
---
>    <Credit-Control-Request> ::= < Diameter Header: 272, REQ, PXY >
>                                 < Session-Id >
>                                 { Origin-Host }
>                                 { Origin-Realm }
>                                 { Destination-Realm }
>                                 { Auth-Application-Id }
>                                 { Service-Context-Id }
>                                 { CC-Request-Type }
>                                     { CC-Request-Number }
>                                     [ Destination-Host ]
>                                     [ User-Name ]
>                                     [ CC-Sub-Session-Id ]
>                                     [ Acct-Multi-Session-Id ]
>                                     [ Origin-State-Id ]
>                                     [ Event-Timestamp ]
>                                    *[ Subscription-Id ]
>                                     [ Service-Identifier ]
>                                     [ Termination-Cause ]
>                                     [ Requested-Service-Unit ]
>                                     [ Requested-Action ]
>                                    *[ Used-Service-Unit ]
>                                     [ Multiple-Services-Indicator ]
>                                    *[ Multiple-Services-Credit-Control ]
>                                    *[ Service-Parameter-Info ]
>                                     [ CC-Correlation-Id ]
>                                     [ User-Equipment-Info ]
>                                    *[ Proxy-Info ]
>                                    *[ Route-Record ]
>                                    *[ AVP ]
577,605c606,650
<       <Credit-Control-Answer> ::= < Diameter Header: 272, PXY >
<                                   < Session-Id >
<                                   { Result-Code }
<                                   { Origin-Host }
<                                   { Origin-Realm }
<                                   { Auth-Application-Id }
<                                   { CC-Request-Type }
<                                   { CC-Request-Number }
<                                   [ User-Name ]
<                                   [ CC-Session-Failover ]
<                                   [ CC-Sub-Session-Id ]
<                                   [ Acct-Multi-Session-Id ]
<                                   [ Origin-State-Id ]
<                                   [ Event-Timestamp ]
<                                   [ Granted-Service-Unit ]
<                                  *[ Multiple-Services-Credit-Control ]
<                                   [ Cost-Information]
<                                   [ Final-Unit-Indication ]
<                                   [ Check-Balance-Result ]
<                                   [ Credit-Control-Failure-Handling ]
<                                   [ Direct-Debiting-Failure-Handling ]
<                                   [ Validity-Time]
<                                  *[ Redirect-Host]
<                                   [ Redirect-Host-Usage ]
<                                   [ Redirect-Max-Cache-Time ]
<                                  *[ Proxy-Info ]
<                                  *[ Route-Record ]
<                                  *[ Failed-AVP ]
<                                  *[ AVP ]
---
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 11]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
>         <Credit-Control-Answer> ::= < Diameter Header: 272, PXY >
>                                     < Session-Id >
>                                     { Result-Code }
>                                     { Origin-Host }
>                                     { Origin-Realm }
>                                     { Auth-Application-Id }
>                                     { CC-Request-Type }
>                                     { CC-Request-Number }
>                                     [ User-Name ]
>                                     [ CC-Session-Failover ]
>                                     [ CC-Sub-Session-Id ]
>                                     [ Acct-Multi-Session-Id ]
>                                     [ Origin-State-Id ]
>                                     [ Event-Timestamp ]
>                                     [ Granted-Service-Unit ]
>                                    *[ Multiple-Services-Credit-Control ]
>                                     [ Cost-Information]
>                                     [ Final-Unit-Indication ]
>                                     [ Check-Balance-Result ]
>                                     [ Credit-Control-Failure-Handling ]
>                                     [ Direct-Debiting-Failure-Handling ]
>                                     [ Validity-Time]
>                                    *[ Redirect-Host]
>                                     [ Redirect-Host-Usage ]
>                                     [ Redirect-Max-Cache-Time ]
>                                    *[ Proxy-Info ]
>                                    *[ Route-Record ]
>                                    *[ Failed-AVP ]
>                                    *[ AVP ]
> 
615,622d659
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 11]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
630a668,676
> 
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 12]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
648c694
<    is described in more detail, with more variations, in section 5.
---
>    is described in more detail, with more variations, in Section 5.
672,678d717
< 
< 
< Hakala, et al.              Standards Track                    [Page 12]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
685a725,732
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 13]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
723,726c770,773
<    1a. The service SHOULD re-use existing AVPs if it can use AVPs
<    defined in existing Diameter applications (e.g., NASREQ for network
<    access services).  Re-use of existing AVPs is strongly recommended in
<    [DIAMBASE].
---
>    1a.  The service SHOULD re-use existing AVPs if it can use AVPs
>    defined in existing Diameter applications (e.g., [RFC7155] for
>    network access services).  Re-use of existing AVPs is strongly
>    recommended in [RFC6733].
727a775,777
>    For AVPs of type Enumerated, the service may require a new value to
>    be defined.  Allocation of new AVP values is done as specified in
>    [RFC6733], section 1.3.
730,732d779
< Hakala, et al.              Standards Track                    [Page 13]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
735,737d781
<    For AVPs of type Enumerated, the service may require a new value to
<    be defined.  Allocation of new AVP values is done as specified in
<    [DIAMBASE], section 1.2.
739c783,789
<    1b. New AVPs can be defined if the existing AVPs do not provide
---
> 
> Bertz, et al.           Expires December 15, 2016              [Page 14]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
>    1b.  New AVPs can be defined if the existing AVPs do not provide
741c791
<    in [DIAMBASE] for creating new AVPs MUST be followed.
---
>    in [RFC6733] for creating new AVPs MUST be followed.
743c793
<    1c. For services specific only to one vendor's implementation, a
---
>    1c.  For services specific only to one vendor's implementation, a
746c796
<    allocation of global AVPs is encouraged instead; refer to [DIAMBASE].
---
>    allocation of global AVPs is encouraged instead; refer to [RFC6733].
748c798
<    2. The Service-Parameter-Info AVP MAY be used as a container to pass
---
>    2.  The Service-Parameter-Info AVP MAY be used as a container to pass
753c803
<    section 8.43.
---
>    Section 8.43.
761,766c811,816
<    Parameter-Info AVP or Service-Context-Id AVP (defined in section
<    8.42) are not within the scope of this document.  To facilitate
<    interoperability, it is RECOMMENDED that the rating input and the
<    values of the Service-Context-Id be coordinated via an informational
<    RFC or other permanent and readily available reference.  The
<    specification of another cooperative standardization body (e.g.,
---
>    Parameter-Info AVP or Service-Context-Id AVP (defined in
>    Section 8.42) are not within the scope of this document.  To
>    facilitate interoperability, it is RECOMMENDED that the rating input
>    and the values of the Service-Context-Id be coordinated via an
>    informational RFC or other permanent and readily available reference.
>    The specification of another cooperative standardization body (e.g.,
782,790d831
< 
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 14]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
796a838,844
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 15]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
802c850
<    [DIAMBASE].
---
>    [RFC6733].
819c867
<    rules described in [NASREQ] for formatting the Diameter AVP MUST be
---
>    rules described in [RFC7155] for formatting the Diameter AVP MUST be
837a886,887
>    control).  In this case, the credit-control server MUST maintain the
>    credit-control session state.
838a889,891
>    Each credit-control session MUST have a globally unique Session-Id as
>    defined in [RFC6733], which MUST NOT be changed during the lifetime
>    of a credit-control session.
842,845d894
< Hakala, et al.              Standards Track                    [Page 15]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
847,848c896,898
<    control).  In this case, the credit-control server MUST maintain the
<    credit-control session state.
---
> Bertz, et al.           Expires December 15, 2016              [Page 16]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
850,852d899
<    Each credit-control session MUST have a globally unique Session-Id as
<    defined in [DIAMBASE], which MUST NOT be changed during the lifetime
<    of a credit-control session.
885c932
<    the Validity-Time, as defined in section 13).  Since credit-control
---
>    the Validity-Time, as defined in Section 13).  Since credit-control
891,902d937
< 
< 
< 
< 
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 16]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
913a949,956
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 17]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
951,958d993
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 17]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
969a1005,1012
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 18]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
977,991c1020,1034
<    Identifier, and subject to the same cost and rating type (e.g.,
<    $0.1/minute).  It is assumed that the service element is provided
<    with Rating-Groups, Service-Identifiers, and their associated
<    parameters that define what has to be metered by means outside the
<    scope of this specification.  (Examples of parameters associated to
<    Service-Identifiers are IP 5-tuple and HTTP URL.) Service-Identifiers
<    enable authorization on a per-service based credit as well as
<    itemized reporting of service usage.  It is up to the credit-control
<    server whether to authorize credit for one or more services or for
<    the whole rating-group.  However, the client SHOULD always report
<    used units at the finest supported level of granularity.  Where quota
<    is allocated to a rating-group, all the services belonging to that
<    group draw from the allotted quota.  The following is a graphical
<    representation of the relationship between service-identifiers,
<    rating-groups, credit pools, and credit-control (sub-)session.
---
>    Identifier, and subject to the same cost and rating type (e.g., $0.1/
>    minute).  It is assumed that the service element is provided with
>    Rating-Groups, Service-Identifiers, and their associated parameters
>    that define what has to be metered by means outside the scope of this
>    specification.  (Examples of parameters associated to Service-
>    Identifiers are IP 5-tuple and HTTP URL.)  Service-Identifiers enable
>    authorization on a per-service based credit as well as itemized
>    reporting of service usage.  It is up to the credit-control server
>    whether to authorize credit for one or more services or for the whole
>    rating-group.  However, the client SHOULD always report used units at
>    the finest supported level of granularity.  Where quota is allocated
>    to a rating-group, all the services belonging to that group draw from
>    the allotted quota.  The following is a graphical representation of
>    the relationship between service-identifiers, rating-groups, credit
>    pools, and credit-control (sub-)session.
993,994c1036,1037
<                           DCC (Sub-)Session
<                                   |
---
>                            DCC (Sub-)Session
>                                    |
998,1008c1041,1048
<         \        /                 \         /                /
<          \      /                   \       /                /
<           \    /                  Rating-Group 1.......Rating-Group n
<            \  /                         |                    |
<           Quota       ---------------Quota                 Quota
<             |        /                                       |
<             |       /                                        |
<          Credit-Pool                                    Credit-Pool
< 
< 
< 
---
>          \        /                 \         /                /
>           \      /                   \       /                /
>            \    /                  Rating-Group 1.......Rating-Group n
>             \  /                         |                    |
>            Quota       ---------------Quota                 Quota
>              |        /                                       |
>              |       /                                        |
>           Credit-Pool                                    Credit-Pool
1010,1012d1049
< Hakala, et al.              Standards Track                    [Page 18]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
1013a1051
>              Figure 2: Multiple-Service (sub)-Session Example
1023a1062,1068
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 19]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
1059,1069c1104
<          C1*M1 + C2*M2 + ... + Cn*Mn >= S
< 
< 
< 
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 19]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
---
>             C1*M1 + C2*M2 + ... + Cn*Mn >= S
1074c1109
<          S = Q1*M1 + Q2*M2 + ... + Qn*Mn
---
>             S = Q1*M1 + Q2*M2 + ... + Qn*Mn
1081a1117,1124
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 20]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
1086c1129
<    Where multiple G-S-U-Pool-Reference AVPs (section 8.30) with the same
---
>    Where multiple G-S-U-Pool-Reference AVPs (Section 8.30) with the same
1088c1131
<    Credit-Control AVP (section 8.16) along with the Granted-Service-Unit
---
>    Credit-Control AVP (Section 8.16) along with the Granted-Service-Unit
1102c1145
<    mechanism (the mechanism described in section 5.1.1).  Therefore,
---
>    mechanism (the mechanism described in Section 5.1.1).  Therefore,
1118,1126d1160
< 
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 20]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
1128,1129c1162,1163
<    section 5.7 and reflected in the basic credit-control state machine
<    in section 7.  Credit-control clients and servers implementing the
---
>    Section 5.7 and reflected in the basic credit-control state machine
>    in Section 7.  Credit-control clients and servers implementing the
1136c1170
<    timer (section 13) every time a CCR message with the value
---
>    timer (Section 13) every time a CCR message with the value
1138a1173,1180
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 21]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
1140c1182
<    when a problem for the session is detected according to section 5.7
---
>    when a problem for the session is detected according to Section 5.7
1164,1168c1206,1210
<    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
---
>    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
1174,1182d1215
< 
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 21]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
1196a1230,1236
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 22]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
1231,1238d1270
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 22]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
1241c1273
<    section 5.6.
---
>    Section 5.6.
1254c1286,1293
<    In service environments such as the Network Access Server (NAS), it
---
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 23]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
>    In service environments such as the Network Access Server (NAS), it
1267,1275c1306,1314
<    scenarios, there is a substantial decoupling between
<    registration/access to the network and the actual service request
<    (i.e., the authentication/authorization is executed once at
<    registration/access to the network and is not executed for every
<    service event requested by the subscriber).  In these environments,
<    it is more appropriate to perform the first interrogation after the
<    user has been authenticated and authorized.  The first, the
<    intermediate, and the final interrogations are executed with credit-
<    control commands defined in this specification.
---
>    scenarios, there is a substantial decoupling between registration/
>    access to the network and the actual service request (i.e., the
>    authentication/authorization is executed once at registration/access
>    to the network and is not executed for every service event requested
>    by the subscriber).  In these environments, it is more appropriate to
>    perform the first interrogation after the user has been authenticated
>    and authorized.  The first, the intermediate, and the final
>    interrogations are executed with credit- control commands defined in
>    this specification.
1287,1294d1325
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 23]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
1304,1338d1334
<                                            Diameter
<    End User        Service Element        AAA Server         CC Server
<                      (CC Client)
<       | Registration      | AA request/answer(accounting,cc or both)|
<       |<----------------->|<------------------>|                    |
<       |        :          |                    |                    |
<       |        :          |                    |                    |
<       | Service Request   |                    |                    |
<       |------------------>|                    |                    |
<       |                   | CCR(Initial,Credit-Control AVPs)        |
<       |                  +|---------------------------------------->|
<       |         CC stream||                    |  CCA(Granted-Units)|
<       |                  +|<----------------------------------------|
<       | Service Delivery  |                    |                    |
<       |<----------------->| ACR(start,Accounting AVPs)              |
<       |         :         |------------------->|+                   |
<       |         :         |                ACA || Accounting stream |
<       |                   |<-------------------|+                   |
<       |         :         |                    |                    |
<       |         :         |                    |                    |
<       |                   | CCR(Update,Used-Units)                  |
<       |                   |---------------------------------------->|
<       |                   |                    |  CCA(Granted-Units)|
<       |                   |<----------------------------------------|
<       |         :         |                    |                    |
<       |         :         |                    |                    |
<       | End of Service    |                    |                    |
<       |------------------>| CCR(Termination, Used-Units)            |
<       |                   |---------------------------------------->|
<       |                   |                    |               CCA  |
<       |                   |<----------------------------------------|
<       |                   | ACR(stop)          |                    |
<       |                   |------------------->|                    |
<       |                   |                ACA |                    |
<       |                   |<-------------------|                    |
1340,1341d1335
<     Figure 2: Protocol example with first interrogation after user's
<                       authorization/authentication
1346c1340,1344
< Hakala, et al.              Standards Track                    [Page 24]
---
> 
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 24]
1348c1346
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
1350a1349,1387
>                                               Diameter
>    End User        Service Element        AAA Server         CC Server
>                       (CC Client)
>        | Registration      | AA request/answer(accounting,cc or both)|
>        |<----------------->|<------------------>|                    |
>        |        :          |                    |                    |
>        |        :          |                    |                    |
>        | Service Request   |                    |                    |
>        |------------------>|                    |                    |
>        |                   | CCR(Initial,Credit-Control AVPs)        |
>        |                  +|---------------------------------------->|
>        |         CC stream||                    |  CCA(Granted-Units)|
>        |                  +|<----------------------------------------|
>        | Service Delivery  |                    |                    |
>        |<----------------->| ACR(start,Accounting AVPs)              |
>        |         :         |------------------->|+                   |
>        |         :         |                ACA || Accounting stream |
>        |                   |<-------------------|+                   |
>        |         :         |                    |                    |
>        |         :         |                    |                    |
>        |                   | CCR(Update,Used-Units)                  |
>        |                   |---------------------------------------->|
>        |                   |                    |  CCA(Granted-Units)|
>        |                   |<----------------------------------------|
>        |         :         |                    |                    |
>        |         :         |                    |                    |
>        | End of Service    |                    |                    |
>        |------------------>| CCR(Termination, Used-Units)            |
>        |                   |---------------------------------------->|
>        |                   |                    |               CCA  |
>        |                   |<----------------------------------------|
>        |                   | ACR(stop)          |                    |
>        |                   |------------------->|                    |
>        |                   |                ACA |                    |
>        |                   |<-------------------|                    |
> 
>      Figure 3: Protocol example with first interrogation after user's
>                        authorization/authentication
> 
1358,1365c1395,1409
<    relevant credit-control specific AVPs to the proper
<    authorization/authentication command to perform the first
<    interrogation toward the home Diameter AAA server.  The Auth-
<    Application-Id is set to the appropriate value, as defined in the
<    relevant service specific authorization/authentication application
<    document (e.g., [NASREQ], [DIAMMIP]).  The home Diameter AAA server
<    authenticates/authorizes the subscriber and determines whether
<    credit-control is required.
---
>    relevant credit-control specific AVPs to the proper authorization/
>    authentication command to perform the first interrogation toward the
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 25]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
>    home Diameter AAA server.  The Auth- Application-Id is set to the
>    appropriate value, as defined in the relevant service specific
>    authorization/authentication application document (e.g., [RFC7155],
>    [RFC4004]).  The home Diameter AAA server authenticates/authorizes
>    the subscriber and determines whether credit-control is required.
1396c1440
<    specific application (e.g., [NASREQ], [DIAMMIP]).  It will then
---
>    specific application (e.g., [RFC7155], [RFC4004]).  It will then
1399,1406d1442
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 25]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
1416a1453,1460
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 26]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
1419c1463
<    section 8.2).
---
>    Section 8.2).
1424,1431c1468,1475
<    AVP with a value set to RE_AUTHORIZATION to indicate that the
<    credit-control server MUST NOT be contacted.  When session based
<    credit-control is used for the subscriber, a constant credit-control
<    message stream flows through the home Diameter AAA server.  The home
<    Diameter AAA server can make use of this credit-control message flow
<    to deduce that the user's activity is ongoing; therefore, it is
<    recommended to set the authorization-lifetime to a reasonably high
<    value when credit-control is used for the subscriber.
---
>    AVP with a value set to RE_AUTHORIZATION to indicate that the credit-
>    control server MUST NOT be contacted.  When session based credit-
>    control is used for the subscriber, a constant credit-control message
>    stream flows through the home Diameter AAA server.  The home Diameter
>    AAA server can make use of this credit-control message flow to deduce
>    that the user's activity is ongoing; therefore, it is recommended to
>    set the authorization-lifetime to a reasonably high value when
>    credit-control is used for the subscriber.
1436a1481,1489
>    The following diagram illustrates the use of authorization/
>    authentication messages to perform the first interrogation.  The
>    parallel accounting stream is not shown in the figure.
> 
> 
> 
> 
> 
> 
1458,1460d1510
< Hakala, et al.              Standards Track                    [Page 26]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
1461a1512,1514
> Bertz, et al.           Expires December 15, 2016              [Page 27]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
1463,1466d1515
<    The following diagram illustrates the use of
<    authorization/authentication messages to perform the first
<    interrogation.  The parallel accounting stream is not shown in the
<    figure.
1468c1517
<                     Service Element         Diameter
---
>                    Service Element         Diameter
1470,1497c1519,1546
<       | Service Request   | AA Request (CC AVPs)                    |
<       |------------------>|------------------->|                    |
<       |                   |                    | CCR(Initial, CC AVPs)
<       |                   |                    |------------------->|
<       |                   |                    |    CCA(Granted-Units)
<       |                   |                    |<-------------------|
<       |                   | AA Answer(Granted-Units)                |
<       | Service Delivery  |<-------------------|                    |
<       |<----------------->|                    |                    |
<       |         :         |                    |                    |
<       |         :         |                    |                    |
<       |         :         |                    |                    |
<       |                   |                    |                    |
<       |                   | CCR(Update,Used-Units)                  |
<       |                   |------------------->| CCR(Update,Used-Units)
<       |                   |                    |------------------->|
<       |                   |                    |  CCA(Granted-Units)|
<       |                   |  CCA(Granted-Units)|<-------------------|
<       |                   |<-------------------|                    |
<       |         :         |                    |                    |
<       |         :         |                    |                    |
<       | End of Service    |                    |                    |
<       |------------------>| CCR(Termination,Used-Units)             |
<       |                   |------------------->| CCR(Term.,Used-Units)
<       |                   |                    |------------------->|
<       |                   |                    |                CCA |
<       |                   |                CCA |<-------------------|
<       |                   |<-------------------|                    |
---
>      | Service Request   | AA Request (CC AVPs)                    |
>      |------------------>|------------------->|                    |
>      |                   |                    | CCR(Initial, CC AVPs)
>      |                   |                    |------------------->|
>      |                   |                    |    CCA(Granted-Units)
>      |                   |                    |<-------------------|
>      |                   | AA Answer(Granted-Units)                |
>      | Service Delivery  |<-------------------|                    |
>      |<----------------->|                    |                    |
>      |         :         |                    |                    |
>      |         :         |                    |                    |
>      |         :         |                    |                    |
>      |                   |                    |                    |
>      |                   | CCR(Update,Used-Units)                  |
>      |                   |------------------->| CCR(Update,Used-Units)
>      |                   |                    |------------------->|
>      |                   |                    |  CCA(Granted-Units)|
>      |                   |  CCA(Granted-Units)|<-------------------|
>      |                   |<-------------------|                    |
>      |         :         |                    |                    |
>      |         :         |                    |                    |
>      | End of Service    |                    |                    |
>      |------------------>| CCR(Termination,Used-Units)             |
>      |                   |------------------->| CCR(Term.,Used-Units)
>      |                   |                    |------------------->|
>      |                   |                    |                CCA |
>      |                   |                CCA |<-------------------|
>      |                   |<-------------------|                    |
1499,1500c1548,1549
<                 Figure 3: Protocol example with use of the
<            authorization messages for the first interrogation
---
>    Figure 4: Protocol example with use of the authorization messages for
>                           the first interrogation
1510a1560,1564
>    credit reservation has been wholly consumed, or upon expiration of
>    the Validity-Time.  It is always up to the Diameter credit-control
>    client to send a new request well in advance of the expiration of the
>    previous request in order to avoid interruption in the service
>    element.  Even if the granted service units reserved by the credit-
1514c1568
< Hakala, et al.              Standards Track                    [Page 27]
---
> Bertz, et al.           Expires December 15, 2016              [Page 28]
1516c1570
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
1519,1523d1572
<    credit reservation has been wholly consumed, or upon expiration of
<    the Validity-Time.  It is always up to the Diameter credit-control
<    client to send a new request well in advance of the expiration of the
<    previous request in order to avoid interruption in the service
<    element.  Even if the granted service units reserved by the credit-
1565a1615,1619
>    The credit-control server MUST deduct the used amount from the end
>    user's account.  It MAY rate the new request and make a new credit-
>    reservation from the end user's account that covers the cost of the
>    requested service event.
> 
1570c1624
< Hakala, et al.              Standards Track                    [Page 28]
---
> Bertz, et al.           Expires December 15, 2016              [Page 29]
1572c1626
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
1575,1579d1628
<    The credit-control server MUST deduct the used amount from the end
<    user's account.  It MAY rate the new request and make a new credit-
<    reservation from the end user's account that covers the cost of the
<    requested service event.
< 
1589c1638
<    section 5.6.
---
>    Section 5.6.
1596c1645
<    graceful service termination described in section 5.6 takes place,
---
>    graceful service termination described in Section 5.6 takes place,
1623a1673,1677
>    unit indication causes user logoff according to local policy), the
>    service element, according to application specific policy, may send a
>    Session-Termination-Request (STR) to the home Diameter AAA server as
>    usual [RFC6733].  Figure 5 illustrates the case when the final-unit
> 
1626c1680
< Hakala, et al.              Standards Track                    [Page 29]
---
> Bertz, et al.           Expires December 15, 2016              [Page 30]
1628c1682
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
1631,1634d1684
<    unit indication causes user logoff according to local policy), the
<    service element, according to application specific policy, may send a
<    Session-Termination-Request (STR) to the home Diameter AAA server as
<    usual [DIAMBASE].  Figure 4 illustrates the case when the final-unit
1638c1688
<                    Service Element        AAA Server        CC Server
---
>                   Service Element        AAA Server        CC Server
1640,1664c1690,1714
<       | Service Delivery  |                    |                    |
<       |<----------------->|                    |                    |
<       |         :         |                    |                    |
<       |         :         |                    |                    |
<       |         :         |                    |                    |
<       |                   |                    |                    |
<       |                   | CCR(Update,Used-Units)                  |
<       |                   |------------------->| CCR(Update,Used-Units)
<       |                   |                    |------------------->|
<       |                   |                  CCA(Final-Unit, Terminate)
<       |              CCA(Final-Unit, Terminate)|<-------------------|
<       |                   |<-------------------|                    |
<       |         :         |                    |                    |
<       |         :         |                    |                    |
<       |  Disconnect user  |                    |                    |
<       |<------------------| CCR(Termination,Used-Units)             |
<       |                   |------------------->| CCR(Term.,Used-Units)
<       |                   |                    |------------------->|
<       |                   |                    |                CCA |
<       |                   |                CCA |<-------------------|
<       |                   |<-------------------|                    |
<       |                   | STR                |                    |
<       |                   |------------------->|                    |
<       |                   |               STA  |                    |
<       |                   |<-------------------|                    |
---
>      | Service Delivery  |                    |                    |
>      |<----------------->|                    |                    |
>      |         :         |                    |                    |
>      |         :         |                    |                    |
>      |         :         |                    |                    |
>      |                   |                    |                    |
>      |                   | CCR(Update,Used-Units)                  |
>      |                   |------------------->| CCR(Update,Used-Units)
>      |                   |                    |------------------->|
>      |                   |                  CCA(Final-Unit, Terminate)
>      |              CCA(Final-Unit, Terminate)|<-------------------|
>      |                   |<-------------------|                    |
>      |         :         |                    |                    |
>      |         :         |                    |                    |
>      |  Disconnect user  |                    |                    |
>      |<------------------| CCR(Termination,Used-Units)             |
>      |                   |------------------->| CCR(Term.,Used-Units)
>      |                   |                    |------------------->|
>      |                   |                    |                CCA |
>      |                   |                CCA |<-------------------|
>      |                   |<-------------------|                    |
>      |                   | STR                |                    |
>      |                   |------------------->|                    |
>      |                   |               STA  |                    |
>      |                   |<-------------------|                    |
1666c1716
<            Figure 4: User disconnected due to exhausted account
---
>            Figure 5: User disconnected due to exhausted account
1670,1677c1720,1725
<    The Diameter credit-control application supports 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 Diameter
<    Credit Control, and the Re-Auth-Request-Type is set to
<    AUTHORIZE_ONLY.
< 
---
>    The Diameter credit-control application supports 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 [RFC6733].  The Auth- Application-Id in
>    the RAR message is set to 4 to indicate Diameter Credit Control, and
>    the Re-Auth-Request-Type is set to AUTHORIZE_ONLY.
1678a1727,1732
>    Section 5.1.2 defines the feature to enable credit-control for
>    multiple services within a single (sub-)session where the server can
>    authorize credit usage at a different level of granularity.  Further,
>    the server may provide credit resources to multiple services or
>    rating groups as a pool (see Section 5.1.2 for details and
>    definitions).  Therefore, the server, based on its service logic and
1682c1736
< Hakala, et al.              Standards Track                    [Page 30]
---
> Bertz, et al.           Expires December 15, 2016              [Page 31]
1684c1738
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
1687,1692d1740
<    Section 5.1.2 defines the feature to enable credit-control for
<    multiple services within a single (sub-)session where the server can
<    authorize credit usage at a different level of granularity.  Further,
<    the server may provide credit resources to multiple services or
<    rating groups as a pool (see section 5.1.2 for details and
<    definitions).  Therefore, the server, based on its service logic and
1735,1742d1782
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 31]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
1748a1789,1796
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 32]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
1790a1839,1844
>    access capability only to/from the specified destinations.  All the
>    IP packets not matching the filters will be dropped or, possibly, re-
>    directed to the service portal.  The user may also be sent an
>    appropriate notification as to why the access has been limited.
>    These actions may be communicated explicitly from the server to the
>    client or may be configured per-service at the client.  Explicitly
1794c1848
< Hakala, et al.              Standards Track                    [Page 32]
---
> Bertz, et al.           Expires December 15, 2016              [Page 33]
1796c1850
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
1799,1804d1852
<    access capability only to/from the specified destinations.  All the
<    IP packets not matching the filters will be dropped or, possibly,
<    re-directed to the service portal.  The user may also be sent an
<    appropriate notification as to why the access has been limited.
<    These actions may be communicated explicitly from the server to the
<    client or may be configured per-service at the client.  Explicitly
1810,1814c1858,1861
<    prompts the user to replenish the account.  In this case, the
<    credit-control server sends only the address of the top-up server
<    where the prepaid user shall be connected after the final granted
<    units have been consumed.  An example of this is given in Appendix A
<    (Flow VII).
---
>    prompts the user to replenish the account.  In this case, the credit-
>    control server sends only the address of the top-up server where the
>    prepaid user shall be connected after the final granted units have
>    been consumed.  An example of this is given in Appendix A (Flow VII).
1817,1819c1864,1866
<    termination by including the Final-Unit-Indication AVP in the
<    Credit-Control-Answer to indicate that the message contains the final
<    units for the service.
---
>    termination by including the Final-Unit-Indication AVP in the Credit-
>    Control-Answer to indicate that the message contains the final units
>    for the service.
1829,1855c1876
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 33]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
<                                             Diameter
---
>                                            Diameter
1857,1903c1878,1900
<                     (CC Client)
<       |  Service Delivery |                    |                    |
<       |<----------------->|                    |                    |
<       |                   |CCR(Update,Used-Units)                   |
<       |                   |------------------->|CCR(Update,Used-Units)
<       |         :         |                    |------------------->|
<       |         :         |                    |CCA(Final-Unit,Action)
<       |         :         |                    |<-------------------|
<       |                   |CCA(Final-Unit,Action)                   |
<       |                   |<-------------------|                    |
<       |                   |                    |                    |
<       |         :         |                    |                    |
<       |         :         |                    |                    |
<       |         :         |                    |                    |
<       | ///////////////   |CCR(Update,Used-Units)                   |
<       |/Final Units End/->|------------------->|CCR(Update,Used-Units)
<       |/Action and    //  |                    |------------------->|
<       |/Restrictions //   |                    |  CCA(Validity-Time)|
<       |/Start       //    |  CCA(Validity-Time)|<-------------------|
<       | /////////////     |<-------------------|                    |
<       |         :         |                    |                    |
<       |         :         |                    |                    |
<       |                 Replenish Account            +-------+      |
<       |<-------------------------------------------->|Account|      |
<       |                   |                    |     +-------+      |
<       |                   |                    |                RAR |
<       |                 + |                RAR |<===================|
<       |                 | |<===================|                    |
<       |                 | | RAA                |                    |
<       |  /////////////  | |===================>| RAA                |
<       | /If supported / | | CCR(Update)        |===================>|
<       | /by CC Server/  | |===================>| CCR(Update)        |
<       | /////////////   | |                    |===================>|
<       |                 | |                    |   CCA(Granted-Unit)|
<       |                 | |   CCA(Granted-Unit)|<===================|
<       |  Restrictions ->+ |<===================|                    |
<       |  removed          |                    |                    |
<       |         :         |                    |                    |
<       |        OR         | CCR(Update)        |                    |
<       |   Validity-Time ->|------------------->| CCR(Update)        |
<       |   expires         |                    |------------------->|
<       |                   |                    |   CCA(Granted-Unit)|
<       |                   |   CCA(Granted-Unit)|<-------------------|
<       |    Restrictions ->|<-------------------|                    |
<       |    removed        |                    |                    |
< 
< 
---
>                    (CC Client)
>      |  Service Delivery |                    |                    |
>      |<----------------->|                    |                    |
>      |                   |CCR(Update,Used-Units)                   |
>      |                   |------------------->|CCR(Update,Used-Units)
>      |         :         |                    |------------------->|
>      |         :         |                    |CCA(Final-Unit,Action)
>      |         :         |                    |<-------------------|
>      |                   |CCA(Final-Unit,Action)                   |
>      |                   |<-------------------|                    |
>      |                   |                    |                    |
>      |         :         |                    |                    |
>      |         :         |                    |                    |
>      |         :         |                    |                    |
>      | ///////////////   |CCR(Update,Used-Units)                   |
>      |/Final Units End/->|------------------->|CCR(Update,Used-Units)
>      |/Action and    //  |                    |------------------->|
>      |/Restrictions //   |                    |  CCA(Validity-Time)|
>      |/Start       //    |  CCA(Validity-Time)|<-------------------|
>      | /////////////     |<-------------------|                    |
>      |         :         |                    |                    |
>      |         :         |                    |                    |
>      |                 Replenish Account            +-------+      |
1906,1908d1902
< Hakala, et al.              Standards Track                    [Page 34]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
1909a1904,1930
> Bertz, et al.           Expires December 15, 2016              [Page 34]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
>      |<-------------------------------------------->|Account|      |
>      |                   |                    |     +-------+      |
>      |                   |                    |                RAR |
>      |                 + |                RAR |<===================|
>      |                 | |<===================|                    |
>      |                 | | RAA                |                    |
>      |  /////////////  | |===================>| RAA                |
>      | /If supported / | | CCR(Update)        |===================>|
>      | /by CC Server/  | |===================>| CCR(Update)        |
>      | /////////////   | |                    |===================>|
>      |                 | |                    |   CCA(Granted-Unit)|
>      |                 | |   CCA(Granted-Unit)|<===================|
>      |  Restrictions ->+ |<===================|                    |
>      |  removed          |                    |                    |
>      |         :         |                    |                    |
>      |        OR         | CCR(Update)        |                    |
>      |   Validity-Time ->|------------------->| CCR(Update)        |
>      |   expires         |                    |------------------->|
>      |                   |                    |   CCA(Granted-Unit)|
>      |                   |   CCA(Granted-Unit)|<-------------------|
>      |    Restrictions ->|<-------------------|                    |
>      |    removed        |                    |                    |
1911c1932
<          Figure 5: Optional graceful service termination procedure
---
>          Figure 6: Optional graceful service termination procedure
1935a1957,1964
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 35]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
1956,1965c1985
<    is considered in section 5.6.3.
< 
< 
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 35]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
---
>    is considered in Section 5.6.3.
1992a2013,2020
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 36]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
2000c2028
<    appropriate Result-Code (see section 9.1) in the Credit-Control-
---
>    appropriate Result-Code (see Section 9.1) in the Credit-Control-
2013,2022d2040
< 
< 
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 36]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
2030,2032c2048,2050
<    AVPs but no Granted-Service-Unit.  It immediately starts the graceful
<    service termination without sending any message to the server.  An
<    example of this case is illustrated in Appendix A.
---
>    AVPs but no Granted-Service-Unit AVP.  It immediately starts the
>    graceful service termination without sending any message to the
>    server.  An example of this case is illustrated in Appendix A.
2050a2069,2076
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 37]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
2071,2078d2096
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 37]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
2091c2109
<    authorization (see section 5.5).  In such a case, upon the successful
---
>    authorization (see Section 5.5).  In such a case, upon the successful
2104a2123,2132
> 
> 
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 38]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
2119,2125c2147,2153
<    [DIAMBASE].  It is RECOMMENDED that the client complement the
<    credit-control failure procedures with backup accounting flow toward
<    an accounting server.  By using different combinations of
<    Accounting-Realtime-Required and Credit-Control-Failure-Handling
<    AVPs, different safety levels can be built.  For example, by choosing
<    a Credit-Control-Failure-Handling AVP equal to CONTINUE for the
<    credit-control flow and a Accounting-Realtime-Required AVP equal to
---
>    [RFC6733].  It is RECOMMENDED that the client complement the credit-
>    control failure procedures with backup accounting flow toward an
>    accounting server.  By using different combinations of Accounting-
>    Realtime-Required and Credit-Control-Failure-Handling AVPs, different
>    safety levels can be built.  For example, by choosing a Credit-
>    Control-Failure-Handling AVP equal to CONTINUE for the credit-control
>    flow and a Accounting-Realtime-Required AVP equal to
2127,2134d2154
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 38]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
2152c2172
<    is detected with a peer, as described in [DIAMBASE].  As a
---
>    is detected with a peer, as described in [RFC6733].  As a
2156c2176
<    server session state machine (section 7), Session-Id AVP, and CC-
---
>    server session state machine (Section 7), Session-Id AVP, and CC-
2160a2181,2188
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 39]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
2175c2203
<    The AAA transport profile [AAATRANS] defines the application layer
---
>    The AAA transport profile [RFC3539] defines the application layer
2177,2178c2205,2206
<    and is controlled by a watchdog timer (Tw) defined in [AAATRANS].
<    The recommended default initial value for Tw (Twinit) is 30 seconds.
---
>    and is controlled by a watchdog timer (Tw) defined in [RFC3539].  The
>    recommended default initial value for Tw (Twinit) is 30 seconds.
2180c2208
<    [AAATRANS], setting too low a value for Twinit is likely to result in
---
>    [RFC3539], setting too low a value for Twinit is likely to result in
2183,2190d2210
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 39]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
2200c2220
<    credit-control client (as defined in section 13) to supervise the
---
>    credit-control client (as defined in Section 13) to supervise the
2216a2237,2244
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 40]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
2218c2246
<    default value is 3 times more than the Tx recommended value.) The
---
>    default value is 3 times more than the Tx recommended value.)  The
2240,2246d2267
< 
< 
< Hakala, et al.              Standards Track                    [Page 40]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
2251c2272
<    The supervision session timer Tcc (as defined in section 13) is used
---
>    The supervision session timer Tcc (as defined in Section 13) is used
2256,2257c2277,2278
<    state SHOULD take place between the primary and the secondary
<    credit-control server.  Implementations supporting the credit-control
---
>    state SHOULD take place between the primary and the secondary credit-
>    control server.  Implementations supporting the credit-control
2272,2274d2292
<    without any credit-reservation.  It can also be used for refunding
<    service units on the user's account or for direct debiting without
<    any credit-reservation.  The one time event is shown in Figure 6.
2276,2287d2293
<                                            Diameter
<    End User        Service Element        AAA Server        CC Server
<                      (CC Client)
<       | Service Request   |                    |                    |
<       |------------------>|                    |                    |
<       |                   | CCR(Event)         |                    |
<       |                   |------------------->| CCR(Event)         |
<       |                   |                    |------------------->|
<       |                   |                    |  CCA(Granted-Units)|
<       |                   |  CCA(Granted-Units)|<-------------------|
<       |  Service Delivery |<-------------------|                    |
<       |<----------------->|                    |                    |
2289d2294
<                          Figure 6: One time event
2291,2293c2296,2299
<    In environments such as the 3GPP architecture, the one time event can
<    be sent from the service element directly to the credit-control
<    server.
---
> Bertz, et al.           Expires December 15, 2016              [Page 41]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
2294a2301,2303
>    without any credit-reservation.  It can also be used for refunding
>    service units on the user's account or for direct debiting withouts
>    any credit-reservation.  The one time event is shown in Figure 7.
2295a2305,2316
>                                           Diameter
>    End User        Service Element        AAA Server        CC Server
>                         (CC Client)
>      | Service Request   |                    |                    |
>      |------------------>|                    |                    |
>      |                   | CCR(Event)         |                    |
>      |                   |------------------->| CCR(Event)         |
>      |                   |                    |------------------->|
>      |                   |                    |  CCA(Granted-Units)|
>      |                   |  CCA(Granted-Units)|<-------------------|
>      |  Service Delivery |<-------------------|                    |
>      |<----------------->|                    |                    |
2298,2300c2319
< Hakala, et al.              Standards Track                    [Page 41]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
---
>                          Figure 7: One time event
2301a2321,2323
>    In environments such as the 3GPP architecture, the one time event can
>    be sent from the service element directly to the credit-control
>    server.
2305c2327
<    The credit-control client may need to know the price of the service
---
>    The credit-control client may need to know the price of the services
2327a2350,2356
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 42]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
2351,2358d2379
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 42]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
2383a2405,2412
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 43]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
2407,2414d2435
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 43]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
2438a2460,2468
> 
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 44]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
2454c2484
<    failure is detected with a peer, as described in [DIAMBASE].  Because
---
>    failure is detected with a peer, as described in [RFC6733].  Because
2458c2488
<    [DIAMBASE], Appendix C.
---
>    [RFC6733], Appendix C.
2462,2472c2492,2494
<    action.  The timer Tx (as defined in section 13) is used in the
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 44]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
<    credit-control client to supervise the communication with the
<    credit-control server.
---
>    action.  The timer Tx (as defined in Section 13) is used in the
>    credit-control client to supervise the communication with the credit-
>    control server.
2494a2517,2524
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 45]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
2502,2503c2532,2533
<    setting the T-flag in the command header as described in [DIAMBASE],
<    section 3.
---
>    setting the T-flag in the command header as described in [RFC6733],
>    Section 3.
2516,2527c2546,2547
<    TERMINATE_OR_BUFFER.  If a failed answer is received for the
< 
< 
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 45]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
<    re-transmitted request, the credit-control client frees all the
---
>    TERMINATE_OR_BUFFER.  If a failed answer is received for the re-
>    transmitted request, the credit-control client frees all the
2536c2556
<    [DIAMBASE], section 3.
---
>    [RFC6733], Section 3.
2550a2571,2580
> 
> 
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 46]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
2561,2562c2591,2592
<    to what state machines have to be supported are discussed in section
<    5.2.
---
>    to what state machines have to be supported are discussed in
>    Section 5.2.
2573,2582d2602
< 
< 
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 46]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
2597,2601c2617,2621
<    DIAMETER_UNABLE_TO_DELIVER, or DIAMETER_LOOP_DETECTED) in the
<    Result-Code AVP of the Credit-Control-Answer command.  The above
<    protocol error notification may ultimately be received in answer to
<    the re-transmitted request to a defined alternative destination, if
<    failover is supported.
---
>    DIAMETER_UNABLE_TO_DELIVER, or DIAMETER_LOOP_DETECTED) in the Result-
>    Code AVP of the Credit-Control-Answer command.  The above protocol
>    error notification may ultimately be received in answer to the re-
>    transmitted request to a defined alternative destination, if failover
>    is supported.
2609a2630,2636
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 47]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
2615c2642
<    user, account being empty, or errors defined in [DIAMBASE].
---
>    user, account being empty, or errors defined in [RFC6733].
2620c2647
<    information about the termination reason, as specified in [DIAMBASE].
---
>    information about the termination reason, as specified in [RFC6733].
2629,2638d2655
< 
< 
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 47]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
2651c2668
<    AVP is set to FAILOVER_SUPPORTED, as described in section 5.7.
---
>    AVP is set to FAILOVER_SUPPORTED, as described in Section 5.7.
2654,2656c2671
<    supported as described in section 6.5.
< 
<    CLIENT, SESSION BASED for the first interrogation with AA request
---
>    supported as described in Section 6.5.
2658,2664d2672
<     State      Event                         Action       New State
<     ---------------------------------------------------------------
<     Idle       Client or device requests     Send          PendingI
<                access/service                AA request
<                                              with added
<                                              CC AVPs,
<                                              start Tx
2666,2669d2673
<     PendingI  Successful AA req.             Grant         Open
<               answer received                service to
<                                              end user,
<                                              stop Tx
2671,2672d2674
<     PendingI  Tx expired                     Disconnect    Idle
<                                              user/dev
2674,2675d2675
<     PendingI  Failed AA answer received      Disconnect    Idle
<                                              user/dev
2677,2680d2676
<     PendingI  AA answer                      Grant         Idle
<               received with result code      service
<               equal to CREDIT_CONTROL_       to end user
<               NOT_APPLICABLE
2682,2684d2677
<     PendingI  User service terminated        Queue         PendingI
<                                              termination
<                                              event
2690,2692d2682
< Hakala, et al.              Standards Track                    [Page 48]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
2695,2699d2684
<     PendingI  Change in rating condition     Queue         PendingI
<                                              changed
<                                              rating
<                                              condition
<                                              event
2701d2685
<       CLIENT, SESSION BASED for the first interrogation with CCR
2703,2704d2686
<     State      Event                          Action       New State
<     ----------------------------------------------------------------
2705a2688,2690
> Bertz, et al.           Expires December 15, 2016              [Page 48]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
2707,2710d2691
<     Idle      Client or device requests      Send         PendingI
<               access/service                 CC initial
<                                              req.,
<                                              start Tx
2712,2713c2693,2721
<     PendingI  Successful CC initial          Stop Tx      Open
<               answer received
---
>    +----------+-------------------------------+-------------+----------+
>    | State    | Event                         | Action      | New      |
>    |          |                               |             | State    |
>    +----------+-------------------------------+-------------+----------+
>    | Idle     | Client or device requests     | Send AA     | PendingI |
>    |          | access/service                | request     |          |
>    |          |                               | with added  |          |
>    |          |                               | CC AVPs,    |          |
>    |          |                               | start Tx    |          |
>    | PendingI | Successful AA req. answer     | Grant       | Open     |
>    |          | received                      | service to  |          |
>    |          |                               | end user,   |          |
>    |          |                               | stop Tx     |          |
>    | PendingI | Tx expired                    | Disconnect  | Idle     |
>    |          |                               | user/dev    |          |
>    | PendingI | Failed AA answer received     | Disconnect  | Idle     |
>    |          |                               | user/dev    |          |
>    | PendingI | AA answer received with       | Grant       | Idle     |
>    |          | result code equal to          | service to  |          |
>    |          | CREDIT_CONTROL_NOT_APPLICABLE | end user    |          |
>    | PendingI | User service terminated       | Queue       | PendingI |
>    |          |                               | termination |          |
>    |          |                               | event       |          |
>    | PendingI | Change in rating condition    | Queue       | PendingI |
>    |          |                               | changed     |          |
>    |          |                               | rating      |          |
>    |          |                               | condition   |          |
>    |          |                               | event       |          |
>    +----------+-------------------------------+-------------+----------+
2715,2717c2723,2724
<     PendingI  Failure to send, or            Grant        Idle
<               temporary error and            service to
<               CCFH equal to CONTINUE         end user
---
>     Table 2: CLIENT, SESSION BASED for the first interrogation with AA
>                                   request
2719,2722d2725
<     PendingI  Failure to send, or            Terminate    Idle
<               temporary error and            end user's
<               CCFH equal to TERMINATE        service
<               or to RETRY_AND_TERMINATE
2724,2726d2726
<     PendingI  Tx expired and CCFH            Terminate    Idle
<               equal to TERMINATE             end user's
<                                              service
2728,2730d2727
<     PendingI  Tx expired and CCFH equal      Grant        PendingI
<               to CONTINUE or to              service to
<               RETRY_AND_TERMINATE            end user
2732,2735d2728
<     PendingI  CC initial answer              Terminate    Idle
<               received with result code      end user's
<               END_USER_SERVICE_DENIED or     service
<               USER_UNKNOWN
2737,2740d2729
<     PendingI  CC initial answer              Grant        Idle
<               received with result code      service
<               equal to CREDIT_CONTROL_       to end user
<               NOT_APPLICABLE
2746,2748d2734
< Hakala, et al.              Standards Track                    [Page 49]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
2751,2753d2736
<     PendingI  Failed CC initial answer       Grant        Idle
<               received and CCFH equal to     service to
<               CONTINUE                       end user
2755,2758d2737
<     PendingI  Failed CC initial answer       Terminate    Idle
<               received and CCFH equal        end user's
<               to TERMINATE or to             service
<               RETRY_AND_TERMINATE
2760,2762d2738
<     PendingI  User service terminated        Queue        PendingI
<                                              termination
<                                              event
2764,2768d2739
<     PendingI  Change in rating condition     Queue        PendingI
<                                              changed
<                                              rating
<                                              condition
<                                              event
2770d2740
<      CLIENT, SESSION BASED for intermediate and final interrogations
2772,2773d2741
<     State     Event                          Action       New State
<     ----------------------------------------------------------------
2775,2778d2742
<     Open      Granted unit elapses           Send         PendingU
<               and no final unit              CC update
<               indication received            req.,
<                                              start Tx
2780,2784c2744,2746
<     Open      Granted unit elapses           Terminate    PendingT
<               and final unit action          end user's
<               equal to TERMINATE             service, send
<               received                       CC termination
<                                              req.
---
> Bertz, et al.           Expires December 15, 2016              [Page 49]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
2786,2789d2747
<     Open      Change in rating condition     Send         PendingU
<               in queue                       CC update
<                                              req.,
<                                              Start Tx
2791,2793c2749,2794
<     Open      Service terminated in queue    Send         PendingT
<                                              CC termination
<                                              req.
---
>    +----------+-------------------------------+-------------+----------+
>    | State    | Event                         | Action      | New      |
>    |          |                               |             | State    |
>    +----------+-------------------------------+-------------+----------+
>    | Idle     | Client or device requests     | Send CC     | PendingI |
>    |          | access/service                | initial     |          |
>    |          |                               | req., start |          |
>    |          |                               | Tx          |          |
>    | PendingI | Successful CC intial answer   | Stop Tx     | Open     |
>    |          | received                      |             |          |
>    | PendingI | Failure to send, or temporary | Grant       | Idle     |
>    |          | error and CCFH equal to       | service to  |          |
>    |          | CONTINUE                      | end user    |          |
>    | PendingI | Failure to send, or temporary | Terminate   | Idle     |
>    |          | error and CCFH equal to       | end user's  |          |
>    |          | TERMINATEor to                | service     |          |
>    |          | RETRY_AND_TERMINATE           |             |          |
>    | PendingI | Tx expired and CCFH equal to  | Terminate   | Idle     |
>    |          | TERMINATE                     | end user's  |          |
>    |          |                               | service     |          |
>    | PendingI | Tx expired and CCFH equal to  | Grant       | Idle     |
>    |          | CONTINUE or to                | service to  |          |
>    |          | RETRY_AND_TERMINATE           | end user    |          |
>    | PendingI | CC initial answer received    | Terminate   | Idle     |
>    |          | with result code              | end user's  |          |
>    |          | END_USER_SERVICE_DENIED or    | service     |          |
>    |          | USER_UNKNOWN                  |             |          |
>    | PendingI | CC initial answer received    | Grant       | Idle     |
>    |          | with result code equal to     | service to  |          |
>    |          | CREDIT_CONTROL_NOT_APPLICABLE | end user    |          |
>    | PendingI | Failed CC initial answer      | Grant       | Idle     |
>    |          | received and CCFH equal to    | service to  |          |
>    |          | CONTINUE                      | end user    |          |
>    | PendingI | Failed CC initial answer      | Terminate   | Idle     |
>    |          | received and CCFH equal to    | end user's  |          |
>    |          | TERMINATE or to               | service     |          |
>    |          | RETRY_AND_TERMINATE           |             |          |
>    | PendingI | User service terminated       | Queue       | PendingI |
>    |          |                               | termination |          |
>    |          |                               | event       |          |
>    | PendingI | Change in rating condition    | Queue       | PendingI |
>    |          |                               | changed     |          |
>    |          |                               | rating      |          |
>    |          |                               | condition   |          |
>    |          |                               | event       |          |
>    +----------+-------------------------------+-------------+----------+
2795,2798c2796
<     Open      Change in rating condition     Send         PendingU
<               or Validity-Time elapses       CC update
<                                              req.,
<                                              Start Tx
---
>     Table 3: CLIENT, SESSION BASED for the first interrogation with CCR
2802c2800
< Hakala, et al.              Standards Track                    [Page 50]
---
> Bertz, et al.           Expires December 15, 2016              [Page 50]
2804c2802
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
2807,2809c2805,2852
<     Open      User service terminated        Send         PendingT
<                                              CC termination
<                                              req.
---
>    +----------+-------------------------------+-------------+----------+
>    | State    | Event                         | Action      | New      |
>    |          |                               |             | State    |
>    +----------+-------------------------------+-------------+----------+
>    | Open     | Granted unit elapses and no   | Send CC     | PendingU |
>    |          | final unit indication         | update req. |          |
>    |          | received                      |             |          |
>    | Open     | Granted unit elapses and      | Terminate   | PendingT |
>    |          | final unit action equal to    | end user's  |          |
>    |          | TERMINATE received            | service,    |          |
>    |          |                               | send CC     |          |
>    |          |                               | termination |          |
>    |          |                               | req.        |          |
>    | Open     | Change in rating condition in | Send CC     | PendingU |
>    |          | queue                         | update      |          |
>    |          |                               | req., Start |          |
>    |          |                               | Tx          |          |
>    | Open     | Service terminated in queue   | Send CC     | PendingT |
>    |          |                               | termination |          |
>    |          |                               | req.        |          |
>    | Open     | Change in rating condition or | Send CC     | PendingU |
>    |          | Validity-Time elapses         | update      |          |
>    |          |                               | req., Start |          |
>    |          |                               | Tx          |          |
>    | Open     | User service terminated       | Send CC     | PendingT |
>    |          |                               | termination |          |
>    |          |                               | req.        |          |
>    | Open     | RAR received                  | Send RAA    | PendingU |
>    |          |                               | followed by |          |
>    |          |                               | CC update   |          |
>    |          |                               | req., start |          |
>    |          |                               | Tx          |          |
>    | PendingU | Successful CC update answer   | Stop Tx     | Open     |
>    |          | received                      |             |          |
>    | PendingU | Failure to send, or temporary | Grant       | Idle     |
>    |          | error and CCFH equal to       | service to  |          |
>    |          | CONTINUE                      | end user    |          |
>    | PendingU | Failure to send, or temporary | Terminate   | Idle     |
>    |          | error and CCFH equal to       | end user's  |          |
>    |          | TERMINATE or to               | service     |          |
>    |          | RETRY_AND_TERMINATE           |             |          |
>    | PendingU | Tx expired and CCFH equal to  | Terminate   | Idle     |
>    |          | TERMINATE                     | end user's  |          |
>    |          |                               | service     |          |
>    | PendingU | Tx expired and CCFH equal to  | Grant       | PendingU |
>    |          | CONTINUE or to                | service to  |          |
>    |          | RETRY_AND_TERMINATE           | end user    |          |
>    | PendingU | CC update answer received     | Terminate   | Idle     |
2811,2814d2853
<     Open      RAR received                   Send RAA     PendingU
<                                              followed by
<                                              CC update req.,
<                                              start Tx
2816,2817d2854
<     PendingU  Successful CC update           Stop Tx      Open
<               answer received
2819,2843c2856,2858
<     PendingU  Failure to send, or            Grant        Idle
<               temporary error and            service to
<               CCFH equal to CONTINUE         end user
< 
<     PendingU  Failure to send, or            Terminate    Idle
<               temporary error and            end user's
<               CCFH equal to TERMINATE        service
<               or to RETRY_AND_TERMINATE
< 
<     PendingU  Tx expired and CCFH            Terminate    Idle
<               equal to TERMINATE             end user's
<                                              service
< 
<     PendingU  Tx expired and CCFH equal      Grant        PendingU
<               to CONTINUE or to              service to
<               RETRY_AND_TERMINATE            end user
< 
<     PendingU  CC update answer               Terminate    Idle
<               received with result code      end user's
<               END_USER_SERVICE_DENIED        service
< 
<     PendingU  CC update answer               Grant        Idle
<               received with result code      service
<               equal to CREDIT_CONTROL_       to end user
<               NOT_APPLICABLE
---
> Bertz, et al.           Expires December 15, 2016              [Page 51]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
2845,2847d2859
<     PendingU  Failed CC update               Grant        Idle
<               answer received and            service to
<               CCFH equal to CONTINUE         end user
2849,2852c2861,2887
<     PendingU  Failed CC update               Terminate    Idle
<               answer received and CCFH       end user's
<               equal to TERMINATE or          service
<               to RETRY_AND_TERMINATE
---
>    |          | with result code              | end user's  |          |
>    |          | END_USER_SERVICE_DENIED       | service     |          |
>    | PendingU | CC update answer received     | Terminate   | Idle     |
>    |          | with result code equal to     | end user's  |          |
>    |          | CREDIT_CONTROL_NOT_APPLICABLE | service     |          |
>    | PendingU | Failed CC update answer       | Grant       | Idle     |
>    |          | received and CCFH equal to    | service to  |          |
>    |          | CONTINUE                      | end user    |          |
>    | PendingU | Failed CC update answer       | Terminate   | Idle     |
>    |          | received and CCFH equal to    | end user's  |          |
>    |          | TERMINATE or to               | service     |          |
>    |          | RETRY_AND_TERMINATE           |             |          |
>    | PendingU | User service terminated       | Queue       | PendingU |
>    |          |                               | termination |          |
>    |          |                               | event       |          |
>    | PendingU | Change in rating condition    | Queue       | PendingU |
>    |          |                               | changed     |          |
>    |          |                               | rating      |          |
>    |          |                               | condition   |          |
>    |          |                               | event       |          |
>    | PendingU | RAR received                  | Send RAA    | PendingU |
>    | PendingT | Successful CC termination     |             | Idle     |
>    |          | answer received               |             |          |
>    | PendingT | Failure to send, temporary    |             | Idle     |
>    |          | error, or failed answer       |             |          |
>    | PendingT | Change in rating condition    |             | PendingT |
>    +----------+-------------------------------+-------------+----------+
2853a2889,2890
>          Table 4: CLIENT, SESSION BASED for intermediate and final
>                               interrogations
2854a2892,2908
>    +----------+--------------------------------+------------+----------+
>    | State    | Event                          | Action     | New      |
>    |          |                                |            | State    |
>    +----------+--------------------------------+------------+----------+
>    | Idle     | Client or device requests a    | Send CC    | PendingE |
>    |          | one-time service               | event      |          |
>    |          |                                | req.,      |          |
>    |          |                                | Start Tx   |          |
>    | Idle     | Request in storage             | Send       | PendingB |
>    |          |                                | stored     |          |
>    |          |                                | request    |          |
>    | PendingE | Grant service to end user      | Send       | Idle     |
>    |          |                                | stored     |          |
>    |          |                                | request    |          |
>    | PendingE | Failure to send, temporary     | Indicate   | Idle     |
>    |          | error, failed CC event answer  | service    |          |
>    |          | received, or Tx expired;       | error      |          |
2858c2912
< Hakala, et al.              Standards Track                    [Page 51]
---
> Bertz, et al.           Expires December 15, 2016              [Page 52]
2860,2865c2914
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
<     PendingU  User service terminated        Queue        PendingU
<                                              termination
<                                              event
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
2867,2871d2915
<     PendingU  Change in rating               Queue        PendingU
<               condition                      changed
<                                              rating
<                                              condition
<                                              event
2873c2917,2964
<     PendingU  RAR received                   Send RAA     PendingU
---
>    |          | requested action CHECK_BALANCE |            |          |
>    |          | or PRICE_ENQUIRY               |            |          |
>    | PendingE | CC event answer received with  | Terminate  | Idle     |
>    |          | result code                    | end user's |          |
>    |          | END_USER_SERVICE_DENIED or     | service    |          |
>    |          | USER_UNKNOWN and Tx running    |            |          |
>    | PendingE | CC event answer received with  | Grant      | Idle     |
>    |          | result code                    | service to |          |
>    |          | CREDIT_CONTROL_NOT_APPLICABLE; | end user   |          |
>    |          | requested action               |            |          |
>    |          | DIRECT_DEBITING                |            |          |
>    | PendingE | Failure to send, temporary     | Grant      | Idle     |
>    |          | error, failed CC event answer  | service to |          |
>    |          | received; requested action     | end user   |          |
>    |          | DIRECT_DEBITING; DDFH equal to |            |          |
>    |          | CONTINUE                       |            |          |
>    | PendingE | Failed CC event answer         | Terminate  | Idle     |
>    |          | received or temporary error;   | end user's |          |
>    |          | requested action               | service    |          |
>    |          | DIRECT_DEBITING; DDFH equal to |            |          |
>    |          | TERMINATE_OR_BUFFER and Tx     |            |          |
>    |          | running                        |            |          |
>    | PendingE | Tx expired; requested action   | Grant      | PendingE |
>    |          | DIRECT_DEBITING                | service to |          |
>    |          |                                | end user   |          |
>    | PendingE | Failure to send; requested     | Store      | Idle     |
>    |          | action DIRECT_DEBITING; DDFH   | request    |          |
>    |          | equal to TERMINATE_OR_BUFFER   | with       |          |
>    |          |                                | T-flag     |          |
>    | PendingE | Failure to send; requested     | Store      | Idle     |
>    |          | action DIRECT_DEBITING; DDFH   | request    |          |
>    |          | equal to TERMINATE_OR_BUFFER   | with       |          |
>    |          |                                | T-flag     |          |
>    | PendingE | Temporary error; requested     | Store      | Idle     |
>    |          | action DIRECT_DEBITING; DDFH   | request    |          |
>    |          | equal to TERMINATE_OR_BUFFER;  |            |          |
>    |          | Tx expired                     |            |          |
>    | PendingE | Failed answer or answer        |            | Idle     |
>    |          | received with result code      |            |          |
>    |          | END_USER_SERVICE DENIED or     |            |          |
>    |          | USER_UNKNOWN; requested action |            |          |
>    |          | DIRECT_DEBITING; Tx expired    |            |          |
>    | PendingE | Failed CC event answer         | Indicate   | Idle     |
>    |          | received; requested action     | service    |          |
>    |          | REFUND_ACCOUNT                 | error and  |          |
>    |          |                                | delete     |          |
>    |          |                                | request    |          |
>    | PendingE | Failure to send or Tx expired; | Store      | Idle     |
2875,2876d2965
<     PendingT  Successful CC                               Idle
<               termination answer received
2878,2879d2966
<     PendingT  Failure to send, temporary                  Idle
<               error, or failed answer
2881,2894c2968,2970
<     PendingT  Change in rating condition                  PendingT
< 
<                        CLIENT, EVENT BASED
< 
<     State     Event                          Action        New State
<     ----------------------------------------------------------------
<     Idle      Client or device requests      Send          PendingE
<               a one-time service             CC event
<                                              req.,
<                                              Start Tx
< 
<     Idle      Request in storage             Send          PendingB
<                                              stored
<                                              request
---
> Bertz, et al.           Expires December 15, 2016              [Page 53]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
2896,2898d2971
<     PendingE  Successful CC event            Grant         Idle
<               answer received                service to
<                                              end user
2900,2905c2973,2984
<     PendingE  Failure to send, temporary     Indicate      Idle
<               error, failed CC event         service
<               answer received, or            error
<               Tx expired; requested
<               action CHECK_BALANCE or
<               PRICE_ENQUIRY
---
>    |          | requested action               | request    |          |
>    |          | REFUND_ACCOUNT                 | with       |          |
>    |          |                                | T-flag     |          |
>    | PendingE | Temporary error, and requested | Store      | Idle     |
>    |          | action REFUND_ACCOUNT          | request    |          |
>    | PendingE | Successful CC answer received  | Delete     | Idle     |
>    |          |                                | request    |          |
>    | PendingE | Failed CC answer received      | Delete     | Idle     |
>    |          |                                | request    |          |
>    | PendingE | Failure to send or temporary   |            | Idle     |
>    |          | error                          |            |          |
>    +----------+--------------------------------+------------+----------+
2907,2910c2986
<     PendingE  CC event answer                Terminate     Idle
<               received with result code      end user's
<               END_USER_SERVICE_DENIED or     service
<               USER_UNKNOWN and Tx running
---
>                             CLIENT, EVENT BASED
2914,2916d2989
< Hakala, et al.              Standards Track                    [Page 52]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
2919,2923d2991
<     PendingE  CC event answer                Grant         Idle
<               received with result code      service
<               CREDIT_CONTROL_NOT_APPLICABLE; to end
<               requested action               user
<               DIRECT_DEBITING
2925,2929d2992
<     PendingE  Failure to send, temporary     Grant         Idle
<               error, or failed CC event      service
<               answer received; requested     to end
<               action DIRECT_DEBITING;        user
<               DDFH equal to CONTINUE
2931,2937d2993
<     PendingE  Failed CC event                Terminate     Idle
<               answer received or temporary   end user's
<               error; requested action        service
<               DIRECT_DEBITING;
<               DDFH equal to
<               TERMINATE_OR_BUFFER and
<               Tx running
2939,2942d2994
<     PendingE  Tx expired; requested          Grant         PendingE
<               action DIRECT_DEBITING         service
<                                              to end
<                                              user
2944,2947d2995
<     PendingE  Failure to send; requested     Store         Idle
<               action DIRECT_DEBITING;        request with
<               DDFH equal to                  T-flag
<               TERMINATE_OR_BUFFER
2949,2953d2996
<     PendingE  Temporary error; requested     Store         Idle
<               action DIRECT_DEBITING;        request
<               DDFH equal to
<               TERMINATE_OR_BUFFER;
<               Tx expired
2955,2959d2997
<     PendingE  Failed answer or answer                      Idle
<               received with result code
<               END_USER_SERVICE DENIED or
<               USER_UNKNOWN; requested action
<               DIRECT_DEBITING; Tx expired
2961,2964d2998
<     PendingE  Failed CC event answer         Indicate      Idle
<               received; requested            service
<               action REFUND_ACCOUNT          error and
<                                              delete request
2970,2972d3003
< Hakala, et al.              Standards Track                    [Page 53]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
2975,2977d3005
<     PendingE  Failure to send or             Store         Idle
<               Tx expired; requested          request
<               action REFUND_ACCOUNT          with T-flag
2979,2981d3006
<     PendingE  Temporary error,               Store         Idle
<               and requested action           request
<               REFUND_ACCOUNT
2983,2984d3007
<     PendingB  Successful CC answer           Delete        Idle
<               received                       request
2986,2987d3008
<     PendingB  Failed CC answer               Delete        Idle
<               received                       request
2989,2990d3009
<     PendingB  Failure to send or                           Idle
<               temporary error
2992d3010
<                    SERVER, SESSION AND EVENT BASED
2994,2995d3011
<     State     Event                          Action        New State
<     ----------------------------------------------------------------
2997,3001d3012
<     Idle      CC initial request             Send          Open
<               received and successfully      CC initial
<               processed                      answer,
<                                              reserve units,
<                                              start Tcc
3003,3007d3013
<     Idle      CC initial request             Send          Idle
<               received but not               CC initial
<               successfully processed         answer with
<                                              Result-Code
<                                              != SUCCESS
3009,3011d3014
<     Idle      CC event request               Send          Idle
<               received and successfully      CC event
<               processed                      answer
3013,3017d3015
<     Idle      CC event request               Send          Idle
<               received but not               CC event
<               successfully processed         answer with
<                                              Result-Code
<                                              != SUCCESS
3026c3024
< Hakala, et al.              Standards Track                    [Page 54]
---
> Bertz, et al.           Expires December 15, 2016              [Page 54]
3028,3037c3026
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
<     Open      CC update request              Send CC       Open
<               received and successfully      update answer,
<               processed                      debit used
<                                              units,
<                                              reserve
<                                              new units,
<                                              restart Tcc
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
3039,3045d3027
<     Open      CC update request              Send          Idle
<               received but not               CC update
<               successfully processed         answer with
<                                              Result-Code
<                                              != SUCCESS,
<                                              debit used
<                                              units
3047,3052c3029,3062
<     Open      CC termination request         Send          Idle
<               received and successfully      CC termin.
<               processed                      answer,
<                                              Stop Tcc,
<                                              debit used
<                                              units
---
>    +-------+------------------------+--------------------------+-------+
>    | State | Event                  | Action                   | New   |
>    |       |                        |                          | State |
>    +-------+------------------------+--------------------------+-------+
>    | Idle  | CC initial request     | Send CC initial answer,  | Open  |
>    |       | received and           | reserve units, start Tcc |       |
>    |       | successfully processed |                          |       |
>    | Idle  | CC initial request     | Send CC initial answer   | Idle  |
>    |       | received but not       | with Result-Code !=      |       |
>    |       | successfully processed | SUCCESS                  |       |
>    | Idle  | CC event request       | Send CC event answer     | Idle  |
>    |       | received and           |                          |       |
>    |       | successfully processed |                          |       |
>    | Idle  | CC event request       | Send CC event answer     | Idle  |
>    |       | received but not       | with Result-Code !=      |       |
>    |       | successfully processed | SUCCESS                  |       |
>    | Open  | CC update request      | Send CC update answer,   | Open  |
>    |       | received and           | debit used units,        |       |
>    |       | successfully processed | reserve new units,       |       |
>    |       |                        | restart Tcc              |       |
>    | Open  | CC update request      | Send CC update answer    | Idle  |
>    |       | received but not       | with Result-Code !=      |       |
>    |       | successfully processed | SUCCESS, debit used      |       |
>    |       |                        | units                    |       |
>    | Open  | CC termination request | Send CC termin. answer,  | Idle  |
>    |       | received and           | Stop Tcc, debit used     |       |
>    |       | successfully processed | units                    |       |
>    | Open  | CC termination request | Send CC termin. answer   | Idle  |
>    |       | received but not       | with Result-Code !=      |       |
>    |       | successfully processed | SUCCESS, debit used      |       |
>    |       |                        | units                    |       |
>    | Open  | Session supervision    | Release reserved units   | Idle  |
>    |       | timer Tcc expired      |                          |       |
>    +-------+------------------------+--------------------------+-------+
3054,3064c3064
<     Open      CC termination request         Send          Idle
<               received but not               CC termin.
<               successfully processed         answer with
<                                              Result-Code
<                                              != SUCCESS,
<                                              debit used
<                                              units
< 
<     Open      Session supervision timer Tcc  Release       Idle
<               expired                        reserved
<                                              units
---
>                       SERVER, SESSION AND EVENT BASED
3074,3077c3074,3076
<    applications, such as [NASREQ] and [DIAMMIP], if the first
<    interrogation is performed as part of the
<    authorization/authentication process, as described in section 5.2.
< 
---
>    applications, such as [RFC7155] and [RFC4004], if the first
>    interrogation is performed as part of the authorization/
>    authentication process, as described in Section 5.2.
3081,3082c3080
< 
< Hakala, et al.              Standards Track                    [Page 55]
---
> Bertz, et al.           Expires December 15, 2016              [Page 55]
3084c3082
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
3087,3088c3085,3086
<    The Diameter AVP rules are defined in the Diameter Base [DIAMBASE],
<    section 4.  These AVP rules are observed in AVPs defined in this
---
>    The Diameter AVP rules are defined in the Diameter Base [RFC6733],
>    Section 4.  These AVP rules are observed in AVPs defined in this
3094c3092
<    [DIAMBASE] specifies the AVP Flag rules for AVPs in section 4.5.
---
>    [RFC6733] specifies the AVP Flag rules for AVPs in section 4.5.
3133a3132
>    G-S-U-Pool-       457  8.30   Grouped    | M  |  P  |    |  V | Y  |
3137,3138c3136
< 
< Hakala, et al.              Standards Track                    [Page 56]
---
> Bertz, et al.           Expires December 15, 2016              [Page 56]
3140c3138
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
3143d3140
<    G-S-U-Pool-       457  8.30   Grouped    | M  |  P  |    |  V | Y  |
3194c3191,3192
< Hakala, et al.              Standards Track                    [Page 57]
---
> 
> Bertz, et al.           Expires December 15, 2016              [Page 57]
3196c3194
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
3227,3230c3225,3229
<    INITIAL_REQUEST                 1
<       An Initial request is used to initiate a credit-control session,
<       and contains credit control information that is relevant to the
<       initiation.
---
>    INITIAL_REQUEST 1
> 
>    An Initial request is used to initiate a credit-control session, and
>    contains credit control information that is relevant to the
>    initiation.
3232,3238c3231
<    UPDATE_REQUEST                  2
<       An Update request contains credit-control information for an
<       existing credit-control session.  Update credit-control requests
<       SHOULD be sent every time a credit-control re-authorization is
<       needed at the expiry of the allocated quota or validity time.
<       Further, additional service-specific events MAY trigger a
<       spontaneous Update request.
---
>    UPDATE_REQUEST 2
3240,3243c3233,3237
<    TERMINATION_REQUEST             3
<       A Termination request is sent to terminate a credit-control
<       session and contains credit-control information relevant to the
<       existing session.
---
>    An Update request contains credit-control information for an existing
>    credit-control session.  Update credit-control requests SHOULD be
>    sent every time a credit-control re-authorization is needed at the
>    expiry of the allocated quota or validity time.  Further, additional
>    service-specific events MAY trigger a spontaneous Update request.
3244a3239
>    TERMINATION_REQUEST 3
3245a3241,3243
>    A Termination request is sent to terminate a credit-control session
>    and contains credit-control information relevant to the existing
>    session.
3250c3248
< Hakala, et al.              Standards Track                    [Page 58]
---
> Bertz, et al.           Expires December 15, 2016              [Page 58]
3252c3250
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
3255,3262c3253,3261
<    EVENT_REQUEST                   4
<       An Event request is used when there is no need to maintain any
<       credit-control session state in the credit-control server.  This
<       request contains all information relevant to the service, and is
<       the only request of the service.  The reason for the Event request
<       is further detailed in the Requested-Action AVP.  The Requested-
<       Action AVP MUST be included in the Credit-Control-Request message
<       when CC-Request-Type is set to EVENT_REQUEST.
---
>    EVENT_REQUEST 4
> 
>    An Event request is used when there is no need to maintain any
>    credit-control session state in the credit-control server.  This
>    request contains all information relevant to the service, and is the
>    only request of the service.  The reason for the Event request is
>    further detailed in the Requested-Action AVP.  The Requested- Action
>    AVP MUST be included in the Credit-Control-Request message when CC-
>    Request-Type is set to EVENT_REQUEST.
3280,3294c3279,3294
<    FAILOVER_NOT_SUPPORTED          0
<       When the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED,
<       the credit-control message stream MUST NOT to be moved to an
<       alternative destination in the case of communication failure.
< 
<       This is the default behavior if the AVP isn't included in the
<       reply from the authorization or credit-control server.
< 
<    FAILOVER_SUPPORTED              1
<       When the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, the
<       credit-control message stream SHOULD be moved to an alternative
<       destination in the case of communication failure.  Moving the
<       credit-control message stream to a backup server MAY require that
<       information related to the credit-control session should also be
<       forwarded to alternative server.
---
>    FAILOVER_NOT_SUPPORTED 0
> 
>    When the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED,
>    the credit-control message stream MUST NOT to be moved to an
>    alternative destination in the case of communication failure.  This
>    is the default behavior if the AVP isn't included in the reply from
>    the authorization or credit-control server.
> 
>    FAILOVER_SUPPORTED 1
> 
>    When the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, the
>    credit-control message stream SHOULD be moved to an alternative
>    destination in the case of communication failure.  Moving the credit-
>    control message stream to a backup server MAY require that
>    information related to the credit-control session should also be
>    forwarded to alternative server.
3304,3306c3304
< 
< 
< Hakala, et al.              Standards Track                    [Page 59]
---
> Bertz, et al.           Expires December 15, 2016              [Page 59]
3308c3306
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
3320c3318,3319
<    Credit-Control-Request command.
---
>    Credit-Control-Request command.  The following values are defined for
>    the Check-Balance-Result AVP.
3322c3321
<    The following values are defined for the Check-Balance-Result AVP.
---
>    ENOUGH_CREDIT 0
3324,3326c3323
<    ENOUGH_CREDIT                   0
<       There is enough credit in the account to cover the requested
<       service.
---
>    There is enough credit in the account to cover the requested service.
3328,3330c3325,3328
<    NO_CREDIT                       1
<       There isn't enough credit in the account to cover the requested
<       service.
---
>    NO_CREDIT 1
> 
>    There isn't enough credit in the account to cover the requested
>    service.
3355a3354,3355
>    The Cost-Information AVP included in the Credit-Control-Answer
>    command with the CC-Request-Type set to EVENT_REQUEST or
3360,3362c3360
< 
< 
< Hakala, et al.              Standards Track                    [Page 60]
---
> Bertz, et al.           Expires December 15, 2016              [Page 60]
3364c3362
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
3367,3368d3364
<    The Cost-Information AVP included in the Credit-Control-Answer
<    command with the CC-Request-Type set to EVENT_REQUEST or
3372,3373c3368,3373
<    It is defined as follows (per the grouped-avp-def of
<    RFC 3588 [DIAMBASE]):
---
>    It is defined as follows (per the grouped-avp-def of [RFC6733]):
> 
>                    Cost-Information ::= < AVP Header: 423 >
>                                         { Unit-Value }
>                                         { Currency-Code }
>                                         [ Cost-Unit ]
3375,3378d3374
<                 Cost-Information ::= < AVP Header: 423 >
<                                      { Unit-Value }
<                                      { Currency-Code }
<                                      [ Cost-Unit ]
3390,3391c3386,3390
<    It is defined as follows (per the grouped-avp-def of
<    RFC 3588 [DIAMBASE]):
---
>    It is defined as follows (per the grouped-avp-def of [RFC6733]):
> 
>                        Unit-Value ::= < AVP Header: 445 >
>                                       { Value-Digits }
>                                       [ Exponent ]
3393,3395d3391
<                     Unit-Value ::= < AVP Header: 445 >
<                                    { Value-Digits }
<                                    [ Exponent ]
3400,3401c3396,3397
<    exponent value to be applied for the Value-Digit AVP within the
<    Unit-Value AVP.
---
>    exponent value to be applied for the Value-Digit AVP within the Unit-
>    Value AVP.
3411a3408
> 8.11.  Currency-Code AVP
3412a3410,3411
>    The Currency-Code AVP (AVP Code 425) is of type Unsigned32 and
>    contains a currency code that specifies in which currency the values
3417,3418c3416
< 
< Hakala, et al.              Standards Track                    [Page 61]
---
> Bertz, et al.           Expires December 15, 2016              [Page 61]
3420c3418
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
3423,3426d3420
< 8.11.  Currency-Code AVP
< 
<    The Currency-Code AVP (AVP Code 425) is of type Unsigned32 and
<    contains a currency code that specifies in which currency the values
3445,3461c3439,3457
<    CREDIT_AUTHORIZATION            0
<       If the home Diameter AAA server determines that the user has
<       prepaid subscription, this value indicates that the credit-control
<       server MUST be contacted to perform the first interrogation.  The
<       value of the Credit-Control AVP MUST always be set to 0 in an AA
<       request sent to perform the first interrogation and to initiate a
<       new credit-control session.
< 
<    RE_AUTHORIZATION                1
<       This value indicates to the Diameter AAA server that a credit-
<       control session is ongoing for the subscriber and that the
<       credit-control server MUST not be contacted.  The Credit-Control
<       AVP set to the value of 1 is to be used only when the first
<       interrogation has been successfully performed and the credit-
<       control session is ongoing (i.e., re-authorization triggered by
<       Authorization-Lifetime).  This value MUST NOT be used in an AA
<       request sent to perform the first interrogation.
---
>    CREDIT_AUTHORIZATION 0
> 
>    If the home Diameter AAA server determines that the user has prepaid
>    subscription, this value indicates that the credit-control server
>    MUST be contacted to perform the first interrogation.  The value of
>    the Credit-Control AVP MUST always be set to 0 in an AA request sent
>    to perform the first interrogation and to initiate a new credit-
>    control session.
> 
>    RE_AUTHORIZATION 1
> 
>    This value indicates to the Diameter AAA server that a credit-
>    control session is ongoing for the subscriber and that the credit-
>    control server MUST not be contacted.  The Credit-Control AVP set to
>    the value of 1 is to be used only when the first interrogation has
>    been successfully performed and the credit- control session is
>    ongoing (i.e., re-authorization triggered by Authorization-Lifetime).
>    This value MUST NOT be used in an AA request sent to perform the
>    first interrogation.
3470a3467,3468
>    immediately when there is a reason to believe that the service cannot
>    be charged, or to try failover to an alternative server, if possible.
3474c3472
< Hakala, et al.              Standards Track                    [Page 62]
---
> Bertz, et al.           Expires December 15, 2016              [Page 62]
3476c3474
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
3479,3480d3476
<    immediately when there is a reason to believe that the service cannot
<    be charged, or to try failover to an alternative server, if possible.
3484,3513c3480,3510
<    TERMINATE                       0
<       When the Credit-Control-Failure-Handling AVP is set to TERMINATE,
<       the service MUST only be granted for as long as there is a
<       connection to the credit-control server.  If the credit-control
<       client does not receive any Credit-Control-Answer message within
<       the Tx timer (as defined in section 13), the credit-control
<       request is regarded as failed, and the end user's service session
<       is terminated.
< 
<       This is the default behavior if the AVP isn't included in the
<       reply from the authorization or credit-control server.
< 
<    CONTINUE                       1
<       When the Credit-Control-Failure-Handling AVP is set to CONTINUE,
<       the credit-control client SHOULD re-send the request to an
<       alternative server in the case of transport or temporary failures,
<       provided that a failover procedure is supported in the credit-
<       control server and the credit-control client, and that an
<       alternative server is available.  Otherwise, the service SHOULD be
<       granted, even if credit-control messages can't be delivered.
< 
<    RETRY_AND_TERMINATE            2
<       When the Credit-Control-Failure-Handling AVP is set to
<       RETRY_AND_TERMINATE, the credit-control client SHOULD re-send the
<       request to an alternative server in the case of transport or
<       temporary failures, provided that a failover procedure is
<       supported in the credit-control server and the credit-control
<       client, and that an alternative server is available.  Otherwise,
<       the service SHOULD not be granted when the credit-control messages
<       can't be delivered.
---
>    TERMINATE 0
> 
>    When the Credit-Control-Failure-Handling AVP is set to TERMINATE, the
>    service MUST only be granted for as long as there is a connection to
>    the credit-control server.  If the credit-control client does not
>    receive any Credit-Control-Answer message within the Tx timer (as
>    defined in Section 13), the credit-control request is regarded as
>    failed, and the end user's service session is terminated.
> 
>    This is the default behavior if the AVP isn't included in the reply
>    from the authorization or credit-control server.
> 
>    CONTINUE 1
> 
>    When the Credit-Control-Failure-Handling AVP is set to CONTINUE, the
>    credit-control client SHOULD re-send the request to an alternative
>    server in the case of transport or temporary failures, provided that
>    a failover procedure is supported in the credit- control server and
>    the credit-control client, and that an alternative server is
>    available.  Otherwise, the service SHOULD be granted, even if credit-
>    control messages can't be delivered.
> 
>    RETRY_AND_TERMINATE 2
> 
>    When the Credit-Control-Failure-Handling AVP is set to
>    RETRY_AND_TERMINATE, the credit-control client SHOULD re-send the
>    request to an alternative server in the case of transport or
>    temporary failures, provided that a failover procedure is supported
>    in the credit-control server and the credit-control client, and that
>    an alternative server is available.  Otherwise, the service SHOULD
>    not be granted when the credit-control messages can't be delivered.
3523,3526c3520
<    TERMINATE_OR_BUFFER             0
<       When the Direct-Debiting-Failure-Handling AVP is set to
<       TERMINATE_OR_BUFFER, the service MUST be granted for as long as
<       there is a connection to the credit-control server.  If the
---
>    TERMINATE_OR_BUFFER 0
3527a3522,3524
>    When the Direct-Debiting-Failure-Handling AVP is set to
>    TERMINATE_OR_BUFFER, the service MUST be granted for as long as there
>    is a connection to the credit-control server.  If the credit-control
3530c3527,3528
< Hakala, et al.              Standards Track                    [Page 63]
---
> 
> Bertz, et al.           Expires December 15, 2016              [Page 63]
3532c3530
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
3535,3543c3533,3542
<       credit-control client does not receive any Credit-Control-Answer
<       message within the Tx timer (as defined in section 13) the
<       credit-control request is regarded as failed.  The client SHOULD
<       terminate the service if it can determine from the failed answer
<       that units have not been debited.  Otherwise the credit-control
<       client SHOULD grant the service, store the request in application
<       level non-volatile storage, and try to re-send the request.  These
<       requests MUST be marked as possible duplicates by setting the T-
<       flag in the command header as described in [DIAMBASE] section 3.
---
>    client does not receive any Credit-Control-Answer message within the
>    Tx timer (as defined in Section 13) the credit-control request is
>    regarded as failed.  The client SHOULD terminate the service if it
>    can determine from the failed answer that units have not been
>    debited.  Otherwise the credit-control client SHOULD grant the
>    service, store the request in application level non-volatile storage,
>    and try to re-send the request.  These requests MUST be marked as
>    possible duplicates by setting the T- flag in the command header as
>    described in [RFC6733] section 3.  This is the default behavior if
>    the AVP isn't included in the reply from the authorization server.
3545,3546c3544
<       This is the default behavior if the AVP isn't included in the
<       reply from the authorization server.
---
>    CONTINUE 1
3548,3551c3546,3548
<    CONTINUE                                              1
<       When the Direct-Debiting-Failure-Handling AVP is set to CONTINUE,
<       the service SHOULD be granted, even if credit-control messages
<       can't be delivered, and the request should be deleted.
---
>    When the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the
>    service SHOULD be granted, even if credit-control messages can't be
>    delivered, and the request should be deleted.
3586c3583,3584
< Hakala, et al.              Standards Track                    [Page 64]
---
> 
> Bertz, et al.           Expires December 15, 2016              [Page 64]
3588c3586
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
3602c3600
<    pools, the credit pooling mechanism defined in section 5.1.2 applies.
---
>    pools, the credit pooling mechanism defined in Section 5.1.2 applies.
3612c3610,3623
<    grouped-avp-def of RFC 3588 [DIAMBASE]):
---
>    grouped-avp-def of [RFC6733]):
> 
>          Multiple-Services-Credit-Control ::= < AVP Header: 456 >
>                                               [ Granted-Service-Unit ]
>                                               [ Requested-Service-Unit ]
>                                              *[ Used-Service-Unit ]
>                                               [ Tariff-Change-Usage ]
>                                              *[ Service-Identifier ]
>                                               [ Rating-Group ]
>                                              *[ G-S-U-Pool-Reference ]
>                                               [ Validity-Time ]
>                                               [ Result-Code ]
>                                               [ Final-Unit-Indication ]
>                                              *[ AVP ]
3614,3625d3624
<       Multiple-Services-Credit-Control ::= < AVP Header: 456 >
<                                            [ Granted-Service-Unit ]
<                                            [ Requested-Service-Unit ]
<                                           *[ Used-Service-Unit ]
<                                            [ Tariff-Change-Usage ]
<                                           *[ Service-Identifier ]
<                                            [ Rating-Group ]
<                                           *[ G-S-U-Pool-Reference ]
<                                            [ Validity-Time ]
<                                            [ Result-Code ]
<                                            [ Final-Unit-Indication ]
<                                           *[ AVP ]
3641,3642c3640
< 
< Hakala, et al.              Standards Track                    [Page 65]
---
> Bertz, et al.           Expires December 15, 2016              [Page 65]
3644c3642
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
3648c3646,3656
<    avp-def of RFC 3588 [DIAMBASE]):
---
>    avp-def of [RFC6733]):
> 
>          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 ]
>                                    *[ AVP ]
3650,3658d3657
<       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 ]
<                                 *[ AVP ]
3669c3668,3677
<    grouped-avp-def of RFC 3588 [DIAMBASE]):
---
>    grouped-avp-def of [RFC6733]):
> 
>          Requested-Service-Unit ::= < AVP Header: 437 >
>                                     [ CC-Time ]
>                                     [ CC-Money ]
>                                     [ CC-Total-Octets ]
>                                     [ CC-Input-Octets ]
>                                     [ CC-Output-Octets ]
>                                     [ CC-Service-Specific-Units ]
>                                    *[ AVP ]
3671,3678d3678
<       Requested-Service-Unit ::= < AVP Header: 437 >
<                                  [ CC-Time ]
<                                  [ CC-Money ]
<                                  [ CC-Total-Octets ]
<                                  [ CC-Input-Octets ]
<                                  [ CC-Output-Octets ]
<                                  [ CC-Service-Specific-Units ]
<                                 *[ AVP ]
3686a3687,3688
>    The Used-Service-Unit AVP is defined as follows (per the grouped-
>    avp-def of [RFC6733]):
3694,3698c3696
< 
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 66]
---
> Bertz, et al.           Expires December 15, 2016              [Page 66]
3700c3698
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
3703,3704c3701,3709
<    The Used-Service-Unit AVP is defined as follows (per the grouped-
<    avp-def of RFC 3588 [DIAMBASE]):
---
>          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 ]
>                               *[ AVP ]
3706,3714d3710
<       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 ]
<                            *[ AVP ]
3724c3720
<    and it is not used for time-based services defined in section 5.  If
---
>    and it is not used for time-based services defined in Section 5.  If
3743c3739
<    RFC 3588 [DIAMBASE]):
---
>    [RFC6733]):
3745,3747c3741,3743
<       CC-Money ::= < AVP Header: 413 >
<                    { Unit-Value }
<                    [ Currency-Code ]
---
>          CC-Money ::= < AVP Header: 413 >
>                       { Unit-Value }
>                       [ Currency-Code ]
3754c3750,3752
< Hakala, et al.              Standards Track                    [Page 67]
---
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 67]
3756c3754
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
3782,3784c3780,3782
<    specific units always refer to the service identified in the
<    Service-Identifier AVP (or Rating-Group AVP when the Multiple-
<    Services-Credit-Control AVP is used).
---
>    specific units always refer to the service identified in the Service-
>    Identifier AVP (or Rating-Group AVP when the Multiple- Services-
>    Credit-Control AVP is used).
3794,3796c3792,3794
<    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.
---
>    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.
3803,3806c3801,3803
<    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.
---
>    UNIT_BEFORE_TARIFF_CHANGE 0
> 
> 
3810c3807,3808
< Hakala, et al.              Standards Track                    [Page 68]
---
> 
> Bertz, et al.           Expires December 15, 2016              [Page 68]
3812c3810,3818
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
>    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.
3813a3820
>    UNIT_AFTER_TARIFF_CHANGE 1
3815,3817c3822,3824
<       When present in the Used-Service-Unit AVP, this value indicates
<       the amount of resource units used before a tariff change had
<       occurred.
---
>    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.
3819,3822c3826,3827
<    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.
3824,3826c3829
<       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
3828,3833c3831,3835
<    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.
---
>    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.
3858,3859d3859
<    Granted-Service-Unit AVP within which it appears with a credit pool
<    within the session.
3861,3862d3860
<    The G-S-U-Pool-Identifier AVP specifies the credit pool from which
<    credit is drawn for this unit type.
3866c3864
< Hakala, et al.              Standards Track                    [Page 69]
---
> Bertz, et al.           Expires December 15, 2016              [Page 69]
3868c3866,3870
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
>    Granted-Service-Unit AVP within which it appears with a credit pool
>    within the session.
3869a3872,3873
>    The G-S-U-Pool-Identifier AVP specifies the credit pool from which
>    credit is drawn for this unit type.
3880c3884,3889
<    avp-def of RFC 3588 [DIAMBASE]):
---
>    avp-def of [RFC6733]):
> 
>          G-S-U-Pool-Reference    ::= < AVP Header: 457 >
>                                      { G-S-U-Pool-Identifier }
>                                      { CC-Unit-Type }
>                                      { Unit-Value }
3882,3885d3890
<       G-S-U-Pool-Reference    ::= < AVP Header: 457 >
<                                   { G-S-U-Pool-Identifier }
<                                   { CC-Unit-Type }
<                                   { Unit-Value }
3900,3905c3905,3910
<       TIME                         0
<       MONEY                        1
<       TOTAL-OCTETS                 2
<       INPUT-OCTETS                 3
<       OUTPUT-OCTETS                4
<       SERVICE-SPECIFIC-UNITS       5
---
>          TIME                         0
>          MONEY                        1
>          TOTAL-OCTETS                 2
>          INPUT-OCTETS                 3
>          OUTPUT-OCTETS                4
>          SERVICE-SPECIFIC-UNITS       5
3911a3917,3924
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 70]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
3920,3926d3932
< 
< 
< Hakala, et al.              Standards Track                    [Page 70]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
3928c3934
<    termination (see section 5.6) to indicate to the credit-control
---
>    termination (see Section 5.6) to indicate to the credit-control
3941c3947
<    Final-Unit-Action AVP (see section 5.6).
---
>    Final-Unit-Action AVP (see Section 5.6).
3947,3951c3953,3957
<    In the first interrogation, the Final-Unit-Indication AVP with
<    Final-Unit-Action REDIRECT or RESTRICT_ACCESS can also be present
<    with no Granted-Service-Unit AVP in the Credit-Control-Answer or in
<    the AA answer.  This indicates to the Diameter credit-control client
<    to execute the specified action immediately.  If the home service
---
>    In the first interrogation, the Final-Unit-Indication AVP with Final-
>    Unit-Action REDIRECT or RESTRICT_ACCESS can also be present with no
>    Granted-Service-Unit AVP in the Credit-Control-Answer or in the AA
>    answer.  This indicates to the Diameter credit-control client to
>    execute the specified action immediately.  If the home service
3953c3959
<    SHOULD return the appropriate transient failure (see section 9.1) in
---
>    SHOULD return the appropriate transient failure (see Section 9.1) in
3967,3972d3972
<    message if the user is also allowed to access other services that are
<    not accessible through the address given in the Redirect-Server AVP.
< 
<    If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the
<    Restriction-Filter-Rule AVP or the Filter-Id AVP SHOULD be present.
< 
3975a3976,3978
> Bertz, et al.           Expires December 15, 2016              [Page 71]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
3978,3980c3981,3982
< Hakala, et al.              Standards Track                    [Page 71]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
---
>    message if the user is also allowed to access other services that are
>    not accessible through the address given in the Redirect-Server AVP.
3981a3984,3985
>    If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the
>    Restriction-Filter-Rule AVP or the Filter-Id AVP SHOULD be present.
3983c3987
<    The Filter-Id AVP is defined in [NASREQ].  The Filter-Id AVP can be
---
>    The Filter-Id AVP is defined in [RFC7155].  The Filter-Id AVP can be
3988,3989c3992,3999
<    The Final-Unit-Indication AVP is defined as follows (per the
<    grouped-avp-def of RFC 3588 [DIAMBASE]):
---
>    The Final-Unit-Indication AVP is defined as follows (per the grouped-
>    avp-def of [RFC6733]):
> 
>          Final-Unit-Indication ::= < AVP Header: 430 >
>                                    { Final-Unit-Action }
>                                   *[ Restriction-Filter-Rule ]
>                                   *[ Filter-Id ]
>                                    [ Redirect-Server ]
3991,3995d4000
<       Final-Unit-Indication ::= < AVP Header: 430 >
<                                 { Final-Unit-Action }
<                                *[ Restriction-Filter-Rule ]
<                                *[ Filter-Id ]
<                                 [ Redirect-Server ]
4005,4022c4010
<    TERMINATE                       0
<       The credit-control client MUST terminate the service session.
<       This is the default handling, applicable whenever the credit-
<       control client receives an unsupported Final-Unit-Action value,
<       and it MUST be supported by all the Diameter credit-control client
<       implementations conforming to this specification.
< 
<    REDIRECT                        1
<       The service element MUST redirect the user to the address
<       specified in the Redirect-Server-Address AVP.  The redirect action
<       is defined in section 5.6.2.
< 
<    RESTRICT_ACCESS                 2
<       The access device MUST restrict the user access according to the
<       IP packet filters defined in the Restriction-Filter-Rule AVP or
<       according to the IP packet filters identified by the Filter-Id
<       AVP.  All the packets not matching the filters MUST be dropped
<       (see section 5.6.3).
---
>    TERMINATE 0
4024c4012,4016
< 8.36.  Restriction-Filter-Rule AVP
---
>    The credit-control client MUST terminate the service session.  This
>    is the default handling, applicable whenever the credit- control
>    client receives an unsupported Final-Unit-Action value, and it MUST
>    be supported by all the Diameter credit-control client
>    implementations conforming to this specification.
4026,4029c4018,4024
<    The Restriction-Filter-Rule AVP (AVP Code 438) is of type
<    IPFilterRule and provides filter rules corresponding to services that
<    are to remain accessible even if there are no more service units
<    granted.  The access device has to configure the specified filter
---
>    REDIRECT 1
> 
>    The service element MUST redirect the user to the address specified
>    in the Redirect-Server-Address AVP.  The redirect action is defined
>    in Section 5.6.2.
> 
>    RESTRICT_ACCESS 2
4030a4026,4028
>    The access device MUST restrict the user access according to the IP
>    packet filters defined in the Restriction-Filter-Rule AVP or
>    according to the IP packet filters identified by the Filter-Id AVP.
4034c4032
< Hakala, et al.              Standards Track                    [Page 72]
---
> Bertz, et al.           Expires December 15, 2016              [Page 72]
4036c4034
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
4038a4037,4045
>    All the packets not matching the filters MUST be dropped (see
>    Section 5.6.3).
> 
> 8.36.  Restriction-Filter-Rule AVP
> 
>    The Restriction-Filter-Rule AVP (AVP Code 438) is of type
>    IPFilterRule and provides filter rules corresponding to services that
>    are to remain accessible even if there are no more service units
>    granted.  The access device has to configure the specified filter
4051,4052c4058,4062
<    It is defined as follows (per the grouped-avp-def of RFC 3588
<    [DIAMBASE]):
---
>    It is defined as follows (per the grouped-avp-def of [RFC6733]):
> 
>          Redirect-Server ::= < AVP Header: 434 >
>                              { Redirect-Address-Type }
>                              { Redirect-Server-Address }
4054,4056d4063
<       Redirect-Server ::= < AVP Header: 434 >
<                           { Redirect-Address-Type }
<                           { Redirect-Server-Address }
4066,4068c4073
<    IPv4 Address                    0
<       The address type is in the form of "dotted-decimal" IPv4 address,
<       as defined in [IPv4].
---
>    IPv4 Address 0
4070,4075c4075,4076
<    IPv6 Address                    1
<       The address type is in the form of IPv6 address, as defined in
<       [IPv6Addr].  The address is a text representation of the address
<       in either the preferred or alternate text form [IPv6Addr].
<       Conformant implementations MUST support the preferred form and
<       SHOULD support the alternate text form for IPv6 addresses.
---
>    The address type is in the form of "dotted-decimal" IPv4 address, as
>    defined in [RFC0791].
4077,4079c4078
<    URL                             2
<       The address type is in the form of Uniform Resource Locator, as
<       defined in [URL].
---
>    IPv6 Address 1
4081,4083c4080,4084
<    SIP URI                         3
<       The address type is in the form of SIP Uniform Resource
<       Identifier, as defined in [SIP].
---
>    The address type is in the form of IPv6 address, as defined in
>    [RFC3513].  The address is a text representation of the address in
>    either the preferred or alternate text form [RFC3513].  Conformant
>    implementations MUST support the preferred form and SHOULD support
>    the alternate text form for IPv6 addresses.
4086a4088,4090
> Bertz, et al.           Expires December 15, 2016              [Page 73]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
4088a4093
>    URL 2
4090,4092c4095,4096
< Hakala, et al.              Standards Track                    [Page 73]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
---
>    The address type is in the form of Uniform Resource Locator, as
>    defined in [RFC1738].
4093a4098,4101
>    SIP URI 3
> 
>    The address type is in the form of SIP Uniform Resource Identifier,
>    as defined in [RFC3261].
4118,4119d4125
<       Client does not support independent credit-control of multiple
<       services within a (sub-)session.
4121,4123c4127,4133
<    MULTIPLE_SERVICES_SUPPORTED     1
<       Client supports independent credit-control of multiple services
<       within a (sub-)session.
---
>    Client does not support independent credit-control of multiple
>    services within a (sub-)session.
> 
>    MULTIPLE_SERVICES_SUPPORTED 1
> 
>    Client supports independent credit-control of multiple services
>    within a (sub-)session.
4132,4138d4141
<    DIRECT_DEBITING                 0
<       This indicates a request to decrease the end user's account
<       according to information specified in the Requested-Service-Unit
<       AVP and/or Service-Identifier AVP (additional rating information
<       may be included in service-specific AVPs or in the Service-
<       Parameter-Info AVP).  The Granted-Service-Unit AVP in the Credit-
<       Control-Answer command contains the debited units.
4140a4144,4146
> Bertz, et al.           Expires December 15, 2016              [Page 74]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
4142a4149
>    DIRECT_DEBITING 0
4143a4151,4156
>    This indicates a request to decrease the end user's account according
>    to information specified in the Requested-Service-Unit AVP and/or
>    Service-Identifier AVP (additional rating information may be included
>    in service-specific AVPs or in the Service- Parameter-Info AVP).  The
>    Granted-Service-Unit AVP in the Credit- Control-Answer command
>    contains the debited units.
4144a4158
>    REFUND_ACCOUNT 1
4146,4148c4160,4165
< Hakala, et al.              Standards Track                    [Page 74]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
---
>    This indicates a request to increase the end user's account according
>    to information specified in the Requested-Service-Unit AVP and/or
>    Service-Identifier AVP (additional rating information may be included
>    in service-specific AVPs or in the Service- Parameter-Info AVP).  The
>    Granted-Service-Unit AVP in the Credit- Control-Answer command
>    contains the refunded units.
4149a4167
>    CHECK_BALANCE 2
4151,4157c4169,4172
<    REFUND_ACCOUNT                  1
<       This indicates a request to increase the end user's account
<       according to information specified in the Requested-Service-Unit
<       AVP and/or Service-Identifier AVP (additional rating information
<       may be included in service-specific AVPs or in the Service-
<       Parameter-Info AVP).  The Granted-Service-Unit AVP in the Credit-
<       Control-Answer command contains the refunded units.
---
>    This indicates a balance check request.  In this case, the checking
>    of the account balance is done without any credit reservation from
>    the account.  The Check-Balance-Result AVP in the Credit-Control-
>    Answer command contains the result of the balance check.
4159,4164c4174
<    CHECK_BALANCE                   2
<       This indicates a balance check request.  In this case, the
<       checking of the account balance is done without any credit
<       reservation from the account.  The Check-Balance-Result AVP in the
<       Credit-Control-Answer command contains the result of the balance
<       check.
---
>    PRICE_ENQUIRY 3
4166,4170c4176,4179
<    PRICE_ENQUIRY                   3
<       This indicates a price enquiry request.  In this case, neither
<       checking of the account balance nor reservation from the account
<       will be done; only the price of the service will be returned in
<       the Cost-Information AVP in the Credit-Control-Answer Command.
---
>    This indicates a price enquiry request.  In this case, neither
>    checking of the account balance nor reservation from the account will
>    be done; only the price of the service will be returned in the Cost-
>    Information AVP in the Credit-Control-Answer Command.
4187a4197,4204
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 75]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
4198,4206d4214
< 
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 75]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
4231,4232c4239,4243
<    It is defined as follows (per the grouped-avp-def of RFC 3588
<    [DIAMBASE]):
---
>    It is defined as follows (per the grouped-avp-def of [RFC6733]):
> 
>          Service-Parameter-Info ::= < AVP Header: 440 >
>                                     { Service-Parameter-Type }
>                                     { Service-Parameter-Value }
4234,4236d4244
<       Service-Parameter-Info ::= < AVP Header: 440 >
<                                  { Service-Parameter-Type }
<                                  { Service-Parameter-Value }
4245,4251d4252
<    the Service-Context-Id (i.e., unique identifier of a service-specific
<    document) is also responsible for assigning Service-Parameter-Type
<    values for the service and ensuring their uniqueness within the given
<    service.  The Service-Parameter-Value AVP contains the value
<    associated with the service parameter type.
< 
< 
4255,4258c4256
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 76]
---
> Bertz, et al.           Expires December 15, 2016              [Page 76]
4260c4258,4259
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
4261a4261,4265
>    the Service-Context-Id (i.e., unique identifier of a service-specific
>    document) is also responsible for assigning Service-Parameter-Type
>    values for the service and ensuring their uniqueness within the given
>    service.  The Service-Parameter-Value AVP contains the value
>    associated with the service parameter type.
4275,4276c4279,4283
<    It is defined as follows (per the grouped-avp-def of RFC 3588
<    [DIAMBASE]):
---
>    It is defined as follows (per the grouped-avp-def of [RFC6733]):
> 
>          Subscription-Id ::= < AVP Header: 443 >
>                              { Subscription-Id-Type }
>                              { Subscription-Id-Data }
4278,4280d4284
<       Subscription-Id ::= < AVP Header: 443 >
<                           { Subscription-Id-Type }
<                           { Subscription-Id-Data }
4290c4294
<    designated expert, as defined in section 12.  A server MUST implement
---
>    designated expert, as defined in Section 12.  A server MUST implement
4294c4298
<    according to the 'M' flag rule, as defined in [DIAMBASE].
---
>    according to the 'M' flag rule, as defined in [RFC6733].
4296,4299c4300
<    END_USER_E164                   0
<       The identifier is in international E.164 format (e.g., MSISDN),
<       according to the ITU-T E.164 numbering plan defined in [E164] and
<       [CE164].
---
>    END_USER_E164 0
4301,4303c4302,4304
<    END_USER_IMSI                   1
<       The identifier is in international IMSI format, according to the
<       ITU-T E.212 numbering plan as defined in [E212] and [CE212].
---
>    The identifier is in international E.164 format (e.g., MSISDN),
>    according to the ITU-T E.164 numbering plan defined in [E164] and
>    [CE164].
4305,4306c4306
<    END_USER_SIP_URI                2
<       The identifier is in the form of a SIP URI, as defined in [SIP].
---
>    END_USER_IMSI 1
4308,4310d4307
<    END_USER_NAI                    3
<       The identifier is in the form of a Network Access Identifier, as
<       defined in [NAI].
4314c4311,4312
< Hakala, et al.              Standards Track                    [Page 77]
---
> 
> Bertz, et al.           Expires December 15, 2016              [Page 77]
4316c4314,4324
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
>    The identifier is in international IMSI format, according to the
>    ITU-T E.212 numbering plan as defined in [E212] and [CE212].
> 
>    END_USER_SIP_URI 2
> 
>    The identifier is in the form of a SIP URI, as defined in [RFC3261].
> 
>    END_USER_NAI 3
4317a4326,4327
>    The identifier is in the form of a Network Access Identifier, as
>    defined in [RFC2486].
4319,4320c4329,4331
<    END_USER_PRIVATE                4
<       The Identifier is a credit-control server private identifier.
---
>    END_USER_PRIVATE 4
> 
>    The Identifier is a credit-control server private identifier.
4335,4336c4346,4350
<    It is defined as follows (per the grouped-avp-def of RFC 3588
<    [DIAMBASE]):
---
>    It is defined as follows (per the grouped-avp-def of [RFC6733]):
> 
>          User-Equipment-Info ::= < AVP Header: 458 >
>                                  { User-Equipment-Info-Type }
>                                  { User-Equipment-Info-Value }
4338,4340d4351
<       User-Equipment-Info ::= < AVP Header: 458 >
<                               { User-Equipment-Info-Type }
<                               { User-Equipment-Info-Value }
4344,4346c4355,4357
<    The User-Equipment-Info-Type AVP is of type Enumerated  (AVP Code
<    459) and defines the type of user equipment information contained in
<    the User-Equipment-Info-Value AVP.
---
>    The User-Equipment-Info-Type AVP is of type Enumerated (AVP Code 459)
>    and defines the type of user equipment information contained in the
>    User-Equipment-Info-Value AVP.
4350c4361
<    IANA designated expert, as defined in section 12.
---
>    IANA designated expert, as defined in Section 12.
4352,4355c4363
<    IMEISV                          0
<       The identifier contains the International Mobile Equipment
<       Identifier and Software Version in the international IMEISV format
<       according to 3GPP TS 23.003 [3GPPIMEI].
---
>    IMEISV 0
4357,4358d4364
<    MAC                             1
<       The 48-bit MAC address is formatted as described in [RAD802.1X].
4360,4362d4365
<    EUI64                           2
<       The 64-bit identifier used to identify hardware instance of the
<       product, as defined in [EUI64].
4364a4368,4370
> Bertz, et al.           Expires December 15, 2016              [Page 78]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
4366a4373,4375
>    The identifier contains the International Mobile Equipment Identifier
>    and Software Version in the international IMEISV format according to
>    3GPP TS 23.003 [TGPPIMEI].
4367a4377
>    MAC 1
4368a4379
>    The 48-bit MAC address is formatted as described in [RFC3580].
4370,4372c4381
< Hakala, et al.              Standards Track                    [Page 78]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
---
>    EUI64 2
4373a4383,4384
>    The 64-bit identifier used to identify hardware instance of the
>    product, as defined in [EUI64].
4375,4380c4386,4392
<    MODIFIED_EUI64                  3
<       There are a number of types of terminals that have identifiers
<       other than IMEI, IEEE 802 MACs, or EUI-64.  These identifiers can
<       be converted to modified EUI-64 format as described in [IPv6Addr]
<       or by using some other methods referred to in the service-specific
<       documentation.
---
>    MODIFIED_EUI64 3
> 
>    There are a number of types of terminals that have identifiers other
>    than IMEI, IEEE 802 MACs, or EUI-64.  These identifiers can be
>    converted to modified EUI-64 format as described in [RFC3513] or by
>    using some other methods referred to in the service-specific
>    documentation.
4390c4402
<    This section defines new Result-Code AVP [DIAMBASE] values that must
---
>    This section defines new Result-Code AVP [RFC6733] values that must
4406,4409c4418
<    DIAMETER_END_USER_SERVICE_DENIED           4010
<       The credit-control server denies the service request due to
<       service restrictions.  If the CCR contained used-service-units,
<       they are deducted, if possible.
---
>    DIAMETER_END_USER_SERVICE_DENIED 4010
4411,4414d4419
<    DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE     4011
<       The credit-control server determines that the service can be
<       granted to the end user but that no further credit-control is
<       needed for the service (e.g., service is free of charge).
4416,4419d4420
<    DIAMETER_CREDIT_LIMIT_REACHED              4012
<       The credit-control server denies the service request because the
<       end user's account could not cover the requested service.  If the
<       CCR contained used-service-units they are deducted, if possible.
4422a4424,4426
> Bertz, et al.           Expires December 15, 2016              [Page 79]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
4424a4429,4431
>    The credit-control server denies the service request due to service
>    restrictions.  If the CCR contained used-service-units, they are
>    deducted, if possible.
4426,4428c4433
< Hakala, et al.              Standards Track                    [Page 79]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
---
>    DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011
4429a4435,4437
>    The credit-control server determines that the service can be granted
>    to the end user but that no further credit-control is needed for the
>    service (e.g., service is free of charge).
4431c4439,4445
< 9.2.  Permanent Failures
---
>    DIAMETER_CREDIT_LIMIT_REACHED 4012
> 
>    The credit-control server denies the service request because the end
>    user's account could not cover the requested service.  If the CCR
>    contained used-service-units they are deducted, if possible.
> 
> 9.2.  Permanent Failures
4437,4438c4451,4453
<    DIAMETER_USER_UNKNOWN                      5030
<       The specified end user is unknown in the credit-control server.
---
>    DIAMETER_USER_UNKNOWN 5030
> 
>    The specified end user is unknown in the credit-control server.
4440,4449c4455,4465
<    DIAMETER_RATING_FAILED                     5031
<       This error code is used to inform the credit-control client that
<       the credit-control server cannot rate the service request due to
<       insufficient rating input, an incorrect AVP combination, or an AVP
<       or an AVP value that is not recognized or supported in the rating.
<       The Failed-AVP AVP MUST be included and contain a copy of the
<       entire AVP(s) that could not be processed successfully or an
<       example of the missing AVP complete with the Vendor-Id if
<       applicable.  The value field of the missing AVP should be of
<       correct minimum length and contain zeros.
---
>    DIAMETER_RATING_FAILED 5031
> 
>    This error code is used to inform the credit-control client that the
>    credit-control server cannot rate the service request due to
>    insufficient rating input, an incorrect AVP combination, or an AVP or
>    an AVP value that is not recognized or supported in the rating.  The
>    Failed-AVP AVP MUST be included and contain a copy of the entire
>    AVP(s) that could not be processed successfully or an example of the
>    missing AVP complete with the Vendor-Id if applicable.  The value
>    field of the missing AVP should be of correct minimum length and
>    contain zeros.
4460,4477d4475
<       0     The AVP MUST NOT be present in the message.
<       0+    Zero or more instances of the AVP MAY be present in the
<             message.
<       0-1   Zero or one instance of the AVP MAY be present in the
<             message.  It is considered an error if there is more
<             than one instance of the AVP.
<       1     One instance of the AVP MUST be present in the message.
<       1+    At least one instance of the AVP MUST be present in the
<             message.
< 
< 
< 
< 
< 
< 
< 
< 
< 
4482c4480
< Hakala, et al.              Standards Track                    [Page 80]
---
> Bertz, et al.           Expires December 15, 2016              [Page 80]
4484c4482
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
4486a4485,4494
>          0     The AVP MUST NOT be present in the message.
>          0+    Zero or more instances of the AVP MAY be present in the
>                message.
>          0-1   Zero or one instance of the AVP MAY be present in the
>                message.  It is considered an error if there is more
>                than one instance of the AVP.
>          1     One instance of the AVP MUST be present in the message.
>          1+    At least one instance of the AVP MUST be present in the
>                message.
> 
4493,4534c4501,4532
<                                        +-----------+
<                                        |  Command  |
<                                        |   Code    |
<                                        |-----+-----+
<          Attribute Name                | CCR | CCA |
<          ------------------------------|-----+-----+
<          Acct-Multi-Session-Id         | 0-1 | 0-1 |
<          Auth-Application-Id           | 1   | 1   |
<          CC-Correlation-Id             | 0-1 | 0   |
<          CC-Session-Failover           | 0   | 0-1 |
<          CC-Request-Number             | 1   | 1   |
<          CC-Request-Type               | 1   | 1   |
<          CC-Sub-Session-Id             | 0-1 | 0-1 |
<          Check-Balance-Result          | 0   | 0-1 |
<          Cost-Information              | 0   | 0-1 |
<          Credit-Control-Failure-       | 0   | 0-1 |
<             Handling                   |     |     |
<          Destination-Host              | 0-1 | 0   |
<          Destination-Realm             | 1   | 0   |
<          Direct-Debiting-Failure-      | 0   | 0-1 |
<             Handling                   |     |     |
<          Event-Timestamp               | 0-1 | 0-1 |
<          Failed-AVP                    | 0   | 0+  |
<          Final-Unit-Indication         | 0   | 0-1 |
<          Granted-Service-Unit          | 0   | 0-1 |
<          Multiple-Services-Credit-     | 0+  | 0+  |
<             Control                    |     |     |
<          Multiple-Services-Indicator   | 0-1 | 0   |
<          Origin-Host                   | 1   | 1   |
<          Origin-Realm                  | 1   | 1   |
<          Origin-State-Id               | 0-1 | 0-1 |
<          Proxy-Info                    | 0+  | 0+  |
<          Redirect-Host                 | 0   | 0+  |
<          Redirect-Host-Usage           | 0   | 0-1 |
<          Redirect-Max-Cache-Time       | 0   | 0-1 |
<          Requested-Action              | 0-1 | 0   |
<          Requested-Service-Unit        | 0-1 | 0   |
<          Route-Record                  | 0+  | 0+  |
<          Result-Code                   | 0   | 1   |
<          Service-Context-Id            | 1   | 0   |
<          Service-Identifier            | 0-1 | 0   |
<          Service-Parameter-Info        | 0+  | 0   |
---
>                                           +-----------+
>                                           |  Command  |
>                                           |   Code    |
>                                           |-----+-----+
>             Attribute Name                | CCR | CCA |
>             ------------------------------|-----+-----+
>             Acct-Multi-Session-Id         | 0-1 | 0-1 |
>             Auth-Application-Id           | 1   | 1   |
>             CC-Correlation-Id             | 0-1 | 0   |
>             CC-Session-Failover           | 0   | 0-1 |
>             CC-Request-Number             | 1   | 1   |
>             CC-Request-Type               | 1   | 1   |
>             CC-Sub-Session-Id             | 0-1 | 0-1 |
>             Check-Balance-Result          | 0   | 0-1 |
>             Cost-Information              | 0   | 0-1 |
>             Credit-Control-Failure-       | 0   | 0-1 |
>                Handling                   |     |     |
>             Destination-Host              | 0-1 | 0   |
>             Destination-Realm             | 1   | 0   |
>             Direct-Debiting-Failure-      | 0   | 0-1 |
>                Handling                   |     |     |
>             Event-Timestamp               | 0-1 | 0-1 |
>             Failed-AVP                    | 0   | 0+  |
>             Final-Unit-Indication         | 0   | 0-1 |
>             Granted-Service-Unit          | 0   | 0-1 |
>             Multiple-Services-Credit-     | 0+  | 0+  |
>                Control                    |     |     |
>             Multiple-Services-Indicator   | 0-1 | 0   |
>             Origin-Host                   | 1   | 1   |
>             Origin-Realm                  | 1   | 1   |
>             Origin-State-Id               | 0-1 | 0-1 |
>             Proxy-Info                    | 0+  | 0+  |
4538,4550c4536,4558
< Hakala, et al.              Standards Track                    [Page 81]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
<          Session-Id                    | 1   | 1   |
<          Subscription-Id               | 0+  | 0   |
<          Termination-Cause             | 0-1 | 0   |
<          User-Equipment-Info           | 0-1 | 0   |
<          Used-Service-Unit             | 0+  | 0   |
<          User-Name                     | 0-1 | 0-1 |
<          Validity-Time                 | 0   | 0-1 |
<          ------------------------------|-----+-----+
---
> Bertz, et al.           Expires December 15, 2016              [Page 81]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
>             Redirect-Host                 | 0   | 0+  |
>             Redirect-Host-Usage           | 0   | 0-1 |
>             Redirect-Max-Cache-Time       | 0   | 0-1 |
>             Requested-Action              | 0-1 | 0   |
>             Requested-Service-Unit        | 0-1 | 0   |
>             Route-Record                  | 0+  | 0+  |
>             Result-Code                   | 0   | 1   |
>             Service-Context-Id            | 1   | 0   |
>             Service-Identifier            | 0-1 | 0   |
>             Service-Parameter-Info        | 0+  | 0   |
>             Session-Id                    | 1   | 1   |
>             Subscription-Id               | 0+  | 0   |
>             Termination-Cause             | 0-1 | 0   |
>             User-Equipment-Info           | 0-1 | 0   |
>             Used-Service-Unit             | 0+  | 0   |
>             User-Name                     | 0-1 | 0-1 |
>             Validity-Time                 | 0   | 0-1 |
>             ------------------------------|-----+-----+
4556c4564
<    Auth-Request/Answer (RAR/RAA) message [DIAMBASE].
---
>    Auth-Request/Answer (RAR/RAA) message [RFC6733].
4561,4570c4569,4578
<                                        +---------------+
<                                        | 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  |
<          ------------------------------+-------+-------+
---
>                                           +---------------+
>                                           | 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  |
>             ------------------------------+-------+-------+
4579a4588,4596
> 
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 82]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
4591,4599c4608
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 82]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
<    illustrated in Figure 7, and interworking flow in Figure 8.  In a
---
>    illustrated Figure 8, and interworking flow in Figure 9.  In a
4620,4622c4629,4631
<         Figure 7: Credit-control architecture with service element
<                   containing translation agent, translating RADIUS
<                   prepaid to Diameter credit-control protocol
---
>    Figure 8: Credit-control architecture with service element containing
>      translation agent, translating RADIUS prepaid to Diameter credit-
>                              control protocol
4635a4645,4652
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 83]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
4647,4654d4663
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 83]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
4664a4674,4675
>    A following diagram illustrates a RADIUS prepaid - Diameter credit-
>    control interworking sequence.
4693,4706c4704
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 84]
---
> Bertz, et al.           Expires December 15, 2016              [Page 84]
4708c4706
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
4711,4747c4709,4742
<    A following diagram illustrates a RADIUS prepaid - Diameter credit-
<    control interworking sequence.
< 
<       Service Element         Translation Agent
<         (e.g., NAS)               (CC Client)             CC Server
<             |     Access-Request     |                        |
<             |----------------------->|                        |
<             |                        |    CCR (initial)       |
<             |                        |----------------------->|
<             |                        |    CCA (Granted-Units) |
<             |                        |<-----------------------|
<             |     Access-Accept      |                        |
<             |     (Granted-Units)    |                        |
<             |<-----------------------|                        |
<             :                        :                        :
<             |     Access-Request     |                        |
<             |     (Used-Units)       |                        |
<             |----------------------->|                        |
<             |                        |    CCR (update,        |
<             |                        |         Used-Units)    |
<             |                        |----------------------->|
<             |                        |    CCA (Granted-Units) |
<             |                        |<-----------------------|
<             |     Access-Accept      |                        |
<             |     (Granted-Units)    |                        |
<             |<-----------------------|                        |
<             :                        :                        :
<             |     Access-Request     |                        |
<             |----------------------->|                        |
<             |                        |     CCR (terminate,    |
<             |                        |          Used-Units)   |
<             |                        |----------------------->|
<             |                        |     CCA                |
<             |                        |<-----------------------|
<             |     Access-Accept      |                        |
<             |<-----------------------|                        |
<             |                        |                        |
---
>    Service Element         Translation Agent
>      (e.g., NAS)               (CC Client)             CC Server
>          |     Access-Request     |                        |
>          |----------------------->|                        |
>          |                        |    CCR (initial)       |
>          |                        |----------------------->|
>          |                        |    CCA (Granted-Units) |
>          |                        |<-----------------------|
>          |     Access-Accept      |                        |
>          |     (Granted-Units)    |                        |
>          |<-----------------------|                        |
>          :                        :                        :
>          |     Access-Request     |                        |
>          |     (Used-Units)       |                        |
>          |----------------------->|                        |
>          |                        |    CCR (update,        |
>          |                        |         Used-Units)    |
>          |                        |----------------------->|
>          |                        |    CCA (Granted-Units) |
>          |                        |<-----------------------|
>          |     Access-Accept      |                        |
>          |     (Granted-Units)    |                        |
>          |<-----------------------|                        |
>          :                        :                        :
>          |     Access-Request     |                        |
>          |----------------------->|                        |
>          |                        |     CCR (terminate,    |
>          |                        |          Used-Units)   |
>          |                        |----------------------->|
>          |                        |     CCA                |
>          |                        |<-----------------------|
>          |     Access-Accept      |                        |
>          |<-----------------------|                        |
>          |                        |                        |
4749,4750c4744,4745
<            Figure 8: Message flow example with RADIUS prepaid -
<                   Diameter credit-control interworking
---
>    Figure 9: Message flow example with RADIUS prepaid - Diameter credit-
>                            control interworking
4757a4753,4756
>    In the subsections below, when we speak about review by a Designated
>    Expert, please note that the designated expert will be assigned by
>    the IESG.  Initially, such Expert discussions take place on the AAA
>    WG mailing list.
4761,4762c4760
< 
< Hakala, et al.              Standards Track                    [Page 85]
---
> Bertz, et al.           Expires December 15, 2016              [Page 85]
4764c4762
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
4767,4771d4764
<    In the subsections below, when we speak about review by a Designated
<    Expert, please note that the designated expert will be assigned by
<    the IESG.  Initially, such Expert discussions take place on the AAA
<    WG mailing list.
< 
4775,4776c4768,4769
<    the Application Identifier namespace defined in [DIAMBASE].  See
<    section 1.3 for more information.
---
>    the Application Identifier namespace defined in [RFC6733].  See
>    Section 1.3 for more information.
4781,4782c4774,4775
<    defined in [DIAMBASE] for the Credit-Control-Request (CCR) and
<    Credit-Control-Answer (CCA) commands.
---
>    defined in [RFC6733] for the Credit-Control-Request (CCR) and Credit-
>    Control-Answer (CCA) commands.
4787c4780
<    namespace defined in [DIAMBASE].  See section 8 for the assignment of
---
>    namespace defined in [RFC6733].  See Section 8 for the assignment of
4793,4794c4786,4787
<    from the Result-Code AVP value namespace defined in [DIAMBASE].  See
<    section 9 for the assignment of the namespace in this specification.
---
>    from the Result-Code AVP value namespace defined in [RFC6733].  See
>    Section 9 for the assignment of the namespace in this specification.
4798c4791
<    As defined in section 8.3, the CC-Request-Type AVP includes
---
>    As defined in Section 8.3, the CC-Request-Type AVP includes
4801c4794
<    assignment by a Designated Expert [IANA].
---
>    assignment by a Designated Expert [RFC2434].
4805c4798
<    As defined in section 8.4, the CC-Failover-Supported AVP includes
---
>    As defined in Section 8.4, the CC-Failover-Supported AVP includes
4808c4801
<    assignment by a Designated Expert [IANA].
---
>    assignment by a Designated Expert [RFC2434].
4809a4803
> 12.7.  CC-Unit-Type AVP
4810a4805,4808
>    As defined in Section 8.32, the CC-Unit-Type AVP includes Enumerated
>    type values 0 - 5.  IANA has created and is maintaining a namespace
>    for this AVP.  All remaining values are available for assignment by a
>    Designated Expert [RFC2434].
4818c4816
< Hakala, et al.              Standards Track                    [Page 86]
---
> Bertz, et al.           Expires December 15, 2016              [Page 86]
4820,4821c4818
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
4823,4828d4819
< 12.7.  CC-Unit-Type AVP
< 
<    As defined in section 8.32, the CC-Unit-Type AVP includes Enumerated
<    type values 0 - 5.  IANA has created and is maintaining a namespace
<    for this AVP.  All remaining values are available for assignment by a
<    Designated Expert [IANA].
4832c4823
<    As defined in section 8.6, the Check-Balance-Result AVP includes
---
>    As defined in Section 8.6, the Check-Balance-Result AVP includes
4835c4826
<    assignment by a Designated Expert [IANA].
---
>    assignment by a Designated Expert [RFC2434].
4839c4830
<    As defined in section 8.13, the Credit-Control AVP includes
---
>    As defined in Section 8.13, the Credit-Control AVP includes
4842c4833
<    assignment by a Designated Expert [IANA].
---
>    assignment by a Designated Expert [RFC2434].
4846c4837
<    As defined in section 8.14, the Credit-Control-Failure-Handling AVP
---
>    As defined in Section 8.14, the Credit-Control-Failure-Handling AVP
4849c4840
<    available for assignment by a Designated Expert [IANA].
---
>    available for assignment by a Designated Expert [RFC2434].
4853c4844
<    As defined in section 8.15, the Direct-Debiting-Failure-Handling AVP
---
>    As defined in Section 8.15, the Direct-Debiting-Failure-Handling AVP
4856c4847
<    available for assignment by a Designated Expert [IANA].
---
>    available for assignment by a Designated Expert [RFC2434].
4860c4851
<    As defined in section 8.35, the Final-Unit-Action AVP includes
---
>    As defined in Section 8.35, the Final-Unit-Action AVP includes
4863c4854
<    assignment by a Designated Expert [IANA].
---
>    assignment by a Designated Expert [RFC2434].
4867c4858
<    As defined in section 8.40, the Multiple-Services-Indicator AVP
---
>    As defined in Section 8.40, the Multiple-Services-Indicator AVP
4870c4861
<    available for assignment by a Designated Expert [IANA].
---
>    available for assignment by a Designated Expert [RFC2434].
4871a4863
> 12.14.  Redirect-Address-Type AVP
4872a4865,4868
>    As defined in Section 8.38, the Redirect-Address-Type AVP includes
>    Enumerated type values 0 - 3.  IANA has created and is maintaining a
>    namespace for this AVP.  All remaining values are available for
>    assignment by a Designated Expert [RFC2434].
4874,4876d4869
< Hakala, et al.              Standards Track                    [Page 87]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
4879c4872,4874
< 12.14.  Redirect-Address-Type AVP
---
> Bertz, et al.           Expires December 15, 2016              [Page 87]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
4881,4884d4875
<    As defined in section 8.38, the Redirect-Address-Type AVP includes
<    Enumerated type values 0 - 3.  IANA has created and is maintaining a
<    namespace for this AVP.  All remaining values are available for
<    assignment by a Designated Expert [IANA].
4888c4879
<    As defined in section 8.41, the Requested-Action AVP includes
---
>    As defined in Section 8.41, the Requested-Action AVP includes
4891c4882
<    assignment by a Designated Expert [IANA].
---
>    assignment by a Designated Expert [RFC2434].
4895c4886
<    As defined in section 8.47, the Subscription-Id-Type AVP  includes
---
>    As defined in Section 8.47, the Subscription-Id-Type AVP includes
4898c4889
<    assignment by a Designated Expert [IANA].
---
>    assignment by a Designated Expert [RFC2434].
4900c4891
< 12.17.   Tariff-Change-Usage AVP
---
> 12.17.  Tariff-Change-Usage AVP
4902c4893
<    As defined in section 8.27, the Tariff-Change-Usage AVP includes
---
>    As defined in Section 8.27, the Tariff-Change-Usage AVP includes
4905c4896
<    assignment by a Designated Expert [IANA].
---
>    assignment by a Designated Expert [RFC2434].
4907c4898
< 12.18.   User-Equipment-Info-Type AVP
---
> 12.18.  User-Equipment-Info-Type AVP
4909c4900
<    As defined in section 8.50, the User-Equipment-Info-Type AVP includes
---
>    As defined in Section 8.50, the User-Equipment-Info-Type AVP includes
4912c4903
<    assignment by a Designated Expert [IANA].
---
>    assignment by a Designated Expert [RFC2434].
4918,4926c4909,4917
<       When real-time credit-control is required, the credit-control
<       client contacts the credit-control server before and while the
<       service is provided to an end user.  Due to the real-time nature
<       of the application, the communication delays SHOULD be minimized;
<       e.g., to avoid an overly long service setup time experienced by
<       the end user.  The Tx timer is introduced to control the waiting
<       time in the client in the Pending state.  When the Tx timer
<       elapses, the credit-control client takes an action to the end user
<       according to the value of the Credit-Control-Failure-Handling AVP
---
>    When real-time credit-control is required, the credit-control client
>    contacts the credit-control server before and while the service is
>    provided to an end user.  Due to the real-time nature of the
>    application, the communication delays SHOULD be minimized; e.g., to
>    avoid an overly long service setup time experienced by the end user.
>    The Tx timer is introduced to control the waiting time in the client
>    in the Pending state.  When the Tx timer elapses, the credit-control
>    client takes an action to the end user according to the value of the
>    Credit-Control-Failure-Handling AVP
4927a4919,4920
>    or Direct-Debiting-Failure-Handling AVP.  The recommended value is 10
>    seconds.
4928a4922
>    Tcc timer
4930,4932d4923
< Hakala, et al.              Standards Track                    [Page 88]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
4935,4936d4925
<       or Direct-Debiting-Failure-Handling AVP.  The recommended value is
<       10 seconds.
4938d4926
<    Tcc timer
4940,4945c4928,4938
<       The Tcc timer supervises an ongoing credit-control session in the
<       credit-control server.  It is RECOMMENDED to use the Validity-Time
<       as input to set the Tcc timer value.  In case of transient
<       failures in the network, the Diameter credit-control server might
<       change to Idle state.  To avoid this, the Tcc timer MAY be set so
<       that Tcc equals to 2 x Validity-Time.
---
> Bertz, et al.           Expires December 15, 2016              [Page 88]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
>    The Tcc timer supervises an ongoing credit-control session in the
>    credit-control server.  It is RECOMMENDED to use the Validity-Time as
>    input to set the Tcc timer value.  In case of transient failures in
>    the network, the Diameter credit-control server might change to Idle
>    state.  To avoid this, the Tcc timer MAY be set so that Tcc equals to
>    2 x Validity-Time.
4949,4952c4942,4945
<       Client implementations may offer the possibility of locally
<       configuring these AVPs.  In such a case their value and behavior
<       is defined in section 5.7 for the Credit-Control-Failure-Handling
<       and in section 6.5 for the Direct-Debiting-Failure-Handling.
---
>    Client implementations may offer the possibility of locally
>    configuring these AVPs.  In such a case their value and behavior is
>    defined in Section 5.7 for the Credit-Control-Failure-Handling and in
>    Section 6.5 for the Direct-Debiting-Failure-Handling.
4956,4970c4949,4964
<    The Diameter base protocol [DIAMBASE] requires that each Diameter
<    implementation use underlying security; i.e., IPsec or TLS.  These
<    mechanisms are believed to provide sufficient protection under the
<    normal Internet threat model; that is, assuming that the authorized
<    nodes engaging in the protocol have not been compromised, but that
<    the attacker has complete control over the communication channels
<    between them.  This includes eavesdropping, message modification,
<    insertion, and man-in-the-middle and replay attacks.  Note also that
<    this application includes a mechanism for application layer replay
<    protection by means of the Session-Id from [DIAMBASE] and CC-
<    Request-Number, which is specified in this document.  The Diameter
<    credit-control application is often used within one domain, and there
<    may be a single hop between the peers.  In these environments, the
<    use of TLS or IPsec is sufficient.  The details of TLS and IPsec
<    related security considerations are discussed in the [DIAMBASE].
---
>    The Diameter base protocol [RFC6733] requires that each Diameter
>    implementation use underlying security; i.e., TLS/TCP, DTLS/SCTP or
>    IPsec.  These mechanisms are believed to provide sufficient
>    protection under the normal Internet threat model; that is, assuming
>    that the authorized nodes engaging in the protocol have not been
>    compromised, but that the attacker has complete control over the
>    communication channels between them.  This includes eavesdropping,
>    message modification, insertion, and man-in-the-middle and replay
>    attacks.  Note also that this application includes a mechanism for
>    application layer replay protection by means of the Session-Id from
>    [RFC6733] and CC- Request-Number, which is specified in this
>    document.  The Diameter credit-control application is often used
>    within one domain, and there may be a single hop between the peers.
>    In these environments, the use of TLS/TCP, DTLS/SCTP or IPsec is
>    sufficient.  The details of TLS/TCP, DTLS/SCTP or IPsec related
>    security considerations are discussed in the [RFC6733].
4981a4976,4980
>    Another kind of threat is malicious modification, injection, or
>    deletion of AVPs or complete credit-control messages.  The credit-
>    control messages contain sensitive billing related information (such
>    as subscription Id, granted units, used units, cost information)
>    whose malicious modification can have financial consequences.
4985,4986c4984
< 
< Hakala, et al.              Standards Track                    [Page 89]
---
> Bertz, et al.           Expires December 15, 2016              [Page 89]
4988c4986
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
4991,4995d4988
<    Another kind of threat is malicious modification, injection, or
<    deletion of AVPs or complete credit-control messages.  The credit-
<    control messages contain sensitive billing related information (such
<    as subscription Id, granted units, used units, cost information)
<    whose malicious modification can have financial consequences.
5002,5003c4995,4996
<    credit-control messages one can collect information about the
<    credit-control server's billing models and business relationships.
---
>    credit-control messages one can collect information about the credit-
>    control server's billing models and business relationships.
5019,5020c5012,5013
<    [DIAMBASE], section 2.7) for the realm of the credit-control server
<    in the end user's home domain.  The Diameter credit-control agent can
---
>    [RFC6733], section 2.7) for the realm of the credit-control server in
>    the end user's home domain.  The Diameter credit-control agent can
5027,5030c5020,5023
<    resulting from the Redirect-Host is to be used.  The Diameter
<    credit-control agent then forwards the CCR message directly to one of
<    the hosts identified by the CCA message from the redirect agent.  If
<    the value of the Redirect-Host-Usage AVP is unequal to zero, all
---
>    resulting from the Redirect-Host is to be used.  The Diameter credit-
>    control agent then forwards the CCR message directly to one of the
>    hosts identified by the CCA message from the redirect agent.  If the
>    value of the Redirect-Host-Usage AVP is unequal to zero, all
5038,5058c5031
<    discussed more widely in [DIAMEAP], section 8.
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 90]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
< 15.  References
< 
< 15.1.  Normative References
< 
<    [DIAMBASE]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
<                Arkko, "Diameter Base Protocol", RFC 3588, September
<                2003.
< 
<    [3GPPCHARG] 3rd Generation Partnership Project; Technical
<                Specification Group Services and System Aspects, Service
<                aspects; Charging and Billing, (release 5), 3GPP TS
<                22.115 v. 5.2.1, 2002-03.
---
>    discussed more widely in [DIAMEAP], Section 8.
5060,5063d5032
<    [SIP]       Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
<                A., Peterson, J., Sparks, R., Handley, M., and E.
<                Schooler, "SIP:  Session Initiation Protocol", RFC 3261,
<                June 2002.
5065,5066d5033
<    [NAI]       Aboba, B. and M. Beadles, "The Network Access
<                Identifier", RFC 2486, January 1999.
5068,5069d5034
<    [E164]      Recommendation E.164/I.331 (05/97): The International
<                Public Telecommunication Numbering Plan. 1997.
5071,5073d5035
<    [CE164]     Complement to ITU-T Recommendation E.164 (05/1997):"List
<                of ITU-T Recommendation E.164 assigned country codes",
<                June 2000.
5075,5077d5036
<    [E212]      Recommendation E.212 (11/98): The international
<                identification plan for mobile terminals and mobile
<                users. 1998.
5079,5081d5037
<    [CE212]     Complement to ITU-T Recommendation E.212 (11/1997):" List
<                of mobile country or geographical area codes", February
<                1999.
5083,5085d5038
<    [IANA]      Narten, T. and H. Alvestrand, "Guidelines for Writing an
<                IANA Considerations Section in RFCs", BCP 26, RFC 2434,
<                October 1998.
5087,5098c5040
<    [IPv4]      Postel, J., "Internet Protocol", STD 5, RFC 791,
<                September 1981.
< 
<    [IPv6Addr]  Hinden, R. and S. Deering, "Internet Protocol Version 6
<                (IPv6) Addressing Architecture", RFC 3513, April 2003.
< 
<    [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
<                Requirement Levels", BCP 14, RFC 2119, March 1997.
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 91]
---
> Bertz, et al.           Expires December 15, 2016              [Page 90]
5100,5104c5042
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
<    [ISO4217]   Codes for the representation of currencies and funds,
<                International Standard ISO 4217,2001
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
5106,5108d5043
<    [NASREQ]    Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
<                "Diameter Network Access Server Application", RFC 4005,
<                August 2005.
5110,5119c5045
<    [AAATRANS]  Aboba, B. and J. Wood, "Authentication, Authorization and
<                Accounting (AAA) Transport Profile", RFC 3539, June 2003.
< 
<    [URL]       Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
<                Resource Locators (URL)", RFC 1738, December 1994.
< 
<    [RAD802.1X] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J.
<                Roese, "IEEE 802.1X Remote Authentication Dial In User
<                Service (RADIUS) Usage Guidelines", RFC 3580, September
<                2003.
---
> 15.  References
5121,5124c5047
<    [EUI64]     IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
<                Registration Authority",
<                http://standards.ieee.org/regauth/oui/tutorials/
<                EUI64.html March 1997.
---
> 15.1.  Normative References
5126,5129c5049,5142
<    [3GPPIMEI]  3rd Generation Partnership Project; Technical
<                Specification Group Core Network, Numbering, addressing
<                and identification, (release 5), 3GPP TS 23.003 v. 5.8.0,
<                2003-12
---
>    [CE164]    "Complement to ITU-T Recommendation E.164 (05/1997):"List
>               of ITU-T Recommendation E.164 assigned country codes"",
>               June 2000.
> 
>    [CE212]    "Complement to ITU-T Recommendation E.212 (11/1997):" List
>               of mobile country or geographical area codes"", February
>               1999.
> 
>    [E164]     "Recommendation E.164/I.331 (05/97): The International
>               Public Telecommunication Numbering Plan.", 1997.
> 
>    [E212]     "Recommendation E.212 (11/98): The international
>               identification plan for mobile terminals and mobile
>               users.", 1998.
> 
>    [EUI64]    IEEE, ""Guidelines for 64-bit Global Identifier (EUI-64)
>               Registration Authority"", March 1997,
>               <http://standards.ieee.org/regauth/oui/tutorials/
>               EUI64.html >.
> 
>    [ISO4217]  "Codes for the representation of currencies and funds,
>               International Standard ISO 4217", 2001.
> 
>    [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
>               DOI 10.17487/RFC0791, September 1981,
>               <http://www.rfc-editor.org/info/rfc791>.
> 
>    [RFC1738]  Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
>               Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738,
>               December 1994, <http://www.rfc-editor.org/info/rfc1738>.
> 
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14, RFC 2119,
>               DOI 10.17487/RFC2119, March 1997,
>               <http://www.rfc-editor.org/info/rfc2119>.
> 
>    [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
>               IANA Considerations Section in RFCs", RFC 2434,
>               DOI 10.17487/RFC2434, October 1998,
>               <http://www.rfc-editor.org/info/rfc2434>.
> 
>    [RFC2486]  Aboba, B. and M. Beadles, "The Network Access Identifier",
>               RFC 2486, DOI 10.17487/RFC2486, January 1999,
>               <http://www.rfc-editor.org/info/rfc2486>.
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 91]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
>    [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
>               A., Peterson, J., Sparks, R., Handley, M., and E.
>               Schooler, "SIP: Session Initiation Protocol", RFC 3261,
>               DOI 10.17487/RFC3261, June 2002,
>               <http://www.rfc-editor.org/info/rfc3261>.
> 
>    [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
>               (IPv6) Addressing Architecture", RFC 3513,
>               DOI 10.17487/RFC3513, April 2003,
>               <http://www.rfc-editor.org/info/rfc3513>.
> 
>    [RFC3539]  Aboba, B. and J. Wood, "Authentication, Authorization and
>               Accounting (AAA) Transport Profile", RFC 3539,
>               DOI 10.17487/RFC3539, June 2003,
>               <http://www.rfc-editor.org/info/rfc3539>.
> 
>    [RFC3580]  Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
>               "IEEE 802.1X Remote Authentication Dial In User Service
>               (RADIUS) Usage Guidelines", RFC 3580,
>               DOI 10.17487/RFC3580, September 2003,
>               <http://www.rfc-editor.org/info/rfc3580>.
> 
>    [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
>               Ed., "Diameter Base Protocol", RFC 6733,
>               DOI 10.17487/RFC6733, October 2012,
>               <http://www.rfc-editor.org/info/rfc6733>.
> 
>    [RFC7155]  Zorn, G., Ed., "Diameter Network Access Server
>               Application", RFC 7155, DOI 10.17487/RFC7155, April 2014,
>               <http://www.rfc-editor.org/info/rfc7155>.
> 
>    [TGPPCHARG]
>               3rd Generation Partnership Project, "Technical
>               Specification Group Services and System Aspects, Service
>               aspects; Charging and Billing, (release 5), 3GPP TS 22.115
>               v. 5.2.1", 2002-03.
> 
>    [TGPPIMEI]
>               3rd Generation Partnership Project, "Technical
>               Specification Group Core Network, Numbering, addressing
>               and identification, (release 5), 3GPP TS 23.003 v. 5.8.0",
>               2003-12.
5133,5147c5146,5148
<    [RFC2866]   Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
< 
<    [DIAMMIP]   Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
<                P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
<                August 2005.
< 
<    [DIAMEAP]   Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
<                Authentication Protocol (EAP) Application", Work in
<                Progress.
< 
<    [RFC3725]   Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
<                Camarillo, "Best Current Practices for Third Party Call
<                Control (3pcc) in the Session Initiation Protocol (SIP)",
<                BCP 85, RFC 3725, April 2004.
< 
---
>    [DIAMEAP]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
>               Authentication Protocol (EAP) Application", Work in
>               Progress.
5150a5152,5154
> Bertz, et al.           Expires December 15, 2016              [Page 92]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
5152a5157,5159
>    [RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866,
>               DOI 10.17487/RFC2866, June 2000,
>               <http://www.rfc-editor.org/info/rfc2866>.
5154,5156c5161,5165
< Hakala, et al.              Standards Track                    [Page 92]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
---
>    [RFC3725]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
>               Camarillo, "Best Current Practices for Third Party Call
>               Control (3pcc) in the Session Initiation Protocol (SIP)",
>               BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004,
>               <http://www.rfc-editor.org/info/rfc3725>.
5157a5167,5170
>    [RFC4004]  Calhoun, P., Johansson, T., Perkins, C., Hiller, T., Ed.,
>               and P. McCann, "Diameter Mobile IPv4 Application",
>               RFC 4004, DOI 10.17487/RFC4004, August 2005,
>               <http://www.rfc-editor.org/info/rfc4004>.
5159c5172
< 16.  Acknowledgements
---
> Appendix A.  Acknowledgements
5166a5180
> Appendix B.  Credit-Control Sequences
5167a5182
> B.1.  Flow I
5193,5210c5208
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 93]
---
> Bertz, et al.           Expires December 15, 2016              [Page 93]
5212,5213c5210
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
5215d5211
< Appendix A.  Credit-Control Sequences
5217,5219c5213
< A.1.  Flow I
< 
<                          NAS
---
>                               NAS
5221,5258c5215,5252
<       |(1)User Logon      |(2)AA Request (CC AVPs)                  |
<       |------------------>|------------------->|                    |
<       |                   |                    |(3)CCR(initial, CC AVPs)
<       |                   |                    |------------------->|
<       |                   |                    | (4)CCA(Granted-Units)
<       |                   |                    |<-------------------|
<       |                   |(5)AA Answer(Granted-Units)              |
<       |(6)Access granted  |<-------------------|                    |
<       |<----------------->|                    |                    |
<       |                   |                    |                    |
<       :                   :                    :                    :
<       |                   |(7)CCR(update,Used-Units)                |
<       |                   |------------------->|(8)CCR              |
<       |                   |                    |   (update,Used-Units)
<       |                   |                    |------------------->|
<       |                   |                    |(9)CCA(Granted-Units)
<       |                   |(10)CCA(Granted-Units)<------------------|
<       |                   |<-------------------|                    |
<       :                   :                    :                    :
<       |         (Auth. lifetime expires)       |                    |
<       |                   |(11) AAR (CC AVP)   |                    |
<       |                   |------------------->|                    |
<       |                   |          (12) AAA  |                    |
<       |                   |<-------------------|                    |
<       :                   :                    :                    :
<       :                   :                    :                    :
<       |(13) User logoff   |                    |                    |
<       |------------------>|(14)CCR(term.,Used-Units)                |
<       |                   |------------------->|(15)CCR             |
<       |                   |                    |   (term.,Used-Units)
<       |                   |                    |------------------->|
<       |                   |                    |            (16)CCA |
<       |                   |            (17)CCA |<-------------------|
<       |                   |<-------------------|                    |
<       |                   |(18)STR             |                    |
<       |                   |------------------->|                    |
<       |                   |            (19)STA |                    |
<       |                   |<-------------------|                    |
---
>      |(1)User Logon      |(2)AA Request (CC AVPs)                  |
>      |------------------>|------------------->|                    |
>      |                   |                    |(3)CCR(initial, CC AVPs)
>      |                   |                    |------------------->|
>      |                   |                    | (4)CCA(Granted-Units)
>      |                   |                    |<-------------------|
>      |                   |(5)AA Answer(Granted-Units)              |
>      |(6)Access granted  |<-------------------|                    |
>      |<----------------->|                    |                    |
>      |                   |                    |                    |
>      :                   :                    :                    :
>      |                   |(7)CCR(update,Used-Units)                |
>      |                   |------------------->|(8)CCR              |
>      |                   |                    |   (update,Used-Units)
>      |                   |                    |------------------->|
>      |                   |                    |(9)CCA(Granted-Units)
>      |                   |(10)CCA(Granted-Units)<------------------|
>      |                   |<-------------------|                    |
>      :                   :                    :                    :
>      |         (Auth. lifetime expires)       |                    |
>      |                   |(11) AAR (CC AVP)   |                    |
>      |                   |------------------->|                    |
>      |                   |          (12) AAA  |                    |
>      |                   |<-------------------|                    |
>      :                   :                    :                    :
>      :                   :                    :                    :
>      |(13) User logoff   |                    |                    |
>      |------------------>|(14)CCR(term.,Used-Units)                |
>      |                   |------------------->|(15)CCR             |
>      |                   |                    |   (term.,Used-Units)
>      |                   |                    |------------------->|
>      |                   |                    |            (16)CCA |
>      |                   |            (17)CCA |<-------------------|
>      |                   |<-------------------|                    |
>      |                   |(18)STR             |                    |
>      |                   |------------------->|                    |
>      |                   |            (19)STA |                    |
>      |                   |<-------------------|                    |
5260c5254
<                             Figure A.1: Flow I
---
>                              Figure 10: Flow I
5261a5256,5259
>    A credit-control flow for Network Access Services prepaid is shown in
>    Figure A.1.  The Diameter [RFC7155] is implemented in the Network
>    Access Server (NAS).  The focus of this flow is in the credit
>    authorization.
5266c5264
< Hakala, et al.              Standards Track                    [Page 94]
---
> Bertz, et al.           Expires December 15, 2016              [Page 94]
5268c5266
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
5271,5275d5268
<    A credit-control flow for Network Access Services prepaid is shown in
<    Figure A.1.  The Diameter [NASREQ] is implemented in the Network
<    Access Server (NAS).  The focus of this flow is in the credit
<    authorization.
< 
5280c5273
<    as usual [NASREQ].  The home Diameter AAA server performs service-
---
>    as usual [RFC7155].  The home Diameter AAA server performs service-
5286,5315c5279,5289
<    server to perform credit authorization (3) and to establish a
<    credit-control session.  (The home Diameter AAA server may forward
<    service-specific AVPs received from the NAS as input for the rating
<    process.)  The Diameter credit-control server checks the end user's
<    account balance, rates the service, and reserves credit from the end
<    user's account.  The reserved quota is returned to the home Diameter
<    AAA server in the Diameter Credit-Control-Answer (4).  The home
<    Diameter AAA server sends the reserved quota to the NAS in the
<    Diameter AA-Answer (AAA).  Upon successful AAA, the NAS starts the
<    credit-control session and starts monitoring the granted units (5).
<    The NAS grants access to the end user (6).  At the expiry of the
<    allocated quota, the NAS sends a Diameter Credit-Control-Request with
<    CC-Request-Type set to UPDATE_REQUEST to the Home Diameter AAA server
<    (7).  This message contains the units used thus far.  The home
<    Diameter AAA server forwards the CCR to the Diameter credit-control
<    server (8).  The Diameter credit-control server debits the used units
<    from the end user's account and allocates a new quota that is
<    returned to the home Diameter AAA server in the Diameter Credit-
<    Control-Answer (9).  The message is forwarded to the NAS (10).
<    During the ongoing credit-control session, the authorization lifetime
<    expires, and the authorization/authentication client in the NAS
<    performs service specific re-authorization to the home Diameter AAA
<    server, as usual.  The credit-control client populates the AAR with
<    the Credit-Control AVP set to RE_AUTHORIZATION, indicating that the
<    credit-control server shall not be contacted, as the credit
<    authorization is controlled by the burning rate of the granted units
<    (11).  The home Diameter AAA server performs service-specific re-
<    authorization as usual and returns the AA-Answer to the NAS (12).
<    The end user logs off from the network (13).  To debit the used units
<    from the end user's account and to stop the credit-control session,
---
>    server to perform credit authorization (3) and to establish a credit-
>    control session.  (The home Diameter AAA server may forward service-
>    specific AVPs received from the NAS as input for the rating process.)
>    The Diameter credit-control server checks the end user's account
>    balance, rates the service, and reserves credit from the end user's
>    account.  The reserved quota is returned to the home Diameter AAA
>    server in the Diameter Credit-Control-Answer (4).  The home Diameter
>    AAA server sends the reserved quota to the NAS in the Diameter AA-
>    Answer (AAA).  Upon successful AAA, the NAS starts the credit-control
>    session and starts monitoring the granted units (5).  The NAS grants
>    access to the end user (6).  At the expiry of the allocated quota,
5317,5374c5291,5316
<    set to TERMINATION_REQUEST to the home Diameter AAA server (14).  The
<    home Diameter AAA server forwards the CCR to the credit-control
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 95]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
<    server (15).  The Diameter credit-control server acknowledges the
<    session termination by sending a Diameter Credit-Control-Answer to
<    the home Diameter AAA server (16).  The home Diameter AAA server
<    forwards the answer to the NAS (17).  STR/STA takes place between the
<    NAS and home Diameter AAA server, as usual (18-19).
< 
< A.2.  Flow II
< 
<               SIP Proxy/Registrar   AAA
<         A           (CC Client)     Server           B        CC Server
<         |(i)  REGISTER |              |              |              |
<         |------------->|(ii)          |              |              |
<         |              |------------->|              |              |
<         |              |authentication &             |              |
<         |              |authorization |              |              |
<         |              |<-------------|              |              |
<         |(iii)200 OK   |                             |              |
<         |<-------------|                             |              |
<         :              :                             :              :
<         |(1)  INVITE   |                                            :
<         |------------->|
<         |              |(2)  CCR (Initial, SIP specific AVP)        |
<         |              |------------------------------------------->|
<         |              |(3)  CCA (Granted-Units)                    |
<         |              |<-------------------------------------------|
<         |              |(4)  INVITE                  |              |
<         |              |---------------------------->|              |
<         :              :                             :              :
<         |              |(5)  CCR (update, Used-Units)               |
<         |              |------------------------------------------->|
<         |              |(6)  CCA (Granted-Units)                    |
<         |              |<-------------------------------------------|
<         :              :                             :              :
<         |(7)  BYE      |                             |              |
<         |------------->|                             |              |
<         |              |(8)  BYE                     |              |
<         |              |---------------------------->|              |
<         |              |(9)  CCR (termination, Used-Units)          |
<         |              |------------------------------------------->|
<         |              |(10) CCA ()                                 |
<         |              |<-------------------------------------------|
<         |              |                             |              |
< 
<                            Figure A.2: Flow II
< 
< 
< 
< 
---
>    set to UPDATE_REQUEST to the Home Diameter AAA server (7).  This
>    message contains the units used thus far.  The home Diameter AAA
>    server forwards the CCR to the Diameter credit-control server (8).
>    The Diameter credit-control server debits the used units from the end
>    user's account and allocates a new quota that is returned to the home
>    Diameter AAA server in the Diameter Credit- Control-Answer (9).  The
>    message is forwarded to the NAS (10).  During the ongoing credit-
>    control session, the authorization lifetime expires, and the
>    authorization/authentication client in the NAS performs service
>    specific re-authorization to the home Diameter AAA server, as usual.
>    The credit-control client populates the AAR with the Credit-Control
>    AVP set to RE_AUTHORIZATION, indicating that the credit-control
>    server shall not be contacted, as the credit authorization is
>    controlled by the burning rate of the granted units (11).  The home
>    Diameter AAA server performs service-specific re- authorization as
>    usual and returns the AA-Answer to the NAS (12).  The end user logs
>    off from the network (13).  To debit the used units from the end
>    user's account and to stop the credit-control session, the NAS sends
>    a Diameter Credit-Control-Request with CC-Request-Type set to
>    TERMINATION_REQUEST to the home Diameter AAA server (14).  The home
>    Diameter AAA server forwards the CCR to the credit-control server
>    (15).  The Diameter credit-control server acknowledges the session
>    termination by sending a Diameter Credit-Control-Answer to the home
>    Diameter AAA server (16).  The home Diameter AAA server forwards the
>    answer to the NAS (17).  STR/STA takes place between the NAS and home
>    Diameter AAA server, as usual (18-19).
5378,5380c5320,5360
< Hakala, et al.              Standards Track                    [Page 96]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Bertz, et al.           Expires December 15, 2016              [Page 95]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
> B.2.  Flow II
> 
>          SIP Proxy/Registrar   AAA
>    A           (CC Client)     Server           B        CC Server
>    |(i)  REGISTER |              |              |              |
>    |------------->|(ii)          |              |              |
>    |              |------------->|              |              |
>    |              |authentication &             |              |
>    |              |authorization |              |              |
>    |              |<-------------|              |              |
>    |(iii)200 OK   |                             |              |
>    |<-------------|                             |              |
>    :              :                             :              :
>    |(1)  INVITE   |                                            :
>    |------------->|
>    |              |(2)  CCR (Initial, SIP specific AVP)        |
>    |              |------------------------------------------->|
>    |              |(3)  CCA (Granted-Units)                    |
>    |              |<-------------------------------------------|
>    |              |(4)  INVITE                  |              |
>    |              |---------------------------->|              |
>    :              :                             :              :
>    |              |(5)  CCR (update, Used-Units)               |
>    |              |------------------------------------------->|
>    |              |(6)  CCA (Granted-Units)                    |
>    |              |<-------------------------------------------|
>    :              :                             :              :
>    |(7)  BYE      |                             |              |
>    |------------->|                             |              |
>    |              |(8)  BYE                     |              |
>    |              |---------------------------->|              |
>    |              |(9)  CCR (termination, Used-Units)          |
>    |              |------------------------------------------->|
>    |              |(10) CCA ()                                 |
>    |              |<-------------------------------------------|
>    |              |                             |              |
5381a5362
>                             Figure 11: Flow II
5391a5373,5380
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 96]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
5399,5401c5388,5390
<    refer to [SIP]).  Finally, the degree of credit-control measuring of
<    the media by the proxy depends on the business model design used in
<    setting up the end system and proxies in the SIP network.
---
>    refer to [RFC3261]).  Finally, the degree of credit-control measuring
>    of the media by the proxy depends on the business model design used
>    in setting up the end system and proxies in the SIP network.
5431,5438d5419
< 
< 
< 
< Hakala, et al.              Standards Track                    [Page 97]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
5445d5425
< A.3.  Flow III
5447,5466d5426
<                           MMS Server
<              A           (CC Client)           B           CC Server
<              |(1) Send MMS    |                |                |
<              |--------------->|                |                |
<              |                |(2)  CCR (event, DIRECT_DEBITING,|
<              |                |          MMS specific AVP)      |
<              |                |-------------------------------->|
<              |                |(3)  CCA (Granted-Units)         |
<              |                |<--------------------------------|
<              |(4) Send MMS Ack|                |                |
<              |<---------------|                |                |
<              |                |(5) Notify MMS  |                |
<              |                |--------------->|                |
<              :                :                :                :
<              |                |(6) Retrieve MMS|                |
<              |                |<---------------|                |
<              |                |(7) Retrieve MMS|                |
<              |                |    Ack         |                |
<              |                |--------------->|                |
<              |                |                |                |
5468c5428,5460
<                              Figure A.3: Flow III
---
> 
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016              [Page 97]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
> B.3.  Flow III
> 
>                             MMS Server
>                 A           (CC Client)           B           CC Server
>                 |(1) Send MMS    |                |                |
>                 |--------------->|                |                |
>                 |                |(2)  CCR (event, DIRECT_DEBITING,|
>                 |                |          MMS specific AVP)      |
>                 |                |-------------------------------->|
>                 |                |(3)  CCA (Granted-Units)         |
>                 |                |<--------------------------------|
>                 |(4) Send MMS Ack|                |                |
>                 |<---------------|                |                |
>                 |                |(5) Notify MMS  |                |
>                 |                |--------------->|                |
>                 :                :                :                :
>                 |                |(6) Retrieve MMS|                |
>                 |                |<---------------|                |
>                 |                |(7) Retrieve MMS|                |
>                 |                |    Ack         |                |
>                 |                |--------------->|                |
>                 |                |                |                |
> 
>                             Figure 12: Flow III
5487a5480,5484
> B.4.  Flow IV
5490,5492d5486
< Hakala, et al.              Standards Track                    [Page 98]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
5493a5488,5490
> Bertz, et al.           Expires December 15, 2016              [Page 98]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
5495d5491
< A.4.  Flow IV
5497,5521c5493,5517
<                           MMS Server
<       Content Server     (CC Client)           B           CC Server
<              |(1) Send MMS    |                |                |
<              |--------------->|                |                |
<              |                |(2)  CCR (event, CHECK_BALANCE,  |
<              |                |          MMS specific AVP)      |
<              |                |-------------------------------->|
<              |                |(3)  CCA (ENOUGH_CREDIT)         |
<              |                |<--------------------------------|
<              |(4) Send MMS Ack|                |                |
<              |<---------------|                |                |
<              |                |(5) Notify MMS  |                |
<              |                |--------------->|                |
<              :                :                :                :
<              |                |(6) Retrieve MMS|                |
<              |                |<---------------|                |
<              |                |(7)  CCR (event, DIRECT_DEBITING,|
<              |                |          MMS specific AVP)      |
<              |                |-------------------------------->|
<              |                |(8)  CCA (Granted-Units)         |
<              |                |<--------------------------------|
<              |                |(9) Retrieve MMS|                |
<              |                |    Ack         |                |
<              |                |--------------->|                |
<              |                |                |                |
---
>                              MMS Server
>          Content Server     (CC Client)           B           CC Server
>                 |(1) Send MMS    |                |                |
>                 |--------------->|                |                |
>                 |                |(2)  CCR (event, CHECK_BALANCE,  |
>                 |                |          MMS specific AVP)      |
>                 |                |-------------------------------->|
>                 |                |(3)  CCA (ENOUGH_CREDIT)         |
>                 |                |<--------------------------------|
>                 |(4) Send MMS Ack|                |                |
>                 |<---------------|                |                |
>                 |                |(5) Notify MMS  |                |
>                 |                |--------------->|                |
>                 :                :                :                :
>                 |                |(6) Retrieve MMS|                |
>                 |                |<---------------|                |
>                 |                |(7)  CCR (event, DIRECT_DEBITING,|
>                 |                |          MMS specific AVP)      |
>                 |                |-------------------------------->|
>                 |                |(8)  CCA (Granted-Units)         |
>                 |                |<--------------------------------|
>                 |                |(9) Retrieve MMS|                |
>                 |                |    Ack         |                |
>                 |                |--------------->|                |
>                 |                |                |                |
5523c5519
<                               Figure A.4: Flow IV
---
>                             Figure 13: Flow IV
5542a5539,5540
>    (EVENT_REQUEST with Requested-Action CHECK_BALANCE) to verify that
>    end user B can cover the cost for the MMS (2).  The Diameter credit-
5546c5544
< Hakala, et al.              Standards Track                    [Page 99]
---
> Bertz, et al.           Expires December 15, 2016              [Page 99]
5548c5546
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
5551,5552d5548
<    (EVENT_REQUEST with Requested-Action CHECK_BALANCE) to verify that
<    end user B can cover the cost for the MMS (2).  The Diameter credit-
5571,5593c5567
<    by using the REFUND action described in section 6.4.
< 
< A.5.  Flow V
< 
<                         SIP Controller
<              A           (CC Client)           B           CC Server
<              |(1)INVITE B(SDP)|                |                |
<              |--------------->|                |                |
<              |                |(2)  CCR (event, PRICE_ENQUIRY,  |
<              |                |          SIP specific AVPs)     |
<              |                |-------------------------------->|
<              |                |(3)  CCA (Cost-Information)      |
<              |                |<--------------------------------|
<              | (4)MESSAGE(URL)|                |                |
<              |<---------------|                |                |
<              |(5)HTTP GET     |                |                |
<              |--------------->|                |                |
<              |(6)HTTP POST    |                |                |
<              |--------------->|(7)INVITE(SDP)  |                |
<              |                |--------------->|                |
<              |                |      (8)200 OK |                |
<              |      (9)200 OK |<---------------|                |
<              |<---------------|                |                |
---
>    by using the REFUND action described in Section 6.4.
5595c5569
<                             Figure A.5: Flow V
---
> B.5.  Flow V
5596a5571,5589
>                            SIP Controller
>                 A           (CC Client)           B           CC Server
>                 |(1)INVITE B(SDP)|                |                |
>                 |--------------->|                |                |
>                 |                |(2)  CCR (event, PRICE_ENQUIRY,  |
>                 |                |          SIP specific AVPs)     |
>                 |                |-------------------------------->|
>                 |                |(3)  CCA (Cost-Information)      |
>                 |                |<--------------------------------|
>                 | (4)MESSAGE(URL)|                |                |
>                 |<---------------|                |                |
>                 |(5)HTTP GET     |                |                |
>                 |--------------->|                |                |
>                 |(6)HTTP POST    |                |                |
>                 |--------------->|(7)INVITE(SDP)  |                |
>                 |                |--------------->|                |
>                 |                |      (8)200 OK |                |
>                 |      (9)200 OK |<---------------|                |
>                 |<---------------|                |                |
5597a5591
>                              Figure 14: Flow V
5598a5593,5596
>    This is an example of Diameter credit-control for SIP sessions.
>    Although the flow focuses on illustrating the usage of credit-control
>    messages, the SIP signaling is inaccurate, and the diagram is not by
>    any means an attempt to define a service provider's SIP network.
5602c5600
< Hakala, et al.              Standards Track                   [Page 100]
---
> Bertz, et al.           Expires December 15, 2016             [Page 100]
5604c5602
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
5607,5611d5604
<    This is an example of Diameter credit-control for SIP sessions.
<    Although the flow focuses on illustrating the usage of credit-control
<    messages, the SIP signaling is inaccurate, and the diagram is not by
<    any means an attempt to define a service provider's SIP network.
< 
5641a5635
> B.6.  Flow VI
5642a5637,5649
>                           Gaming Server
>    End User                (CC Client)              CC Server
>       |  (1)Service Delivery   |                        |
>       |<---------------------->|                        |
>       :                        :                        :
>       :                        :                        :
>       |                        |(2)CCR(event,REFUND,Requested-
>       |                        |Service-Unit,Service-Parameter-Info)
>       |                        |----------------------->|
>       |                        |  (3)CCA(Cost-Information)
>       |                        |<-----------------------|
>       |        (4)Notification |                        |
>       |<-----------------------|                        |
5643a5651
>                             Figure 15: Flow VI
5648,5658c5656
< 
< 
< 
< 
< 
< 
< 
< 
< 
< 
< Hakala, et al.              Standards Track                   [Page 101]
---
> Bertz, et al.           Expires December 15, 2016             [Page 101]
5660,5663c5658
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
< A.6.  Flow VI
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
5665,5679d5659
<                              Gaming Server
<       End User                (CC Client)              CC Server
<          |  (1)Service Delivery   |                        |
<          |<---------------------->|                        |
<          :                        :                        :
<          :                        :                        :
<          |                        |(2)CCR(event,REFUND,Requested-
<          |                        |Service-Unit,Service-Parameter-Info)
<          |                        |----------------------->|
<          |                        |  (3)CCA(Cost-Information)
<          |                        |<-----------------------|
<          |        (4)Notification |                        |
<          |<-----------------------|                        |
< 
<                           Figure A.6: Flow VI
5700a5681
> B.7.  Flow VII
5714,5716d5694
< Hakala, et al.              Standards Track                   [Page 102]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
5719d5696
< A.7.  Flow VII
5721,5747d5697
<                   SIP Controller    Top-Up
<         A          (CC Client)      Server           B      CC Server
<         |               |              |             |              |
<         |               | (1) CCR(Update,Used-Unit)  |              |
<         |               |------------------------------------------>|
<         |               |              (2) CCA(Final-Unit, Redirect)|
<         |               |<------------------------------------------|
<         :               :              :             :              :
<         :               :              :             :              :
<         |               | (3) CCR(Update, Used-Units)|              |
<         |               |------------------------------------------>|
<         |               | (3a)INVITE("hold")         |              |
<         |               |--------------------------->|              |
<         |               |              |      (4) CCA(Validity-Time)|
<         |               |<------------------------------------------|
<         |     (5)INVITE | (6)INVITE    |             |              |
<         |<--------------|------------->|             |              |
<         |            (7)RTP            |             |              |
<         |..............................|             |              |
<         |               |       (8)BYE |             |              |
<         |               |<-------------|             |              |
<         |               | (9)CCR(Update)             |              |
<         |               |------------------------------------------>|
<         |               |                     (10)CCA(Granted-Unit) |
<         |               |<------------------------------------------|
<         |    (12)INVITE | (11)INVITE                 |              |
<         |<--------------|--------------------------->|              |
5749c5699,5745
<                            Figure A.7: Flow VII
---
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016             [Page 102]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
>              SIP Controller    Top-Up
>    A          (CC Client)      Server           B      CC Server
>    |               |              |             |              |
>    |               | (1) CCR(Update,Used-Unit)  |              |
>    |               |------------------------------------------>|
>    |               |              (2) CCA(Final-Unit, Redirect)|
>    |               |<------------------------------------------|
>    :               :              :             :              :
>    :               :              :             :              :
>    |               | (3) CCR(Update, Used-Units)|              |
>    |               |------------------------------------------>|
>    |               | (3a)INVITE("hold")         |              |
>    |               |--------------------------->|              |
>    |               |              |      (4) CCA(Validity-Time)|
>    |               |<------------------------------------------|
>    |     (5)INVITE | (6)INVITE    |             |              |
>    |<--------------|------------->|             |              |
>    |            (7)RTP            |             |              |
>    |..............................|             |              |
>    |               |       (8)BYE |             |              |
>    |               |<-------------|             |              |
>    |               | (9)CCR(Update)             |              |
>    |               |------------------------------------------>|
>    |               |                     (10)CCA(Granted-Unit) |
>    |               |<------------------------------------------|
>    |    (12)INVITE | (11)INVITE                 |              |
>    |<--------------|--------------------------->|              |
> 
>                             Figure 16: Flow VII
5766a5763,5764
>    Final-Unit-Action set to REDIRECT, the Redirect-Address-Type set to
>    SIP URI, and the Redirect-Server-Address set to the Top-up server
5770c5768
< Hakala, et al.              Standards Track                   [Page 103]
---
> Bertz, et al.           Expires December 15, 2016             [Page 103]
5772c5770
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
5775,5776d5772
<    Final-Unit-Action set to REDIRECT, the Redirect-Address-Type set to
<    SIP URI, and the Redirect-Server-Address set to the Top-up server
5781,5782c5777,5778
<    with the appropriate connection address in the SDP (3a).  The
<    Credit-Control-Request message contains the units used thus far.  The
---
>    with the appropriate connection address in the SDP (3a).  The Credit-
>    Control-Request message contains the units used thus far.  The
5784,5801c5780,5797
<    user's account but does not make any credit reservation.  The
<    Credit-Control-Answer message, which contains the Validity-Time to
<    supervise the graceful service termination, is returned to the SIP
<    controller (4).  The SIP controller establishes a SIP session between
<    the prepaid user and the Top-up server (5, 6).  The Top-up server
<    plays an announcement and prompts the user to enter a credit card
<    number and the amount of money to be used to replenish the account
<    (7).  The Top-up server validates the credit card number and
<    replenishes the user's account (using some means outside the scope of
<    this specification) and releases the SIP session (8).  The SIP
<    controller can now assume that communication between the prepaid user
<    and the Top-up server took place.  It sends a spontaneous Credit-
<    Control-Request (UPDATE_REQUEST) to the Diameter credit-control
<    server to check whether the account has been replenished (9).  The
<    Diameter credit-control server reserves credit from the end user's
<    account and returns the reserved quota to the SIP controller in the
<    Credit-Control-Answer (10).  At this point, the SIP controller re-
<    connects the caller and the called party (11,12).
---
>    user's account but does not make any credit reservation.  The Credit-
>    Control-Answer message, which contains the Validity-Time to supervise
>    the graceful service termination, is returned to the SIP controller
>    (4).  The SIP controller establishes a SIP session between the
>    prepaid user and the Top-up server (5, 6).  The Top-up server plays
>    an announcement and prompts the user to enter a credit card number
>    and the amount of money to be used to replenish the account (7).  The
>    Top-up server validates the credit card number and replenishes the
>    user's account (using some means outside the scope of this
>    specification) and releases the SIP session (8).  The SIP controller
>    can now assume that communication between the prepaid user and the
>    Top-up server took place.  It sends a spontaneous Credit- Control-
>    Request (UPDATE_REQUEST) to the Diameter credit-control server to
>    check whether the account has been replenished (9).  The Diameter
>    credit-control server reserves credit from the end user's account and
>    returns the reserved quota to the SIP controller in the Credit-
>    Control-Answer (10).  At this point, the SIP controller re- connects
>    the caller and the called party (11,12).
5802a5799
> B.8.  Flow VIII
5826,5828d5822
< Hakala, et al.              Standards Track                   [Page 104]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
5829a5824,5826
> Bertz, et al.           Expires December 15, 2016             [Page 104]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
5831d5827
< A.8.  Flow VIII
5833c5829
<                          NAS                           Top-up      CC
---
>                           NAS                           Top-up      CC
5835,5860c5831,5856
<      |(1)User Logon      |(2)AA Request (CC AVPs)        |         |
<      |------------------>|------------------->|          |         |
<      |                   |                    |(3)CCR(initial, CC AVPs)
<      |                   |                    |------------------->|
<      |                   |                    |(4)CCA(Final-Unit,  |
<      |                   |                    |      Validity-Time)|
<      |                   |                    |<-------------------|
<      |                   |(5)AA Answer(Final-Unit,Validity-Time)   |
<      |(6)Limited Access  |<-------------------|          |         |
<      |      granted      |                    |          |         |
<      |<----------------->|                    |          |         |
<      |                   |                    |          |         |
<      |   (7)TCP/HTTP     |        (8)TCP/HTTP            |         |
<      |<----------------->|<----------------------------->|         |
<      |                 (9) Replenish account             |         |
<      |<------------------------------------------------->|         |
<      |                   |                    |            (10)RAR |
<      |                   |<-------------------|<-------------------|
<      |                   | (11) RAA           |                    |
<      |                   |------------------->|------------------->|
<      |                   |(12)CCR(update)     |                    |
<      |                   |------------------->|(13)CCR(Update)     |
<      |                   |                    |------------------->|
<      |                   |                    |(14)CCA(Granted-Units)
<      |                   |(15)CCA(Granted-Units)<------------------|
<      |                   |<-------------------|                    |
---
>       |(1)User Logon      |(2)AA Request (CC AVPs)        |         |
>       |------------------>|------------------->|          |         |
>       |                   |                    |(3)CCR(initial, CC AVPs)
>       |                   |                    |------------------->|
>       |                   |                    |(4)CCA(Final-Unit,  |
>       |                   |                    |      Validity-Time)|
>       |                   |                    |<-------------------|
>       |                   |(5)AA Answer(Final-Unit,Validity-Time)   |
>       |(6)Limited Access  |<-------------------|          |         |
>       |      granted      |                    |          |         |
>       |<----------------->|                    |          |         |
>       |                   |                    |          |         |
>       |   (7)TCP/HTTP     |        (8)TCP/HTTP            |         |
>       |<----------------->|<----------------------------->|         |
>       |                 (9) Replenish account             |         |
>       |<------------------------------------------------->|         |
>       |                   |                    |            (10)RAR |
>       |                   |<-------------------|<-------------------|
>       |                   | (11) RAA           |                    |
>       |                   |------------------->|------------------->|
>       |                   |(12)CCR(update)     |                    |
>       |                   |------------------->|(13)CCR(Update)     |
>       |                   |                    |------------------->|
>       |                   |                    |(14)CCA(Granted-Units)
>       |                   |(15)CCA(Granted-Units)<------------------|
>       |                   |<-------------------|                    |
5862c5858
<                          Figure A.8: Flow VIII
---
>                            Figure 17: Flow VIII
5868c5864
<    [NASREQ] is implemented in the Network Access Server (NAS).
---
>    [RFC7155] is implemented in the Network Access Server (NAS).
5874c5870
<    usual [NASREQ].  The home Diameter AAA server performs service
---
>    usual [RFC7155].  The home Diameter AAA server performs service
5878a5875,5876
>    Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter
>    credit-control server to perform credit authorization (3) and to
5882c5880
< Hakala, et al.              Standards Track                   [Page 105]
---
> Bertz, et al.           Expires December 15, 2016             [Page 105]
5884c5882
< RFC 4006          Diameter Credit-Control Application        August 2005
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
5887,5888d5884
<    Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter
<    credit-control server to perform credit authorization (3) and to
5914,5919c5910,5915
<    this specification)(9).  After successful account top-up, the
<    credit-control server sends a Re-Auth-Request message to the NAS
<    (10).  The NAS acknowledges the request by returning the Re-Auth-
<    Answer message (11) and initiates the credit re-authorization by
<    sending a Credit-Control-request (UPDATE_REQUEST) to the Diameter
<    credit-control server (12,13).
---
>    this specification)(9).  After successful account top-up, the credit-
>    control server sends a Re-Auth-Request message to the NAS (10).  The
>    NAS acknowledges the request by returning the Re-Auth- Answer message
>    (11) and initiates the credit re-authorization by sending a Credit-
>    Control-request (UPDATE_REQUEST) to the Diameter credit-control
>    server (12,13).
5926a5923
> B.9.  Flow IX
5927a5925,5930
>    The Diameter credit-control application defines the Multiple-
>    Services-Credit-Control AVP that can be used to support independent
>    credit-control of multiple services in a single credit-control (sub-)
>    session for service elements that have such capabilities.  It is
>    possible to request and allocate resources as a credit pool that is
>    shared between services or rating groups.
5933,5938c5936
< 
< 
< 
< 
< 
< Hakala, et al.              Standards Track                   [Page 106]
---
> Bertz, et al.           Expires December 15, 2016             [Page 106]
5940,5941c5938
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
5943,5950d5939
< A.9.  Flow IX
< 
<    The Diameter credit-control application defines the Multiple-
<    Services-Credit-Control AVP that can be used to support independent
<    credit-control of multiple services in a single credit-control (sub-)
<    session for service elements that have such capabilities.  It is
<    possible to request and allocate resources as a credit pool that is
<    shared between services or rating groups.
5954c5943
<    of multiple services, as defined in section 5.1.2.  It is assumed
---
>    of multiple services, as defined in Section 5.1.2.  It is assumed
5961,6046c5950,6065
<                        (CC client)
<       |(1)User logon      |                                         |
<       |------------------>|(2)CCR(initial, Service-Id access,       |
<       |                   |        Access specific AVPs,            |
<       |                   |        Multiple-Service-Indicator)      |
<       |                   |---------------------------------------->|
<       |                   |(3)CCA(Multiple-Services-CC (            |
<       |                   |        Granted-Units(Total-Octets),     |
<       |                   |        Service-Id access,               |
<       |                   |        Validity-time,                   |
<       |                   |        G-S-U-Pool-Reference(Pool-Id 1,  |
<       |                   |          Multiplier 10)))               |
<       |                   |<----------------------------------------|
<       :                   :                                         :
<       |(4)Service-Request (Service 1)                               |
<       |------------------>|(5)CCR(update, Multiple-Services-CC(     |
<       |                   |        Requested-Units(), Service-Id 1, |
<       |                   |        Rating-Group 1))                 |
<       |                   |---------------------------------------->|
<       |                   |(6)CCA(Multiple-Services-CC (            |
<       |                   |        Granted-Units(Time),             |
<       |                   |        Rating-Group 1,                  |
<       |                   |        G-S-U-Pool-Reference(Pool-Id 1,  |
<       |                   |          Multiplier 1)))                |
<       |                   |<----------------------------------------|
<       :                   :                                         :
<       |(7)Service-Request (Service 2)                               |
<       |------------------>|                                         |
< 
< 
< 
< 
< 
< Hakala, et al.              Standards Track                   [Page 107]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
<       :                   :                                         :
<       :                   :                                         :
<       |(8)Service-Request (Service 3&4)                             |
<       |------------------>|(9)CCR(update, Multiple-Services-CC (    |
<       |                   |        Requested-Units(), Service-Id 3, |
<       |                   |        Rating-Group 2),                 |
<       |                   |        Multiple-Services-CC (           |
<       |                   |        Requested-Units(), Service-Id 4, |
<       |                   |        Rating-Group 3))                 |
<       |                   |---------------------------------------->|
<       |                   |(10)CCA(Multiple-Services-CC (           |
<       |                   |        Granted-Units(Total-Octets),     |
<       |                   |        Service-Id 3, Rating-Group 2,    |
<       |                   |        Validity-time,                   |
<       |                   |        G-S-U-Pool-Reference(Pool-Id 2,  |
<       |                   |          Multiplier 2)),                |
<       |                   |        Multiple-Services-CC (           |
<       |                   |        Granted-Units(Total-Octets),     |
<       |                   |        Service-Id 4, Rating-Group 3     |
<       |                   |        Validity-Time,                   |
<       |                   |        Final-Unit-Ind.(Terminate),      |
<       |                   |        G-S-U-Pool-Reference(Pool-Id 2,  |
<       |                   |          Multiplier 5)))                |
<       |                   |<----------------------------------------|
<       :                   :                                         :
<       :                   :                                         :
<       | +--------------+  |                                         |
<       | |Validity time |  |(11)CCR(update,                          |
<       | |expires for   |  |        Multiple-Services-CC (           |
<       | |Service-Id    |  |        Requested-Unit(),                |
<       | | 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)))               |
<       |                   |<----------------------------------------|
<       :                   :                                         :
<       :                   :                                         :
< 
< 
< 
< 
< 
< 
---
>                       (CC client)
>      |(1)User logon      |                                         |
>      |------------------>|(2)CCR(initial, Service-Id access,       |
>      |                   |        Access specific AVPs,            |
>      |                   |        Multiple-Service-Indicator)      |
>      |                   |---------------------------------------->|
>      |                   |(3)CCA(Multiple-Services-CC (            |
>      |                   |        Granted-Units(Total-Octets),     |
>      |                   |        Service-Id access,               |
>      |                   |        Validity-time,                   |
>      |                   |        G-S-U-Pool-Reference(Pool-Id 1,  |
>      |                   |          Multiplier 10)))               |
>      |                   |<----------------------------------------|
>      :                   :                                         :
>      |(4)Service-Request (Service 1)                               |
>      |------------------>|(5)CCR(update, Multiple-Services-CC(     |
>      |                   |        Requested-Units(), Service-Id 1, |
>      |                   |        Rating-Group 1))                 |
>      |                   |---------------------------------------->|
>      |                   |(6)CCA(Multiple-Services-CC (            |
>      |                   |        Granted-Units(Time),             |
>      |                   |        Rating-Group 1,                  |
>      |                   |        G-S-U-Pool-Reference(Pool-Id 1,  |
>      |                   |          Multiplier 1)))                |
>      |                   |<----------------------------------------|
>      :                   :                                         :
>      |(7)Service-Request (Service 2)                               |
>      |------------------>|                                         |
>      :                   :                                         :
>      :                   :                                         :
>      |(8)Service-Request (Service 3&4)                             |
>      |------------------>|(9)CCR(update, Multiple-Services-CC (    |
>      |                   |        Requested-Units(), Service-Id 3, |
>      |                   |        Rating-Group 2),                 |
>      |                   |        Multiple-Services-CC (           |
>      |                   |        Requested-Units(), Service-Id 4, |
>      |                   |        Rating-Group 3))                 |
>      |                   |---------------------------------------->|
>      |                   |(10)CCA(Multiple-Services-CC (           |
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016             [Page 107]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
>      |                   |        Granted-Units(Total-Octets),     |
>      |                   |        Service-Id 3, Rating-Group 2,    |
>      |                   |        Validity-time,                   |
>      |                   |        G-S-U-Pool-Reference(Pool-Id 2,  |
>      |                   |          Multiplier 2)),                |
>      |                   |        Multiple-Services-CC (           |
>      |                   |        Granted-Units(Total-Octets),     |
>      |                   |        Service-Id 4, Rating-Group 3     |
>      |                   |        Validity-Time,                   |
>      |                   |        Final-Unit-Ind.(Terminate),      |
>      |                   |        G-S-U-Pool-Reference(Pool-Id 2,  |
>      |                   |          Multiplier 5)))                |
>      |                   |<----------------------------------------|
>      :                   :                                         :
>      :                   :                                         :
>      | +--------------+  |                                         |
>      | |Validity time |  |(11)CCR(update,                          |
>      | |expires for   |  |        Multiple-Services-CC (           |
>      | |Service-Id    |  |        Requested-Unit(),                |
>      | | 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-Unit(),                |
>      | |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))                   |
>      |                   |<----------------------------------------|
>      :                   :                                         :
>      :                   :                                         :
>      |(15) User logoff   |                                         |
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016             [Page 108]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
>      |------------------>|(16)CCR(term,                            |
>      |                   |       Multiple-Services-CC (            |
>      |                   |        Used-Units(In-Octets,Out-Octets),|
>      |                   |        Service-Id access),              |
>      |                   |       Multiple-Services-CC (            |
>      |                   |        Used-Units(Time),                |
>      |                   |        Service-Id 1, Rating-Group 1),   |
>      |                   |       Multiple-Services-CC (            |
>      |                   |        Used-Units(Time),                |
>      |                   |        Service-Id 2, Rating-Group 1))   |
>      |                   |---------------------------------------->|
>      |                   |(17)CCA(term)                            |
>      |                   |<----------------------------------------|
6048,6087c6067,6068
< 
< 
< Hakala, et al.              Standards Track                   [Page 108]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
<       | +--------------+  |                                         |
<       | |Total Quota   |  |(13)CCR(update,                          |
<       | |elapses for   |  |       Multiple-Services-CC (            |
<       | |pool 2:       |  |        Requested-Unit(),                |
<       | |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))                   |
<       |                   |<----------------------------------------|
<       :                   :                                         :
<       :                   :                                         :
<       |(15) User logoff   |                                         |
<       |------------------>|(16)CCR(term,                            |
<       |                   |       Multiple-Services-CC (            |
<       |                   |        Used-Units(In-Octets,Out-Octets),|
<       |                   |        Service-Id access),              |
<       |                   |       Multiple-Services-CC (            |
<       |                   |        Used-Units(Time),                |
<       |                   |        Service-Id 1, Rating-Group 1),   |
<       |                   |       Multiple-Services-CC (            |
<       |                   |        Used-Units(Time),                |
<       |                   |        Service-Id 2, Rating-Group 1))   |
<       |                   |---------------------------------------->|
<       |                   |(17)CCA(term)                            |
<       |                   |<----------------------------------------|
< 
<       Figure A.9: Flow example independent credit-control of multiple
<                   services in a  credit-control (sub-)Session
---
>       Figure 18: Flow example independent credit-control of multiple
>                 services in a credit-control (sub-)Session
6103,6110d6083
< 
< 
< 
< Hakala, et al.              Standards Track                   [Page 109]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
6121,6123c6094,6096
<    (i.e., pool 1).  It rates the request according to Service-
<    Id/Rating-Group and updates the existing reservation by requesting
<    more credit.  Suppose that the server reserves $5 more (now the
---
>    (i.e., pool 1).  It rates the request according to Service- Id/
>    Rating-Group and updates the existing reservation by requesting more
>    credit.  Suppose that the server reserves $5 more (now the
6127a6101,6108
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016             [Page 109]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
6159,6166d6139
< 
< 
< 
< Hakala, et al.              Standards Track                   [Page 110]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
6182a6156,6164
> 
> 
> 
> 
> Bertz, et al.           Expires December 15, 2016             [Page 110]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
> 
> 
6198,6203c6180,6185
<    Service 3 (13).  This message contains two instances of the
<    Multiple-Services-Credit-Control AVP to report the units used by
<    Services 3 and 4.  The server deducts the last $5 from the user's
<    account (pool 2) and returns the answer with Result-Code 4011 in the
<    Multiple-Services-Credit-Control AVP to indicate that Service 3 can
<    continue without credit-control (14).
---
>    Service 3 (13).  This message contains two instances of the Multiple-
>    Services-Credit-Control AVP to report the units used by Services 3
>    and 4.  The server deducts the last $5 from the user's account (pool
>    2) and returns the answer with Result-Code 4011 in the Multiple-
>    Services-Credit-Control AVP to indicate that Service 3 can continue
>    without credit-control (14).
6213,6222d6194
< 
< 
< 
< 
< 
< Hakala, et al.              Standards Track                   [Page 111]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
6227,6258c6199
< Authors' Addresses
< 
<    Harri Hakala
<    Oy L M Ericsson Ab
<    Joukahaisenkatu 1
<    20520 Turku
<    Finland
< 
<    Phone: +358 2 265 3722
<    EMail: [email-masked]
< 
< 
<    Leena Mattila
<    Oy L M Ericsson Ab
<    Joukahaisenkatu 1
<    20520 Turku
<    Finland
< 
<    Phone: +358 2 265 3731
<    EMail: [email-masked]
< 
< 
<    Juha-Pekka Koskinen
<    Nokia Networks
<    Hatanpaanvaltatie 30
<    33100 Tampere
<    Finland
< 
<    Phone: +358 7180 74027
<    EMail: [email-masked]
< 
< 
---
> Appendix C.  Changes relative to RFC4006
6259a6201
>    The following changes were made relative to RFC4006:
6260a6203
>       Update references to obsolete RFC 3588 to refer to RFC 6733.
6261a6205
>       Update references to obsolete RFC 4005 to refer to RFC 7155.
6262a6207,6208
>       Update reference to "IPsec or TLS" to be "TLS/TCP, DTLS/SCTP or
>       IPsec"
6263a6210
>       Update AVP per Errata ID 3329
6269,6274c6216
< 
< 
< 
< 
< 
< Hakala, et al.              Standards Track                   [Page 112]
---
> Bertz, et al.           Expires December 15, 2016             [Page 111]
6276,6296c6218
< RFC 4006          Diameter Credit-Control Application        August 2005
< 
< 
<    Marco Stura
<    Nokia Networks
<    Hiomotie 32
<    00380 Helsinki
<    Finland
< 
<    Phone: +358 7180 64308
<    EMail: [email-masked]
< 
< 
<    John Loughney
<    Nokia Research Center
<    Itamerenkatu 11-13
<    00180 Helsinki
<    Finland
< 
<    Phone: +358 50 483 642
<    EMail: [email-masked]
---
> Internet-Draft     Diameter Credit-Control Application         June 2016
6298a6221
> Authors' Addresses
6299a6223,6227
>    Lyle Bertz (editor)
>    Sprint
>    6220 Sprint Parkway
>    Overland Park, KS  66251
>    United States
6300a6229
>    Email: [email-masked]
6302a6232,6236
>    David Dolson (editor)
>    Sandvine
>    408 Albert Street
>    Waterloo, ON  N2L 3V3
>    Canada
6303a6238,6239
>    Phone: +1 519 880 2400
>    Email: [email-masked]
6305a6242,6246
>    Yuval Lifshitz (editor)
>    Sandvine
>    408 Albert Street
>    Waterloo, ON  N2L 3V3
>    Canada
6306a6248,6249
>    Phone: +1 519 880 2400
>    Email: [email-masked]
6308a6252,6256
>    Harri Hakala
>    Oy L M Ericsson Ab
>    Joukahaisenkatu 1
>    Turku  20520
>    Finland
6309a6258,6259
>    Phone: +358 2 265 3722
>    Email: [email-masked]
6321a6272,6274
> Bertz, et al.           Expires December 15, 2016             [Page 112]
> 
> Internet-Draft     Diameter Credit-Control Application         June 2016
6323a6277,6281
>    Leena Mattila
>    Oy L M Ericsson Ab
>    Joukahaisenkatu 1
>    Turku  20520
>    Finland
6324a6283,6284
>    Phone: +358 2 265 3731
>    Email: [email-masked]
6326a6287,6291
>    Juha-Pekka Koskinen
>    Nokia Networks
>    Hatanpaanvaltatie 30
>    Tampere  33100
>    Finland
6327a6293,6294
>    Phone: +358 7180 74027
>    Email: [email-masked]
6330,6332c6297,6301
< Hakala, et al.              Standards Track                   [Page 113]
< 
< RFC 4006          Diameter Credit-Control Application        August 2005
---
>    Marco Stura
>    Nokia Networks
>    Hiomotie 32
>    Tampere  00380
>    Helsinki
6333a6303,6304
>    Phone: +358 7180 64308
>    Email: [email-masked]
6335d6305
< Full Copyright Statement
6337c6307,6311
<    Copyright (C) The Internet Society (2005).
---
>    John Loughney
>    Nokia Research Center
>    Itamerenkatu 11-13
>    Tampere  00180
>    Helsinki
6339,6341c6313,6314
<    This document is subject to the rights, licenses and restrictions
<    contained in BCP 78, and except as set forth therein, the authors
<    retain all their rights.
---
>    Phone: +358 50 483 642
>    Email: [email-masked]
6343,6349d6315
<    This document and the information contained herein are provided on an
<    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
<    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
<    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
<    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
<    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
<    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
6351d6316
< Intellectual Property
6353,6360d6317
<    The IETF takes no position regarding the validity or scope of any
<    Intellectual Property Rights or other rights that might be claimed to
<    pertain to the implementation or use of the technology described in
<    this document or the extent to which any license under such rights
<    might or might not be available; nor does it represent that it has
<    made any independent effort to identify any such rights.  Information
<    on the procedures with respect to rights in RFC documents can be
<    found in BCP 78 and BCP 79.
6362,6367d6318
<    Copies of IPR disclosures made to the IETF Secretariat and any
<    assurances of licenses to be made available, or the result of an
<    attempt made to obtain a general license or permission for the use of
<    such proprietary rights by implementers or users of this
<    specification can be obtained from the IETF on-line IPR repository at
<    http://www.ietf.org/ipr.
6369,6373d6319
<    The IETF invites any interested party to bring to its attention any
<    copyrights, patents or patent applications, or other proprietary
<    rights that may cover technology that may be required to implement
<    this standard.  Please address the information to the IETF at ietf-
<    [email-masked].
6375d6320
< Acknowledgement
6377,6378d6321
<    Funding for the RFC Editor function is currently provided by the
<    Internet Society.
6384a6328
> Bertz, et al.           Expires December 15, 2016             [Page 113]
6386,6387d6329
< Hakala, et al.              Standards Track                   [Page 114]
<