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 < ::= < 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 --- > ::= < 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 < ::= < 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 > > > ::= < 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, > 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, > . > > [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform > Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738, > December 1994, . > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, > DOI 10.17487/RFC2119, March 1997, > . > > [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an > IANA Considerations Section in RFCs", RFC 2434, > DOI 10.17487/RFC2434, October 1998, > . > > [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", > RFC 2486, DOI 10.17487/RFC2486, January 1999, > . > > > > 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, > . > > [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 > (IPv6) Addressing Architecture", RFC 3513, > DOI 10.17487/RFC3513, April 2003, > . > > [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and > Accounting (AAA) Transport Profile", RFC 3539, > DOI 10.17487/RFC3539, June 2003, > . > > [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, > . > > [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, > Ed., "Diameter Base Protocol", RFC 6733, > DOI 10.17487/RFC6733, October 2012, > . > > [RFC7155] Zorn, G., Ed., "Diameter Network Access Server > Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, > . > > [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, > . 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, > . 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, > . 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: Harri.Hakala@ericsson.com < < < Leena Mattila < Oy L M Ericsson Ab < Joukahaisenkatu 1 < 20520 Turku < Finland < < Phone: +358 2 265 3731 < EMail: Leena.Mattila@ericsson.com < < < Juha-Pekka Koskinen < Nokia Networks < Hatanpaanvaltatie 30 < 33100 Tampere < Finland < < Phone: +358 7180 74027 < EMail: juha-pekka.koskinen@nokia.com < < --- > 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: marco.stura@nokia.com < < < John Loughney < Nokia Research Center < Itamerenkatu 11-13 < 00180 Helsinki < Finland < < Phone: +358 50 483 642 < EMail: John.Loughney@nokia.com --- > 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: lbertz551144@gmail.com 6302a6232,6236 > David Dolson (editor) > Sandvine > 408 Albert Street > Waterloo, ON N2L 3V3 > Canada 6303a6238,6239 > Phone: +1 519 880 2400 > Email: ddolson@sandvine.com 6305a6242,6246 > Yuval Lifshitz (editor) > Sandvine > 408 Albert Street > Waterloo, ON N2L 3V3 > Canada 6306a6248,6249 > Phone: +1 519 880 2400 > Email: ylifshitz@sandvine.com 6308a6252,6256 > Harri Hakala > Oy L M Ericsson Ab > Joukahaisenkatu 1 > Turku 20520 > Finland 6309a6258,6259 > Phone: +358 2 265 3722 > Email: Harri.Hakala@ericsson.com 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: Leena.Mattila@ericsson.com 6326a6287,6291 > Juha-Pekka Koskinen > Nokia Networks > Hatanpaanvaltatie 30 > Tampere 33100 > Finland 6327a6293,6294 > Phone: +358 7180 74027 > Email: juha-pekka.koskinen@nokia.com 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: marco.stura@nokia.com 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: John.Loughney@nokia.com 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- < ipr@ietf.org. 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] <