draft-ietf-dime-rfc4006bis-08.txt   draft-ietf-dime-rfc4006bis-09.txt 
Network Working Group L. Bertz, Ed. Network Working Group L. Bertz, Ed.
Internet-Draft Sprint Internet-Draft Sprint
Obsoletes: 4006 (if approved) D. Dolson, Ed. Obsoletes: 4006 (if approved) D. Dolson, Ed.
Intended status: Standards Track Y. Lifshitz, Ed. Intended status: Standards Track Y. Lifshitz, Ed.
Expires: November 19, 2018 Sandvine Expires: December 13, 2018 Sandvine
May 18, 2018 June 11, 2018
Diameter Credit-Control Application Diameter Credit-Control Application
draft-ietf-dime-rfc4006bis-08 draft-ietf-dime-rfc4006bis-09
Abstract Abstract
This document specifies a Diameter application that can be used to This document specifies a Diameter application that can be used to
implement real-time credit-control for a variety of end user services implement real-time credit-control for a variety of end user services
such as network access, Session Initiation Protocol (SIP) services, such as network access, Session Initiation Protocol (SIP) services,
messaging services, and download services. The Diameter Credit- messaging services, and download services. The Diameter Credit-
Control application as defined in this document obsoletes RFC4006, Control application as defined in this document obsoletes RFC4006,
and it must be supported by all new Diameter Credit-Control and it must be supported by all new Diameter Credit-Control
Application implementations. Application implementations.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 19, 2018. This Internet-Draft will expire on December 13, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 45 skipping to change at page 2, line 45
4.1.3. Handling of Unsupported/Incorrect Rating Input . . . 16 4.1.3. Handling of Unsupported/Incorrect Rating Input . . . 16
4.1.4. RADIUS Vendor-Specific Rating Attributes . . . . . . 16 4.1.4. RADIUS Vendor-Specific Rating Attributes . . . . . . 16
5. Session Based Credit-Control . . . . . . . . . . . . . . . . 16 5. Session Based Credit-Control . . . . . . . . . . . . . . . . 16
5.1. General Principles . . . . . . . . . . . . . . . . . . . 16 5.1. General Principles . . . . . . . . . . . . . . . . . . . 16
5.1.1. Basic Tariff-Time Change Support . . . . . . . . . . 17 5.1.1. Basic Tariff-Time Change Support . . . . . . . . . . 17
5.1.2. Credit-Control for Multiple Services within a 5.1.2. Credit-Control for Multiple Services within a
(sub-)Session . . . . . . . . . . . . . . . . . . . . 18 (sub-)Session . . . . . . . . . . . . . . . . . . . . 18
5.2. First Interrogation . . . . . . . . . . . . . . . . . . . 22 5.2. First Interrogation . . . . . . . . . . . . . . . . . . . 22
5.2.1. First Interrogation after Authorization and 5.2.1. First Interrogation after Authorization and
Authentication . . . . . . . . . . . . . . . . . . . 24 Authentication . . . . . . . . . . . . . . . . . . . 24
5.2.2. Authorization Messages for First Interrogation . . . 25 5.2.2. First Interrogation Included with Authorization
Messages . . . . . . . . . . . . . . . . . . . . . . 25
5.3. Intermediate Interrogation . . . . . . . . . . . . . . . 28 5.3. Intermediate Interrogation . . . . . . . . . . . . . . . 28
5.4. Final Interrogation . . . . . . . . . . . . . . . . . . . 30 5.4. Final Interrogation . . . . . . . . . . . . . . . . . . . 30
5.5. Server-Initiated Credit Re-Authorization . . . . . . . . 31 5.5. Server-Initiated Credit Re-Authorization . . . . . . . . 31
5.6. Graceful Service Termination . . . . . . . . . . . . . . 33 5.6. Graceful Service Termination . . . . . . . . . . . . . . 33
5.6.1. Terminate Action . . . . . . . . . . . . . . . . . . 36 5.6.1. Terminate Action . . . . . . . . . . . . . . . . . . 36
5.6.2. Redirect Action . . . . . . . . . . . . . . . . . . . 37 5.6.2. Redirect Action . . . . . . . . . . . . . . . . . . . 37
5.6.3. Restrict Access Action . . . . . . . . . . . . . . . 39 5.6.3. Restrict Access Action . . . . . . . . . . . . . . . 39
5.6.4. Usage of the Server-Initiated Credit Re-Authorization 40 5.6.4. Usage of the Server-Initiated Credit Re-Authorization 40
5.7. Failure Procedures . . . . . . . . . . . . . . . . . . . 40 5.7. Failure Procedures . . . . . . . . . . . . . . . . . . . 40
6. One Time Event . . . . . . . . . . . . . . . . . . . . . . . 43 6. One Time Event . . . . . . . . . . . . . . . . . . . . . . . 43
6.1. Service Price Enquiry . . . . . . . . . . . . . . . . . . 44 6.1. Service Price Enquiry . . . . . . . . . . . . . . . . . . 44
6.2. Balance Check . . . . . . . . . . . . . . . . . . . . . . 45 6.2. Balance Check . . . . . . . . . . . . . . . . . . . . . . 45
6.3. Direct Debiting . . . . . . . . . . . . . . . . . . . . . 45 6.3. Direct Debiting . . . . . . . . . . . . . . . . . . . . . 45
6.4. Refund . . . . . . . . . . . . . . . . . . . . . . . . . 46 6.4. Refund . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.5. Failure Procedure . . . . . . . . . . . . . . . . . . . . 47 6.5. Failure Procedure . . . . . . . . . . . . . . . . . . . . 47
7. Credit-Control Application State Machine . . . . . . . . . . 49 7. Credit-Control Application State Machine . . . . . . . . . . 49
8. Credit-Control AVPs . . . . . . . . . . . . . . . . . . . . . 57 8. Credit-Control AVPs . . . . . . . . . . . . . . . . . . . . . 57
8.1. CC-Correlation-Id AVP . . . . . . . . . . . . . . . . . . 60 8.1. CC-Correlation-Id AVP . . . . . . . . . . . . . . . . . . 60
8.2. CC-Request-Number AVP . . . . . . . . . . . . . . . . . . 60 8.2. CC-Request-Number AVP . . . . . . . . . . . . . . . . . . 60
8.3. CC-Request-Type AVP . . . . . . . . . . . . . . . . . . . 60 8.3. CC-Request-Type AVP . . . . . . . . . . . . . . . . . . . 61
8.4. CC-Session-Failover AVP . . . . . . . . . . . . . . . . . 61 8.4. CC-Session-Failover AVP . . . . . . . . . . . . . . . . . 61
8.5. CC-Sub-Session-Id AVP . . . . . . . . . . . . . . . . . . 61 8.5. CC-Sub-Session-Id AVP . . . . . . . . . . . . . . . . . . 62
8.6. Check-Balance-Result AVP . . . . . . . . . . . . . . . . 62 8.6. Check-Balance-Result AVP . . . . . . . . . . . . . . . . 62
8.7. Cost-Information AVP . . . . . . . . . . . . . . . . . . 62 8.7. Cost-Information AVP . . . . . . . . . . . . . . . . . . 63
8.8. Unit-Value AVP . . . . . . . . . . . . . . . . . . . . . 63 8.8. Unit-Value AVP . . . . . . . . . . . . . . . . . . . . . 63
8.9. Exponent AVP . . . . . . . . . . . . . . . . . . . . . . 63 8.9. Exponent AVP . . . . . . . . . . . . . . . . . . . . . . 64
8.10. Value-Digits AVP . . . . . . . . . . . . . . . . . . . . 63 8.10. Value-Digits AVP . . . . . . . . . . . . . . . . . . . . 64
8.11. Currency-Code AVP . . . . . . . . . . . . . . . . . . . . 63 8.11. Currency-Code AVP . . . . . . . . . . . . . . . . . . . . 64
8.12. Cost-Unit AVP . . . . . . . . . . . . . . . . . . . . . . 64 8.12. Cost-Unit AVP . . . . . . . . . . . . . . . . . . . . . . 64
8.13. Credit-Control AVP . . . . . . . . . . . . . . . . . . . 64 8.13. Credit-Control AVP . . . . . . . . . . . . . . . . . . . 64
8.14. Credit-Control-Failure-Handling AVP . . . . . . . . . . . 64 8.14. Credit-Control-Failure-Handling AVP . . . . . . . . . . . 65
8.15. Direct-Debiting-Failure-Handling AVP . . . . . . . . . . 65 8.15. Direct-Debiting-Failure-Handling AVP . . . . . . . . . . 66
8.16. Multiple-Services-Credit-Control AVP . . . . . . . . . . 66 8.16. Multiple-Services-Credit-Control AVP . . . . . . . . . . 67
8.17. Granted-Service-Unit AVP . . . . . . . . . . . . . . . . 67 8.17. Granted-Service-Unit AVP . . . . . . . . . . . . . . . . 68
8.18. Requested-Service-Unit AVP . . . . . . . . . . . . . . . 68 8.18. Requested-Service-Unit AVP . . . . . . . . . . . . . . . 69
8.19. Used-Service-Unit AVP . . . . . . . . . . . . . . . . . . 68 8.19. Used-Service-Unit AVP . . . . . . . . . . . . . . . . . . 69
8.20. Tariff-Time-Change AVP . . . . . . . . . . . . . . . . . 69 8.20. Tariff-Time-Change AVP . . . . . . . . . . . . . . . . . 70
8.21. CC-Time AVP . . . . . . . . . . . . . . . . . . . . . . . 69 8.21. CC-Time AVP . . . . . . . . . . . . . . . . . . . . . . . 70
8.22. CC-Money AVP . . . . . . . . . . . . . . . . . . . . . . 69 8.22. CC-Money AVP . . . . . . . . . . . . . . . . . . . . . . 70
8.23. CC-Total-Octets AVP . . . . . . . . . . . . . . . . . . . 70 8.23. CC-Total-Octets AVP . . . . . . . . . . . . . . . . . . . 70
8.24. CC-Input-Octets AVP . . . . . . . . . . . . . . . . . . . 70 8.24. CC-Input-Octets AVP . . . . . . . . . . . . . . . . . . . 70
8.25. CC-Output-Octets AVP . . . . . . . . . . . . . . . . . . 70 8.25. CC-Output-Octets AVP . . . . . . . . . . . . . . . . . . 71
8.26. CC-Service-Specific-Units AVP . . . . . . . . . . . . . . 70 8.26. CC-Service-Specific-Units AVP . . . . . . . . . . . . . . 71
8.27. Tariff-Change-Usage AVP . . . . . . . . . . . . . . . . . 70 8.27. Tariff-Change-Usage AVP . . . . . . . . . . . . . . . . . 71
8.28. Service-Identifier AVP . . . . . . . . . . . . . . . . . 71 8.28. Service-Identifier AVP . . . . . . . . . . . . . . . . . 72
8.29. Rating-Group AVP . . . . . . . . . . . . . . . . . . . . 71 8.29. Rating-Group AVP . . . . . . . . . . . . . . . . . . . . 72
8.30. G-S-U-Pool-Reference AVP . . . . . . . . . . . . . . . . 71 8.30. G-S-U-Pool-Reference AVP . . . . . . . . . . . . . . . . 72
8.31. G-S-U-Pool-Identifier AVP . . . . . . . . . . . . . . . . 72 8.31. G-S-U-Pool-Identifier AVP . . . . . . . . . . . . . . . . 73
8.32. CC-Unit-Type AVP . . . . . . . . . . . . . . . . . . . . 72 8.32. CC-Unit-Type AVP . . . . . . . . . . . . . . . . . . . . 73
8.33. Validity-Time AVP . . . . . . . . . . . . . . . . . . . . 72 8.33. Validity-Time AVP . . . . . . . . . . . . . . . . . . . . 73
8.34. Final-Unit-Indication AVP . . . . . . . . . . . . . . . . 73 8.34. Final-Unit-Indication AVP . . . . . . . . . . . . . . . . 74
8.35. Final-Unit-Action AVP . . . . . . . . . . . . . . . . . . 74 8.35. Final-Unit-Action AVP . . . . . . . . . . . . . . . . . . 75
8.36. Restriction-Filter-Rule AVP . . . . . . . . . . . . . . . 75 8.36. Restriction-Filter-Rule AVP . . . . . . . . . . . . . . . 76
8.37. Redirect-Server AVP . . . . . . . . . . . . . . . . . . . 75 8.37. Redirect-Server AVP . . . . . . . . . . . . . . . . . . . 76
8.38. Redirect-Address-Type AVP . . . . . . . . . . . . . . . . 76 8.38. Redirect-Address-Type AVP . . . . . . . . . . . . . . . . 76
8.39. Redirect-Server-Address AVP . . . . . . . . . . . . . . . 76 8.39. Redirect-Server-Address AVP . . . . . . . . . . . . . . . 77
8.40. Multiple-Services-Indicator AVP . . . . . . . . . . . . . 76 8.40. Multiple-Services-Indicator AVP . . . . . . . . . . . . . 77
8.41. Requested-Action AVP . . . . . . . . . . . . . . . . . . 77 8.41. Requested-Action AVP . . . . . . . . . . . . . . . . . . 78
8.42. Service-Context-Id AVP . . . . . . . . . . . . . . . . . 78 8.42. Service-Context-Id AVP . . . . . . . . . . . . . . . . . 78
8.43. Service-Parameter-Info AVP . . . . . . . . . . . . . . . 78 8.43. Service-Parameter-Info AVP . . . . . . . . . . . . . . . 79
8.44. Service-Parameter-Type AVP . . . . . . . . . . . . . . . 79 8.44. Service-Parameter-Type AVP . . . . . . . . . . . . . . . 80
8.45. Service-Parameter-Value AVP . . . . . . . . . . . . . . . 79 8.45. Service-Parameter-Value AVP . . . . . . . . . . . . . . . 80
8.46. Subscription-Id AVP . . . . . . . . . . . . . . . . . . . 79 8.46. Subscription-Id AVP . . . . . . . . . . . . . . . . . . . 80
8.47. Subscription-Id-Type AVP . . . . . . . . . . . . . . . . 80 8.47. Subscription-Id-Type AVP . . . . . . . . . . . . . . . . 80
8.48. Subscription-Id-Data AVP . . . . . . . . . . . . . . . . 80 8.48. Subscription-Id-Data AVP . . . . . . . . . . . . . . . . 81
8.49. User-Equipment-Info AVP . . . . . . . . . . . . . . . . . 81 8.49. User-Equipment-Info AVP . . . . . . . . . . . . . . . . . 81
8.50. User-Equipment-Info-Type AVP . . . . . . . . . . . . . . 81 8.50. User-Equipment-Info-Type AVP . . . . . . . . . . . . . . 82
8.51. User-Equipment-Info-Value AVP . . . . . . . . . . . . . . 82 8.51. User-Equipment-Info-Value AVP . . . . . . . . . . . . . . 82
8.52. User-Equipment-Info-Extension AVP . . . . . . . . . . . . 82 8.52. User-Equipment-Info-Extension AVP . . . . . . . . . . . . 82
8.53. User-Equipment-Info-IMEISV AVP . . . . . . . . . . . . . 82 8.53. User-Equipment-Info-IMEISV AVP . . . . . . . . . . . . . 83
8.54. User-Equipment-Info-MAC AVP . . . . . . . . . . . . . . . 82 8.54. User-Equipment-Info-MAC AVP . . . . . . . . . . . . . . . 83
8.55. User-Equipment-Info-EUI64 AVP . . . . . . . . . . . . . . 82 8.55. User-Equipment-Info-EUI64 AVP . . . . . . . . . . . . . . 83
8.56. User-Equipment-Info-ModifiedEUI64 AVP . . . . . . . . . . 83 8.56. User-Equipment-Info-ModifiedEUI64 AVP . . . . . . . . . . 83
8.57. User-Equipment-Info-IMEI AVP . . . . . . . . . . . . . . 83 8.57. User-Equipment-Info-IMEI AVP . . . . . . . . . . . . . . 84
8.58. Subscription-Id-Extension AVP . . . . . . . . . . . . . . 83 8.58. Subscription-Id-Extension AVP . . . . . . . . . . . . . . 84
8.59. Subscription-Id-E164 AVP . . . . . . . . . . . . . . . . 84 8.59. Subscription-Id-E164 AVP . . . . . . . . . . . . . . . . 84
8.60. Subscription-Id-IMSI AVP . . . . . . . . . . . . . . . . 84 8.60. Subscription-Id-IMSI AVP . . . . . . . . . . . . . . . . 85
8.61. Subscription-Id-SIP-URI AVP . . . . . . . . . . . . . . . 84 8.61. Subscription-Id-SIP-URI AVP . . . . . . . . . . . . . . . 85
8.62. Subscription-Id-NAI AVP . . . . . . . . . . . . . . . . . 84 8.62. Subscription-Id-NAI AVP . . . . . . . . . . . . . . . . . 85
8.63. Subscription-Id-Private AVP . . . . . . . . . . . . . . . 84 8.63. Subscription-Id-Private AVP . . . . . . . . . . . . . . . 85
8.64. Redirect-Server-Extension AVP . . . . . . . . . . . . . . 84 8.64. Redirect-Server-Extension AVP . . . . . . . . . . . . . . 85
8.65. Redirect-Address-IPAddress AVP . . . . . . . . . . . . . 85 8.65. Redirect-Address-IPAddress AVP . . . . . . . . . . . . . 86
8.66. Redirect-Address-URL AVP . . . . . . . . . . . . . . . . 85 8.66. Redirect-Address-URL AVP . . . . . . . . . . . . . . . . 86
8.67. Redirect-Address-SIP-URI AVP . . . . . . . . . . . . . . 85 8.67. Redirect-Address-SIP-URI AVP . . . . . . . . . . . . . . 86
8.68. QoS-Final-Unit-Indication AVP . . . . . . . . . . . . . . 86 8.68. QoS-Final-Unit-Indication AVP . . . . . . . . . . . . . . 86
9. Result Code AVP Values . . . . . . . . . . . . . . . . . . . 87 9. Result Code AVP Values . . . . . . . . . . . . . . . . . . . 88
9.1. Transient Failures . . . . . . . . . . . . . . . . . . . 87 9.1. Transient Failures . . . . . . . . . . . . . . . . . . . 88
9.2. Permanent Failures . . . . . . . . . . . . . . . . . . . 88 9.2. Permanent Failures . . . . . . . . . . . . . . . . . . . 89
10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . 88 10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . 89
10.1. Credit-Control AVP Table . . . . . . . . . . . . . . . . 89 10.1. Credit-Control AVP Table . . . . . . . . . . . . . . . . 90
10.2. Re-Auth-Request/Answer AVP Table . . . . . . . . . . . . 90 10.2. Re-Auth-Request/Answer AVP Table . . . . . . . . . . . . 91
11. RADIUS/Diameter Credit-Control Interworking Model . . . . . . 90 11. RADIUS/Diameter Credit-Control Interworking Model . . . . . . 91
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 94
12.1. Application Identifier . . . . . . . . . . . . . . . . . 94 12.1. Application Identifier . . . . . . . . . . . . . . . . . 95
12.2. Command Codes . . . . . . . . . . . . . . . . . . . . . 94 12.2. Command Codes . . . . . . . . . . . . . . . . . . . . . 95
12.3. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . 94 12.3. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . 95
12.4. Result-Code AVP Values . . . . . . . . . . . . . . . . . 95 12.4. Result-Code AVP Values . . . . . . . . . . . . . . . . . 96
12.5. CC-Request-Type AVP . . . . . . . . . . . . . . . . . . 95 12.5. CC-Request-Type AVP . . . . . . . . . . . . . . . . . . 96
12.6. CC-Session-Failover AVP . . . . . . . . . . . . . . . . 95 12.6. CC-Session-Failover AVP . . . . . . . . . . . . . . . . 96
12.7. CC-Unit-Type AVP . . . . . . . . . . . . . . . . . . . . 95 12.7. CC-Unit-Type AVP . . . . . . . . . . . . . . . . . . . . 96
12.8. Check-Balance-Result AVP . . . . . . . . . . . . . . . . 95 12.8. Check-Balance-Result AVP . . . . . . . . . . . . . . . . 96
12.9. Credit-Control AVP . . . . . . . . . . . . . . . . . . . 95 12.9. Credit-Control AVP . . . . . . . . . . . . . . . . . . . 96
12.10. Credit-Control-Failure-Handling AVP . . . . . . . . . . 96 12.10. Credit-Control-Failure-Handling AVP . . . . . . . . . . 97
12.11. Direct-Debiting-Failure-Handling AVP . . . . . . . . . . 96 12.11. Direct-Debiting-Failure-Handling AVP . . . . . . . . . . 97
12.12. Final-Unit-Action AVP . . . . . . . . . . . . . . . . . 96 12.12. Final-Unit-Action AVP . . . . . . . . . . . . . . . . . 97
12.13. Multiple-Services-Indicator AVP . . . . . . . . . . . . 96 12.13. Multiple-Services-Indicator AVP . . . . . . . . . . . . 97
12.14. Redirect-Address-Type AVP . . . . . . . . . . . . . . . 96 12.14. Redirect-Address-Type AVP . . . . . . . . . . . . . . . 97
12.15. Requested-Action AVP . . . . . . . . . . . . . . . . . . 96 12.15. Requested-Action AVP . . . . . . . . . . . . . . . . . . 97
12.16. Subscription-Id-Type AVP . . . . . . . . . . . . . . . . 97 12.16. Subscription-Id-Type AVP . . . . . . . . . . . . . . . . 98
12.17. Tariff-Change-Usage AVP . . . . . . . . . . . . . . . . 97 12.17. Tariff-Change-Usage AVP . . . . . . . . . . . . . . . . 98
12.18. User-Equipment-Info-Type AVP . . . . . . . . . . . . . . 97 12.18. User-Equipment-Info-Type AVP . . . . . . . . . . . . . . 98
13. Credit-Control Application Related Parameters . . . . . . . . 97 13. Credit-Control Application Related Parameters . . . . . . . . 98
14. Security Considerations . . . . . . . . . . . . . . . . . . . 98 14. Security Considerations . . . . . . . . . . . . . . . . . . . 99
14.1. Direct Connection with Redirects . . . . . . . . . . . . 99 14.1. Direct Connection with Redirects . . . . . . . . . . . . 100
15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 99 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 100
15.1. Privacy Sensitive AVPs . . . . . . . . . . . . . . . . . 100 15.1. Privacy Sensitive AVPs . . . . . . . . . . . . . . . . . 101
15.2. Data Minimization . . . . . . . . . . . . . . . . . . . 101 15.2. Data Minimization . . . . . . . . . . . . . . . . . . . 102
15.3. Diameter Agents . . . . . . . . . . . . . . . . . . . . 102 15.3. Diameter Agents . . . . . . . . . . . . . . . . . . . . 103
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 102 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 103
16.1. Normative References . . . . . . . . . . . . . . . . . . 102 16.1. Normative References . . . . . . . . . . . . . . . . . . 103
16.2. Informative References . . . . . . . . . . . . . . . . . 104 16.2. Informative References . . . . . . . . . . . . . . . . . 106
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 105 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 106
Appendix B. Credit-Control Sequences . . . . . . . . . . . . . . 106 Appendix B. Credit-Control Sequences . . . . . . . . . . . . . . 107
B.1. Flow I . . . . . . . . . . . . . . . . . . . . . . . . . 106 B.1. Flow I . . . . . . . . . . . . . . . . . . . . . . . . . 107
B.2. Flow II . . . . . . . . . . . . . . . . . . . . . . . . . 108 B.2. Flow II . . . . . . . . . . . . . . . . . . . . . . . . . 110
B.3. Flow III . . . . . . . . . . . . . . . . . . . . . . . . 110 B.3. Flow III . . . . . . . . . . . . . . . . . . . . . . . . 112
B.4. Flow IV . . . . . . . . . . . . . . . . . . . . . . . . . 111 B.4. Flow IV . . . . . . . . . . . . . . . . . . . . . . . . . 113
B.5. Flow V . . . . . . . . . . . . . . . . . . . . . . . . . 112 B.5. Flow V . . . . . . . . . . . . . . . . . . . . . . . . . 114
B.6. Flow VI . . . . . . . . . . . . . . . . . . . . . . . . . 113 B.6. Flow VI . . . . . . . . . . . . . . . . . . . . . . . . . 116
B.7. Flow VII . . . . . . . . . . . . . . . . . . . . . . . . 114 B.7. Flow VII . . . . . . . . . . . . . . . . . . . . . . . . 117
B.8. Flow VIII . . . . . . . . . . . . . . . . . . . . . . . . 116 B.8. Flow VIII . . . . . . . . . . . . . . . . . . . . . . . . 118
B.9. Flow IX . . . . . . . . . . . . . . . . . . . . . . . . . 118 B.9. Flow IX . . . . . . . . . . . . . . . . . . . . . . . . . 120
Appendix C. Changes relative to RFC4006 . . . . . . . . . . . . 123 Appendix C. Changes relative to RFC4006 . . . . . . . . . . . . 125
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 126
1. Introduction 1. Introduction
This document specifies a Diameter application that can be used to This document specifies a Diameter application that can be used to
implement real-time credit-control for a variety of end user services implement real-time credit-control for a variety of end user services
such as network access, Session Initiation Protocol (SIP) services, such as network access, Session Initiation Protocol (SIP) services,
messaging services, and download services. It provides a general messaging services, and download services. It provides a general
solution to real-time cost and credit-control. solution to real-time cost and credit-control.
The prepaid model has been shown to be very successful, for instance, The prepaid model has been shown to be very successful, for instance,
in GSM networks, where network operators offering prepaid services in GSM networks, where network operators offering prepaid services
have experienced a substantial growth of their customer base and have experienced a substantial growth of their customer base and
revenues. Prepaid services are now cropping up in many other revenues. Prepaid services are now cropping up in many other
wireless and wire line based networks. wireless and wire line based networks.
In next generation wireless networks, additional functionality is In mobile networks, additional functionality is required beyond that
required beyond that specified in the Diameter base protocol. For specified in the Diameter base protocol [RFC6733]. For example, the
example, the 3GPP Charging and Billing requirements [TGPPCHARG] state 3GPP Charging and Billing requirements [TGPPCHARG] state that an
that an application must be able to rate service information in real- application must be able to rate service information in real-time.
time. In addition, it is necessary to check that the end user's In addition, it is necessary to check that the end user's account
account provides coverage for the requested service prior to provides coverage for the requested service prior to initiation of
initiation of that service. When an account is exhausted or expired, that service. When an account is exhausted or expired, the user must
the user must be denied the ability to compile additional chargeable be denied the ability to compile additional chargeable events.
events.
A mechanism has to be provided to allow the user to be informed of A mechanism has to be provided to allow the user to be informed of
the charges to be levied for a requested service. In addition, there the charges to be levied for a requested service. In addition, there
are services such as gaming and advertising that may credit as well are services such as gaming and advertising that may credit as well
as debit a user account. as debit a user account.
The other Diameter applications provide service specific The other Diameter applications provide service-specific
authorization, and they do not provide credit authorization for authorization, and they do not provide credit authorization for
prepaid users. The credit authorization shall be generic and prepaid users. The credit authorization shall be generic and
applicable to all the service environments required to support applicable to all the service environments required to support
prepaid services. prepaid services.
To fulfill these requirements, it is necessary to facilitate credit- To fulfill these requirements, it is necessary to facilitate credit-
control communication between the network element providing the control communication between the network element providing the
service (e.g., Network Access Server, SIP Proxy, and Application service (e.g., Network Access Server, SIP Proxy, and Application
Server) and a credit-control server. Server) and a credit-control server.
The scope of this specification is the credit authorization. Service The scope of this specification is the credit authorization.
specific authorization and authentication is out of the scope. Service-specific authorization and authentication is out of scope.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Terminology 1.2. Terminology
AAA Authentication, Authorization, and Accounting AAA Authentication, Authorization, and Accounting
AA answer AA answer generically refers to a service specific AA answer AA answer generically refers to a service-specific
authorization and authentication answer. AA answer commands are authorization and authentication answer. AA answer commands are
defined in service specific authorization applications, e.g., defined in service-specific authorization applications, e.g.,
[RFC7155] and [RFC4004]. [RFC7155] and [RFC4004].
AA request AA request generically refers to a service specific AA request AA request generically refers to a service-specific
authorization and authentication request. AA request commands are authorization and authentication request. AA request commands are
defined in service specific authorization applications e.g., defined in service-specific authorization applications e.g.,
[RFC7155] and [RFC4004]. [RFC7155] and [RFC4004].
Credit-control Credit-control is a mechanism that directly interacts Credit-control Credit-control is a mechanism that directly interacts
in real-time with an account and controls or monitors the charges in real-time with an account and controls or monitors the charges
related to the service usage. Credit-control is a process of related to the service usage. Credit-control is a process of
checking whether credit is available, credit-reservation, checking whether credit is available, credit-reservation,
deduction of credit from the end user account when service is deduction of credit from the end user account when service is
completed and refunding of reserved credit that is not used. completed and refunding of reserved credit that is not used.
Diameter Credit-control Server A Diameter credit-control server acts Diameter Credit-control Server A Diameter credit-control server acts
skipping to change at page 9, line 12 skipping to change at page 9, line 14
balance is sufficient to cover the cost of the service being balance is sufficient to cover the cost of the service being
rendered. rendered.
Figure 1 illustrates the typical credit-control architecture, which Figure 1 illustrates the typical credit-control architecture, which
consists of a Service Element with an embedded Diameter credit- consists of a Service Element with an embedded Diameter credit-
control client, a Diameter credit-control server, and an AAA server. control client, a Diameter credit-control server, and an AAA server.
A Business Support System is usually deployed; it includes at least A Business Support System is usually deployed; it includes at least
the billing functionality. The credit-control server and AAA server the billing functionality. The credit-control server and AAA server
in this architecture model are logical entities. The real in this architecture model are logical entities. The real
configuration can combine them into a single host. The credit- configuration can combine them into a single host. The credit-
control protocol is the Diameter base protocol with the Diameter control protocol is the Diameter base protocol [RFC6733] with the
credit-control application. Diameter credit-control application.
When an end user requests services such as SIP or messaging, the When an end user requests services such as SIP or messaging, the
request is typically forwarded to a service element (e.g., SIP Proxy) request is typically forwarded to a service element (e.g., SIP Proxy)
in the user's home domain. In some cases it might be possible that in the user's home realm as defined in [RFC6733]. In some cases it
the service element in the visited domain can offer services to the might be possible that the service element in the local realm
end user; however, a commercial agreement must exist between the [RFC6733] can offer services to the end user; however, a commercial
visited domain and the home domain. Network access is an example of agreement must exist between the local realm and the home realm.
a service offered in the visited domain where the NAS, through an AAA Network access is an example of a service offered in the local realm
infrastructure, authenticates and authorizes the user with the user's where the NAS, through an AAA infrastructure, authenticates and
home network. authorizes the user with the user's home network.
Service Element AAA and CC Service Element AAA and CC
+----------+ +---------+ Protocols+-----------+ +--------+ +----------+ +---------+ Protocols+-----------+ +--------+
| End |<---->|+-------+|<------------>| AAA | |Business| | End |<---->|+-------+|<------------>| AAA | |Business|
| User | +->|| CC || | Server |->|Support | | User | +->|| CC || | Server |->|Support |
| | | || Client||<-----+ | | |System | | | | || Client||<-----+ | | |System |
+----------+ | |+-------+| | +-----------+ | | +----------+ | |+-------+| | +-----------+ | |
| +---------+ | ^ +--------+ | +---------+ | ^ +--------+
+----------+ | | CC Protocol | ^ +----------+ | | CC Protocol | ^
| End |<--+ | +-----v----+ | | End |<--+ | +-----v----+ |
skipping to change at page 10, line 47 skipping to change at page 10, line 49
The Credit-Control-Request message (CCR) is indicated by the 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 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 Flags field. It is used between the Diameter credit-control client
and the credit-control server to request credit authorization for a and the credit-control server to request credit authorization for a
given service. given service.
The Auth-Application-Id MUST be set to the value 4, indicating the The Auth-Application-Id MUST be set to the value 4, indicating the
Diameter credit-control application. Diameter credit-control application.
The CCR is extensible via the inclusion of one or more Attribute
Value Pairs (AVPs).
Message Format Message Format
<Credit-Control-Request> ::= < Diameter Header: 272, REQ, PXY > <Credit-Control-Request> ::= < Diameter Header: 272, REQ, PXY >
< Session-Id > < Session-Id >
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
{ Auth-Application-Id } { Auth-Application-Id }
{ Service-Context-Id } { Service-Context-Id }
{ CC-Request-Type } { CC-Request-Type }
{ CC-Request-Number } { CC-Request-Number }
[ Destination-Host ] [ Destination-Host ]
skipping to change at page 12, line 49 skipping to change at page 12, line 49
authentication and authorization before any request is sent to the authentication and authorization before any request is sent to the
credit-control server. The credit-control application defined in credit-control server. The credit-control application defined in
this specification supports two different credit authorization this specification supports two different credit authorization
models: credit authorization with money reservation and credit models: credit authorization with money reservation and credit
authorization with direct debiting. In both models, the credit- authorization with direct debiting. In both models, the credit-
control client requests credit authorization from the credit-control control client requests credit authorization from the credit-control
server prior to allowing any service to be delivered to the end user. server prior to allowing any service to be delivered to the end user.
In the first model, the credit-control server rates the request, In the first model, the credit-control server rates the request,
reserves a suitable amount of money from the user's account, and reserves a suitable amount of money from the user's account, and
returns the corresponding amount of credit resources. Note that returns the amount of credit reserved. Note that credit resources
credit resources may not imply actual monetary credit; credit may not imply actual monetary credit; credit resources may be granted
resources may be granted to the credit-control client in the form of to the credit-control client in the form of units (e.g., data volume
units (e.g., data volume or time) to be metered. or time) to be metered.
Upon receipt of a successful credit authorization answer with a Upon receipt of a successful credit authorization answer with a
certain amount of credit resources, the credit-control client allows certain amount of credit resources, the credit-control client allows
service delivery to the end user and starts monitoring the usage of service delivery to the end user and starts monitoring the usage of
the granted resources. When the credit resources granted to the user the granted resources. When the credit resources granted to the user
have been consumed or the service has been successfully delivered or have been consumed or the service has been successfully delivered or
terminated, the credit-control client reports back to the server the terminated, the credit-control client reports back to the server the
used amount. The credit-control server deducts the used amount from used amount. The credit-control server deducts the used amount from
the end user's account; it may perform rating and make a new credit the end user's account; it may perform rating and make a new credit
reservation if the service delivery is continuing. This process is reservation if the service delivery is continuing. This process is
skipping to change at page 13, line 45 skipping to change at page 13, line 45
multimedia session, an additional media type is added to the session, multimedia session, an additional media type is added to the session,
causing a new simultaneous request toward same account. causing a new simultaneous request toward same account.
Consequently, this needs to be considered when credit resources are Consequently, this needs to be considered when credit resources are
granted to the services. granted to the services.
The credit-control application also supports operations such as The credit-control application also supports operations such as
service price enquiry, user's balance check, and refund of credit on service price enquiry, user's balance check, and refund of credit on
the user's account. These operations are accomplished with the one- the user's account. These operations are accomplished with the one-
time event. Session state is not maintained. time event. Session state is not maintained.
A flexible credit-control application specific failure handling is Flexible failure handling, specific to the credit-control, is defined
defined in which the home service provider can model the credit- in the application. This allows the the service provider to control
control client behavior according to its own credit risk management the credit-control client behavior according to its own risk
policy. management policy.
The Credit-Control-Failure-Handling AVP and the Direct-Debiting- The Credit-Control-Failure-Handling AVP and the Direct-Debiting-
Failure-Handling AVP are defined to determine what is done if the Failure-Handling AVP are defined to determine what is done if the
sending of credit-control messages to the credit-control server has sending of credit-control messages to the credit-control server has
been temporarily prevented. The usage of the Credit-Control-Failure- been temporarily prevented. The usage of the Credit-Control-Failure-
Handling AVP and the Direct-Debiting-Failure-Handling AVP allows Handling AVP and the Direct-Debiting-Failure-Handling AVP allows
flexibility, as failure handling for the credit-control session and flexibility, as failure handling for the credit-control session and
one-time event direct debiting may be different. one-time event direct debiting may be different.
4.1. Service-Specific Rating Input and Interoperability 4.1. Service-Specific Rating Input and Interoperability
skipping to change at page 15, line 26 skipping to change at page 15, line 26
BER). This method can be used to avoid unnecessary conversions from BER). This method can be used to avoid unnecessary conversions from
an existing data format to an AVP format. In this case, the rating an existing data format to an AVP format. In this case, the rating
input is embedded in the Service-Parameter-Info AVP as defined in input is embedded in the Service-Parameter-Info AVP as defined in
Section 8.43. Section 8.43.
New service applications SHOULD favor the use of explicitly defined New service applications SHOULD favor the use of explicitly defined
AVPs as described in items 1a and 1b, to simplify interoperability. AVPs as described in items 1a and 1b, to simplify interoperability.
4.1.2. Service-Specific Documentation 4.1.2. Service-Specific Documentation
The service specific rating input AVPs, the contents of the Service- The service-specific rating input AVPs, the contents of the Service-
Parameter-Info AVP or Service-Context-Id AVP (defined in Parameter-Info AVP or Service-Context-Id AVP (defined in
Section 8.42) are not within the scope of this document. To Section 8.42) are not within the scope of this document. To
facilitate interoperability, it is RECOMMENDED that the rating input facilitate interoperability, it is RECOMMENDED that the rating input
and the values of the Service-Context-Id be coordinated via an and the values of the Service-Context-Id be coordinated via an
informational RFC or other permanent and readily available reference. informational RFC or other permanent and readily available reference,
The specification of another cooperative standardization body (e.g., preferably, of another cooperative standardization body (e.g., 3GPP,
3GPP, OMA, or 3GPP2) SHOULD be used. However, private services may OMA, or 3GPP2). However, private services may be deployed that are
be deployed that are subject to agreements between providers of the subject to agreements between providers of the credit-control server
credit-control server and client. In this case, vendor specific AVPs and client. In this case, vendor-specific AVPs can be used.
can be used.
This specification, together with the above service specific This specification, together with the above service-specific
documents, governs the credit-control message. Service specific documents, governs the credit-control message. Service-specific
documents define which existing AVPs or new AVPs are used as input to documents define which existing AVPs or new AVPs are used as input to
the rating process (i.e., those that do not define new credit-control the rating process (i.e., those that do not define new credit-control
applications), and thus have to be included in the Credit-Control- applications), and thus have to be included in the Credit-Control-
Request command by a Diameter credit-control client supporting a Request command by a Diameter credit-control client supporting a
given service as *[AVP]. Should Service-Parameter-Info be used, then given service as *[AVP]. Should Service-Parameter-Info be used, then
the service specific document MUST specify the exact content of this the service-specific document MUST specify the exact content of this
grouped AVP. grouped AVP.
The Service-Context-Id AVP MUST be included at the command level of a The Service-Context-Id AVP MUST be included at the command level of a
Credit-Control Request to identify the service specific document that Credit-Control Request to identify the service-specific document that
applies to the request. The specific service or rating group the applies to the request. The specific service or rating group the
request relates to is uniquely identified by the combination of request relates to is uniquely identified by the combination of
Service-Context-Id and Service-Identifier or Rating-Group. Service-Context-Id and Service-Identifier or Rating-Group.
4.1.3. Handling of Unsupported/Incorrect Rating Input 4.1.3. Handling of Unsupported/Incorrect Rating Input
Diameter credit-control implementations are required to support the Diameter credit-control implementations are required to support the
Mandatory rating AVPs defined in service specific documentation of Mandatory rating AVPs defined in service-specific documentation of
the services they support, according to the 'M' bit rules in the services they support, according to the 'M' bit rules in
[RFC6733]. [RFC6733].
If a rating input required for the rating process is incorrect in the If a rating input required for the rating process is incorrect in the
Credit-control request, or if the credit-control server does not Credit-control request, or if the credit-control server does not
support the requested service context (identified by the Service- support the requested service context (identified by the Service-
Context-Id AVP at command level), the Credit-control answer MUST Context-Id AVP at command level), the Credit-control answer MUST
contain the error code DIAMETER_RATING_FAILED. A CCA message with contain the error code DIAMETER_RATING_FAILED. A CCA message with
this error MUST contain one or more Failed-AVP AVPs containing the this error MUST contain one or more Failed-AVP AVPs containing the
missing and/or unsupported AVPs that caused the failure. A Diameter missing and/or unsupported AVPs that caused the failure. A Diameter
credit-control client that receives the error code credit-control client that receives the error code
DIAMETER_RATING_FAILED in response to a request MUST NOT send similar DIAMETER_RATING_FAILED in response to a request MUST NOT send similar
requests in the future. requests in the future.
4.1.4. RADIUS Vendor-Specific Rating Attributes 4.1.4. RADIUS Vendor-Specific Rating Attributes
When service specific documents include RADIUS vendor specific When service-specific documents include RADIUS vendor-specific
attributes that could be used as input in the rating process, the attributes that could be used as input in the rating process, the
rules described in [RFC7155] for formatting the Diameter AVP MUST be rules described in [RFC7155] for formatting the Diameter AVP MUST be
followed. followed.
For example, if the AVP code used is the vendor attribute type code, For example, if the AVP code used is the vendor attribute type code,
the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be
set to the IANA Vendor identification value. The Diameter AVP data set to the IANA Vendor identification value. The Diameter AVP data
field contains only the attribute value of the RADIUS attribute. field contains only the attribute value of the RADIUS attribute.
5. Session Based Credit-Control 5. Session Based Credit-Control
skipping to change at page 17, line 13 skipping to change at page 17, line 13
of a credit-control session. of a credit-control session.
Certain applications require multiple credit-control sub-sessions. Certain applications require multiple credit-control sub-sessions.
These applications would send messages with a constant Session-Id These applications would send messages with a constant Session-Id
AVP, but with a different CC-Sub-Session-Id AVP. If several credit AVP, but with a different CC-Sub-Session-Id AVP. If several credit
sub-sessions will be used, all sub-sessions MUST be closed separately sub-sessions will be used, all sub-sessions MUST be closed separately
before the main session is closed so that units per sub-session may before the main session is closed so that units per sub-session may
be reported. The absence of this AVP implies that no sub-sessions be reported. The absence of this AVP implies that no sub-sessions
are in use. are in use.
Note that the service element might send a service specific re- Note that the service element might send a service-specific re-
authorization message to the AAA server due to expiration of the authorization message to the AAA server due to expiration of the
authorization-lifetime during an ongoing credit-control session. authorization-lifetime during an ongoing credit-control session.
However, the service specific re-authorization does not influence the However, the service-specific re-authorization does not influence the
credit authorization that is ongoing between the credit-control credit authorization that is ongoing between the credit-control
client and credit-control server, as credit authorization is client and credit-control server, as credit authorization is
controlled by the burning rate of the granted quota. controlled by the burning rate of the granted quota.
If service specific re-authorization fails, the user will be If service-specific re-authorization fails, the user will be
disconnected, and the credit-control client MUST send a final disconnected, and the credit-control client MUST send a final
interrogation to the credit-control server. interrogation to the credit-control server.
The Diameter credit-control server may seek to control the validity The Diameter credit-control server may seek to control the validity
time of the granted quota and/or the production of intermediate time of the granted quota and/or the production of intermediate
interrogations. Thus, it MAY include the Validity-Time AVP in the interrogations. Thus, it MAY include the Validity-Time AVP in the
answer message to the credit-control client. Upon expiration of the answer message to the credit-control client. Upon expiration of the
Validity-Time, the credit-control client MUST generate a credit- Validity-Time, the credit-control client MUST generate a credit-
control update request and report the used quota to the credit- control update request and report the used quota to the credit-
control server. It is up to the credit-control server to determine control server. It is up to the credit-control server to determine
the value of the Validity-Time to be used for consumption of the the value of the Validity-Time to be used for consumption of the
granted service units. If the Validity-Time is used, its value granted service unit(s) (G-S-U). If the Validity-Time is used, its
SHOULD be given as input to set the session supervision timer Tcc value SHOULD be given as input to set the session supervision timer
(the session supervision timer MAY be set to two times the value of Tcc (the session supervision timer MAY be set to two times the value
the Validity-Time, as defined in Section 13). Since credit-control of the Validity-Time, as defined in Section 13). Since credit-
update requests are also produced at the expiry of granted service control update requests are also produced at the expiry of granted
units and/or for mid-session service events, the omission of service units and/or for mid-session service events, the omission of
Validity-Time does not mean that intermediate interrogation for the Validity-Time does not mean that intermediate interrogation for the
purpose of credit-control is not performed. purpose of credit-control is not performed.
5.1.1. Basic Tariff-Time Change Support 5.1.1. Basic Tariff-Time Change Support
The Diameter credit-control server and client MAY optionally support The Diameter credit-control server and client MAY optionally support
a tariff change mechanism. The Diameter credit-control server may a tariff change mechanism. The Diameter credit-control server may
include a Tariff-Time-Change AVP in the answer message. Note that include a Tariff-Time-Change AVP in the answer message. Note that
the granted units should be allocated based on the worst-case the granted units should be allocated based on the worst-case
scenario in case of forthcoming tariff change, so that the overall scenario in case of forthcoming tariff change, so that the overall
skipping to change at page 18, line 16 skipping to change at page 18, line 16
whether units straddling the tariff change were used before or after whether units straddling the tariff change were used before or after
the tariff change, the credit-control client MUST itemize those units the tariff change, the credit-control client MUST itemize those units
in a third category. in a third category.
If a client does not support the tariff change mechanism and it If a client does not support the tariff change mechanism and it
receives a CCA message carrying the Tariff-Time-Change AVP, it MUST receives a CCA message carrying the Tariff-Time-Change AVP, it MUST
terminate the credit-control session, giving a reason of terminate the credit-control session, giving a reason of
DIAMETER_BAD_ANSWER in the Termination-Cause AVP. DIAMETER_BAD_ANSWER in the Termination-Cause AVP.
For time based services, the quota is continuously consumed at the For time based services, the quota is continuously consumed at the
regular rate of 60 seconds per minute. At the time when credit regular rate of 60 seconds per minute (ignoring leap seconds). At
resources are allocated, the server already knows how many units will the time when credit resources are allocated, the server already
be consumed before the tariff time change and how many units will be knows how many units will be consumed before the tariff time change
consumed afterward. Similarly, the server can determine the units and how many units will be consumed afterward. Similarly, the server
consumed at the before rate and the units consumed at the rate can determine the units consumed at the before rate and the units
afterward in the event that the end-user closes the session before consumed at the rate afterward in the event that the end-user closes
the consumption of the allotted quota. There is no need for the session before the consumption of the allotted quota. There is
additional traffic between client and server in the case of tariff no need for additional traffic between client and server in the case
time changes for continuous time based service. Therefore, the of tariff time changes for continuous time based service. Therefore,
tariff change mechanism is not used for such services. For time- the tariff change mechanism is not used for such services. For time-
based services in which the quota is NOT continuously consumed at a based services in which the quota is NOT continuously consumed at a
regular rate, the tariff change mechanism described for volume and regular rate, the tariff change mechanism described for volume and
event units MAY be used. event units MAY be used.
5.1.2. Credit-Control for Multiple Services within a (sub-)Session 5.1.2. Credit-Control for Multiple Services within a (sub-)Session
When multiple services are used within the same user session and each When multiple services are used within the same user session and each
service or group of services is subject to different cost, it is service or group of services is subject to different cost, it is
necessary to perform credit-control for each service independently. necessary to perform credit-control for each service independently.
Making use of credit-control sub-sessions to achieve independent Making use of credit-control sub-sessions to achieve independent
credit-control will result in increased signaling load and usage of credit-control will result in increased signaling load and usage of
resources in both the credit-control client and the credit-control resources in both the credit-control client and the credit-control
server. For instance, during one network access session the end user server. For instance, during one network access session the end user
may use several http-services subject to different access cost. The may use several http-services subject to different access cost. The
network access specific attributes such as the quality of service network-access-specific attributes such as the quality of service
(QoS) are common to all the services carried within the access (QoS) are common to all the services carried within the access
bearer, but the cost of the bearer may vary depending on its content. bearer, but the cost of the bearer may vary depending on its content.
To support these scenarios optimally, the credit-control application To support these scenarios optimally, the credit-control application
enables independent credit-control of multiple services in a single enables independent credit-control of multiple services in a single
credit-control (sub-)session. This is achieved by including the credit-control (sub-)session. This is achieved by including the
optional Multiple-Services-Credit-Control AVP in Credit-Control- optional Multiple-Services-Credit-Control AVP in Credit-Control-
Request/Answer messages. It is possible to request and allocate Request/Answer messages. It is possible to request and allocate
resources as a credit pool shared between multiple services. The resources as a credit pool shared between multiple services. The
services can be grouped into rating groups in order to achieve even services can be grouped into rating groups in order to achieve even
skipping to change at page 22, line 7 skipping to change at page 22, line 7
in Section 7. Credit-control clients and servers implementing the in Section 7. Credit-control clients and servers implementing the
independent credit-control of multiple services in a (sub-)session independent credit-control of multiple services in a (sub-)session
functionality MUST ensure failure handling and general behavior fully functionality MUST ensure failure handling and general behavior fully
consistent with the above mentioned sections, while maintaining the consistent with the above mentioned sections, while maintaining the
ability to handle parallel ongoing credit re-authorization within a ability to handle parallel ongoing credit re-authorization within a
(sub-)session. Therefore, it is RECOMMENDED that Diameter credit- (sub-)session. Therefore, it is RECOMMENDED that Diameter credit-
control clients maintain a PendingU message queue and restart the Tx control clients maintain a PendingU message queue and restart the Tx
timer (Section 13) every time a CCR message with the value timer (Section 13) every time a CCR message with the value
UPDATE_REQUEST is sent while they are in PendingU state. When UPDATE_REQUEST is sent while they are in PendingU state. When
answers to all pending messages are received, the state machine moves answers to all pending messages are received, the state machine moves
to OPEN state, and Tx is stopped. Naturally, the action performed to OPEN state, and Tx timer is stopped. Naturally, the action
when a problem for the session is detected according to Section 5.7 performed when a problem for the session is detected according to
affects all the ongoing services (e.g., failover to a backup server Section 5.7 affects all the ongoing services (e.g., failover to a
if possible affect all the CCR messages with the value UPDATE_REQUEST backup server if possible affect all the CCR messages with the value
in the PendingU queue). UPDATE_REQUEST in the PendingU queue).
Since the client may send CCR messages with the value UPDATE_REQUEST Since the client may send CCR messages with the value UPDATE_REQUEST
while in PendingU (i.e., without waiting for an answer to ongoing while in PendingU (i.e., without waiting for an answer to ongoing
credit re-authorization), the time space between these requests may credit re-authorization), the time space between these requests may
be very short, and the server may not have received the previous be very short, and the server may not have received the previous
request(s) yet. Therefore, in this situation the server may receive request(s) yet. Therefore, in this situation the server may receive
out of sequence requests and SHOULD NOT consider this an error out of sequence requests and SHOULD NOT consider this an error
condition. A proper answer is to be returned to each of those condition. A proper answer is to be returned to each of those
requests. requests.
skipping to change at page 22, line 42 skipping to change at page 22, line 42
cost) the monetary amount to be charged is included in the Requested- cost) the monetary amount to be charged is included in the Requested-
Service-Unit AVP. If the Diameter credit-control client does not Service-Unit AVP. If the Diameter credit-control client does not
know the cost of the service event, the Requested-Service-Unit AVP know the cost of the service event, the Requested-Service-Unit AVP
MAY contain the number of requested service events. Where the MAY contain the number of requested service events. Where the
Multiple-Services-Credit-Control AVP is used, it MUST contain the Multiple-Services-Credit-Control AVP is used, it MUST contain the
Requested-Service-Unit AVP to indicate that the quota for the Requested-Service-Unit AVP to indicate that the quota for the
associated service/rating-group is requested. In the case of associated service/rating-group is requested. In the case of
multiple services, the Service-Identifier AVP or the Rating-Group AVP multiple services, the Service-Identifier AVP or the Rating-Group AVP
within the Multiple-Services-Credit-Control AVP always indicates the within the Multiple-Services-Credit-Control AVP always indicates the
service concerned. Additional service event information to be rated service concerned. Additional service event information to be rated
MAY be sent as service specific AVPs or MAY be sent within the MAY be sent as service-specific AVPs or MAY be sent within the
Service-Parameter-Info AVP at command level. The Service-Context-Id Service-Parameter-Info AVP at command level. The Service-Context-Id
AVP indicates the service specific document applicable to the AVP indicates the service-specific document applicable to the
request. request.
The Event-Timestamp AVP SHOULD be included in the request and The Event-Timestamp AVP SHOULD be included in the request and
contains the time when the service event is requested in the service contains the time when the service event is requested in the service
element. The Subscription-Id AVP or the Subscription-Id-Extension element. The Subscription-Id AVP or the Subscription-Id-Extension
AVP SHOULD be included to identify the end user in the credit-control AVP SHOULD be included to identify the end user in the credit-control
server. The credit-control client MAY include the User-Equipment- server. The credit-control client MAY include the User-Equipment-
Info AVP or User-Equipment-Info-Extension AVP so that the credit- Info AVP or User-Equipment-Info-Extension AVP so that the credit-
control server has some indication of the type and capabilities of control server has some indication of the type and capabilities of
the end user access device. How the credit-control server uses this the end user access device. How the credit-control server uses this
skipping to change at page 23, line 22 skipping to change at page 23, line 22
is money, no rating is needed, but the corresponding monetary amount is money, no rating is needed, but the corresponding monetary amount
is reserved from the end user's account. is reserved from the end user's account.
The credit-control server returns the Granted-Service-Unit AVP in the The credit-control server returns the Granted-Service-Unit AVP in the
Answer message to the Diameter credit-control client. The Granted- Answer message to the Diameter credit-control client. The Granted-
Service-Unit AVP contains the amount of service units that the Service-Unit AVP contains the amount of service units that the
Diameter credit-control client can provide to the end user until a Diameter credit-control client can provide to the end user until a
new Credit-Control-Request MUST be sent to the credit-control server. new Credit-Control-Request MUST be sent to the credit-control server.
If several unit types are sent in the Answer message, the credit- If several unit types are sent in the Answer message, the credit-
control client MUST handle each unit type separately. The type of control client MUST handle each unit type separately. The type of
the Granted-Service-Unit AVP can be time, volume, service specific, the Granted-Service-Unit AVP can be time, volume, service-specific,
or money, depending on the type of service event. The unit type(s) or money, depending on the type of service event. The unit type(s)
SHOULD NOT be changed within an ongoing credit-control session. SHOULD NOT be changed within an ongoing credit-control session.
There MUST be a maximum of one instance of the same unit type in one There MUST be a maximum of one instance of the same unit type in one
Answer message. However, if multiple quotas are conveyed to the Answer message. However, if multiple quotas are conveyed to the
credit-control client in the Multiple-Services-Credit-Control AVPs, credit-control client in the Multiple-Services-Credit-Control AVPs,
it is possible to carry two instances of the same unit type it is possible to carry two instances of the same unit type
associated to a service-identifier/rating-group. This is typically associated to a service-identifier/rating-group. This is typically
the case when a tariff time change is expected and the credit-control the case when a tariff time change is expected and the credit-control
server wants to make a distinction between the granted quota before server wants to make a distinction between the granted quota before
skipping to change at page 23, line 51 skipping to change at page 23, line 51
The Credit-Control-Answer message MAY also include the Final-Unit- The Credit-Control-Answer message MAY also include the Final-Unit-
Indication AVP or the QoS-Final-Unit-Indication AVP to indicate that Indication AVP or the QoS-Final-Unit-Indication AVP to indicate that
the answer message contains the final units for the service. After the answer message contains the final units for the service. After
the end user has consumed these units, the Diameter credit-control- the end user has consumed these units, the Diameter credit-control-
client MUST behave as described in Section 5.6. client MUST behave as described in Section 5.6.
This document defines two different approaches to perform the first This document defines two different approaches to perform the first
interrogation to be used in different network architectures. The interrogation to be used in different network architectures. The
first approach uses credit-control messages after the user's first approach uses credit-control messages after the user's
authorization and authentication takes place. The second approach authorization and authentication takes place. The second approach
uses service specific authorization messages to perform the first uses service-specific authorization messages to perform the first
interrogation during the user's authorization/authentication phase, interrogation during the user's authorization/authentication phase,
and credit-control messages for the intermediate and final and credit-control messages for the intermediate and final
interrogations. If an implementation of the credit-control client interrogations. If an implementation of the credit-control client
supports both the methods, determining which method to use SHOULD be supports both the methods, determining which method to use SHOULD be
configurable. configurable.
In service environments such as the Network Access Server (NAS), it In service environments such as the Network Access Server (NAS), it
is desired to perform the first interrogation as part of the is desired to perform the first interrogation as part of the
authorization/authentication process for the sake of protocol authorization/authentication process for the sake of protocol
efficiency. Further credit authorizations after the first efficiency. Further credit authorizations after the first
skipping to change at page 25, line 44 skipping to change at page 25, line 44
| | | CCA | | | | CCA |
| |<----------------------------------------| | |<----------------------------------------|
| | ACR(stop) | | | | ACR(stop) | |
| |------------------->| | | |------------------->| |
| | ACA | | | | ACA | |
| |<-------------------| | | |<-------------------| |
Figure 3: Protocol example with first interrogation after user's Figure 3: Protocol example with first interrogation after user's
authorization/authentication authorization/authentication
5.2.2. Authorization Messages for First Interrogation 5.2.2. First Interrogation Included with Authorization Messages
The Diameter credit-control client in the service element MUST The Diameter credit-control client in the service element MUST
actively co-operate with the authorization/authentication client in actively co-operate with the authorization/authentication client in
the construction of the AA request by adding appropriate credit- the construction of the AA request by adding appropriate credit-
control AVPs. The credit-control client MUST add the Credit-Control control AVPs. The credit-control client MUST add the Credit-Control
AVP to indicate credit-control capabilities and MAY add other AVP to indicate credit-control capabilities and MAY add other
relevant credit-control specific AVPs to the proper authorization/ relevant credit-control-specific AVPs to the proper authorization/
authentication command to perform the first interrogation toward the authentication command to perform the first interrogation toward the
home Diameter AAA server. The Auth-Application-Id is set to the home Diameter AAA server. The Auth-Application-Id is set to the
appropriate value, as defined in the relevant service specific appropriate value, as defined in the relevant service-specific
authorization/authentication application document (e.g., [RFC7155], authorization/authentication application document (e.g., [RFC7155],
[RFC4004]). The home Diameter AAA server authenticates/authorizes [RFC4004]). The home Diameter AAA server authenticates/authorizes
the subscriber and determines whether credit-control is required. the subscriber and determines whether credit-control is required.
If credit-control is not required for the subscriber, the home If credit-control is not required for the subscriber, the home
Diameter AAA server will respond as usual, with an appropriate AA Diameter AAA server will respond as usual, with an appropriate AA
answer message. If credit-control is required for the subscriber and answer message. If credit-control is required for the subscriber and
the Credit-Control AVP with the value set to CREDIT_AUTHORIZATION was the Credit-Control AVP with the value set to CREDIT_AUTHORIZATION was
present in the authorization request, the home AAA server MUST present in the authorization request, the home AAA server MUST
contact the credit-control server to perform the first interrogation. contact the credit-control server to perform the first interrogation.
If credit-control is required for the subscriber and the Credit- If credit-control is required for the subscriber and the Credit-
Control AVP was not present in the authorization request, the home Control AVP was not present in the authorization request, the home
AAA server MUST send an authorization reject answer message. AAA server MUST send an authorization reject answer message.
The Diameter AAA server supporting credit-control is required to send The Diameter AAA server supporting credit-control is required to send
the Credit-Control-Request command (CCR) defined in this document to the Credit-Control-Request command (CCR) defined in this document to
the credit-control server. The Diameter AAA server populates the CCR the credit-control server. The Diameter AAA server populates the CCR
based on service specific AVPs used for input to the rating process, based on service-specific AVPs used for input to the rating process,
and possibly on credit-control AVPs received in the AA request. The and possibly on credit-control AVPs received in the AA request. The
credit-control server will reserve money from the user's account, credit-control server will reserve money from the user's account,
will rate the request and will send a Credit-Control-Answer message will rate the request and will send a Credit-Control-Answer message
to the home Diameter AAA server. The answer message includes the to the home Diameter AAA server. The answer message includes the
Granted-Service-Unit AVP(s) and MAY include other credit-control Granted-Service-Unit AVP(s) and MAY include other credit-control-
specific AVPs, as appropriate. Additionally, the credit-control specific AVPs, as appropriate. Additionally, the credit-control
server MAY set the Validity-Time and MAY include the Credit-Control- server MAY set the Validity-Time and MAY include the Credit-Control-
Failure-Handling AVP and the Direct-Debiting-Failure-Handling AVP to Failure-Handling AVP and the Direct-Debiting-Failure-Handling AVP to
determine what to do if the sending of credit-control messages to the determine what to do if the sending of credit-control messages to the
credit-control server has been temporarily prevented. credit-control server has been temporarily prevented.
Upon receiving the Credit-Control-Answer message from the credit- Upon receiving the Credit-Control-Answer message from the credit-
control server, the home Diameter AAA server will populate the AA control server, the home Diameter AAA server will populate the AA
answer with the received credit-control AVPs and with the appropriate answer with the received credit-control AVPs and with the appropriate
service attributes according to the authorization/authentication service attributes according to the authorization/authentication-
specific application (e.g., [RFC7155], [RFC4004]). It will then specific application (e.g., [RFC7155], [RFC4004]). It will then
forward the packet to the credit-control client. If the home forward the packet to the credit-control client. If the home
Diameter AAA server receives a credit-control reject message, it will Diameter AAA server receives a credit-control reject message, it will
simply generate an appropriate authorization reject message to the simply generate an appropriate authorization reject message to the
credit-control client, including the credit-control specific error credit-control client, including the credit-control-specific error
code. code.
In this model, the credit-control client sends further credit-control In this model, the credit-control client sends further credit-control
messages to the credit-control server via the home Diameter AAA messages to the credit-control server via the home Diameter AAA
server. Upon receiving a successful authorization answer message server. Upon receiving a successful authorization answer message
with the Granted-Service-Unit AVP(s), the credit-control client will with the Granted-Service-Unit AVP(s), the credit-control client will
grant the service to the end user and will generate an intermediate grant the service to the end user and will generate an intermediate
credit-control request, as required by using credit-control commands. credit-control request, as required by using credit-control commands.
The CC-Request-Number of the first UPDATE_REQUEST MUST be set to 1 The CC-Request-Number of the first UPDATE_REQUEST MUST be set to 1
(for how to produce unique value for the CC-Request-Number AVP, see (for how to produce unique value for the CC-Request-Number AVP, see
Section 8.2). Section 8.2).
If service specific re-authorization is performed (i.e., If service-specific re-authorization is performed (i.e.,
authorization-lifetime expires), the credit-control client MUST add authorization-lifetime expires), the credit-control client MUST add
to the service specific re-authorization request the Credit-Control to the service-specific re-authorization request the Credit-Control
AVP with a value set to RE_AUTHORIZATION to indicate that the credit- AVP with a value set to RE_AUTHORIZATION to indicate that the credit-
control server MUST NOT be contacted. When session based credit- control server MUST NOT be contacted. When session based credit-
control is used for the subscriber, a constant credit-control message control is used for the subscriber, a constant credit-control message
stream flows through the home Diameter AAA server. The home Diameter stream flows through the home Diameter AAA server. The home Diameter
AAA server can make use of this credit-control message flow to deduce 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 that the user's activity is ongoing; therefore, it is recommended to
set the authorization-lifetime to a reasonably high value when set the authorization-lifetime to a reasonably high value when
credit-control is used for the subscriber. credit-control is used for the subscriber.
In this scenario, the home Diameter AAA server MUST advertise support In this scenario, the home Diameter AAA server MUST advertise support
skipping to change at page 29, line 28 skipping to change at page 29, line 28
When the new granted units are received, these units apply from the When the new granted units are received, these units apply from the
point where the measurement of the reported used units stopped. point where the measurement of the reported used units stopped.
Where independent credit-control of multiple services is supported, Where independent credit-control of multiple services is supported,
this process may be executed for one or more services, a single this process may be executed for one or more services, a single
rating-group, or a pool within the (sub)session. rating-group, or a pool within the (sub)session.
The CC-Request-Type AVP is set to the value UPDATE_REQUEST in the The CC-Request-Type AVP is set to the value UPDATE_REQUEST in the
intermediate request message. The Subscription-Id AVP or intermediate request message. The Subscription-Id AVP or
Subscription-Id-Extension AVP SHOULD be included in the intermediate Subscription-Id-Extension AVP SHOULD be included in the intermediate
message to identify the end user in the credit-control server. The message to identify the end user in the credit-control server. The
Service-Context-Id AVP indicates the service specific document Service-Context-Id AVP indicates the service-specific document
applicable to the request. applicable to the request.
The Requested-Service-Unit AVP MAY contain the new amount of The Requested-Service-Unit AVP MAY contain the new amount of
requested service units. Where the Multiple-Services-Credit-Control requested service units. Where the Multiple-Services-Credit-Control
AVP is used, it MUST contain the Requested-Service-Unit AVP if a new AVP is used, it MUST contain the Requested-Service-Unit AVP if a new
quota is requested for the associated service/rating-group. The quota is requested for the associated service/rating-group. The
Used-Service-Unit AVP contains the amount of used service units Used-Service-Unit AVP contains the amount of used service units
measured from the point when the service became active or, if interim measured from the point when the service became active or, if interim
interrogations are used during the session, from the point when the interrogations are used during the session, from the point when the
previous measurement ended. The same unit types used in the previous previous measurement ended. The same unit types used in the previous
skipping to change at page 30, line 25 skipping to change at page 30, line 25
There can be several intermediate interrogations within a session. There can be several intermediate interrogations within a session.
5.4. Final Interrogation 5.4. Final Interrogation
When the end user terminates the service session, or when the When the end user terminates the service session, or when the
graceful service termination described in Section 5.6 takes place, graceful service termination described in Section 5.6 takes place,
the Diameter credit-control client MUST send a final Credit-Control- the Diameter credit-control client MUST send a final Credit-Control-
Request message to the credit-control server. The CC-Request-Type Request message to the credit-control server. The CC-Request-Type
AVP is set to the value TERMINATION_REQUEST. The Service-Context-Id AVP is set to the value TERMINATION_REQUEST. The Service-Context-Id
AVP indicates the service specific document applicable to the AVP indicates the service-specific document applicable to the
request. request.
The Event-Timestamp AVP SHOULD be included in the request and The Event-Timestamp AVP SHOULD be included in the request and
contains the time when the session was terminated. contains the time when the session was terminated.
The Used-Service-Unit AVP contains the amount of used service units The Used-Service-Unit AVP contains the amount of used service units
measured from the point when the service became active or, if interim measured from the point when the service became active or, if interim
interrogations are used during the session, from the point when the interrogations are used during the session, from the point when the
previous measurement ended. If several unit types were included in previous measurement ended. If several unit types were included in
the previous answer message, the used service units for each unit the previous answer message, the used service units for each unit
skipping to change at page 30, line 49 skipping to change at page 30, line 49
reserved credit amount not used to the end user's account and deduct reserved credit amount not used to the end user's account and deduct
the used monetary amount from the end user's account. the used monetary amount from the end user's account.
A Credit-Control-Answer message with the CC-Request-Type set to the A Credit-Control-Answer message with the CC-Request-Type set to the
value TERMINATION_REQUEST MAY include the Cost-Information AVP value TERMINATION_REQUEST MAY include the Cost-Information AVP
containing the estimated total cost for the session in question. containing the estimated total cost for the session in question.
If the user logs off during an ongoing credit-control session, or if If the user logs off during an ongoing credit-control session, or if
some other reason causes the user to become logged off (e.g., final- some other reason causes the user to become logged off (e.g., final-
unit indication causes user logoff according to local policy), the unit indication causes user logoff according to local policy), the
service element, according to application specific policy, may send a service element, according to application-specific policy, may send a
Session-Termination-Request (STR) to the home Diameter AAA server as Session-Termination-Request (STR) to the home Diameter AAA server as
usual [RFC6733]. Figure 5 illustrates the case when the final-unit usual [RFC6733]. Figure 5 illustrates the case when the final-unit
indication causes user logoff upon consumption of the final granted indication causes user logoff upon consumption of the final granted
units and the generation of STR. units and the generation of STR.
Service Element AAA Server CC Server Service Element AAA Server CC Server
End User (CC Client) End User (CC Client)
| Service Delivery | | | | Service Delivery | | |
|<----------------->| | | |<----------------->| | |
| : | | | | : | | |
skipping to change at page 37, line 29 skipping to change at page 37, line 29
connected to the top-up server, an additional authorization (and connected to the top-up server, an additional authorization (and
possibly authentication) may be needed before the subscriber can possibly authentication) may be needed before the subscriber can
replenish the account; however, this is out of the scope of this replenish the account; however, this is out of the scope of this
specification. specification.
In addition to the Redirect-Server AVP or Redirect-Server-Extension In addition to the Redirect-Server AVP or Redirect-Server-Extension
AVP, the credit-control server MAY include one or more Restriction- AVP, the credit-control server MAY include one or more Restriction-
Filter-Rule AVPs, one or more Filter-Rule AVPs, or one or more Filter-Rule AVPs, one or more Filter-Rule AVPs, or one or more
Filter-Id AVPs in the Credit-Control-Answer message to enable the Filter-Id AVPs in the Credit-Control-Answer message to enable the
user to access other services (for example, zero-rated services). In user to access other services (for example, zero-rated services). In
such a case, the access device MUST drop all the packets not matching such a case, the access device MUST treat all packets according to
the IP filters specified in the Restriction-Filter-Rule AVPs, Filter- the Restriction-Filter-Rule AVPs, Filter-Rules AVPs and the rules
Rule AVPs or Filter-Id AVPs. If enforcement actions other than referred to by the Filter-Id AVP. After treatment is applied
allowing the packets (e.g., QoS), are indicated in the Filter-Rule according to these rules, all traffic that has not been dropped or
AVPs or Filter-Id AVPs, they SHOULD be performed as well. In already forwarded MUST be redirected to the destination specified in
addition, if possible, to redirecting the user to the destination the Redirect-Server AVP or Redirect-Server-Extension AVP.
specified in the Redirect-Server AVP or Redirect-Server-Extension
AVP.
An entity other than the credit-control server may provision the An entity other than the credit-control server may provision the
access device with appropriate IP packet filters to be used in access device with appropriate IP packet filters to be used in
conjunction with the Diameter credit-control application. This case conjunction with the Diameter credit-control application. This case
is considered in Section 5.6.3. is considered in Section 5.6.3.
When the final granted units have been consumed, the credit-control When the final granted units have been consumed, the credit-control
client MUST perform an intermediate interrogation. The purpose of client MUST perform an intermediate interrogation. The purpose of
this interrogation is to indicate to the credit-control server that this interrogation is to indicate to the credit-control server that
the specified action started and to report the used units. The the specified action started and to report the used units. The
skipping to change at page 38, line 44 skipping to change at page 38, line 42
The credit-control client may not wait until the expiration of the The credit-control client may not wait until the expiration of the
Validity-Time and may send a spontaneous update (a new Credit- Validity-Time and may send a spontaneous update (a new Credit-
Control-Request) if the service element can determine, for instance, Control-Request) if the service element can determine, for instance,
that communication between the end user and the top-up server took that communication between the end user and the top-up server took
place. An example of this is given in Appendix B.8 (Figure 18). place. An example of this is given in Appendix B.8 (Figure 18).
Note that the credit-control server may already have initiated the Note that the credit-control server may already have initiated the
above-described process for the first interrogation. However, the above-described process for the first interrogation. However, the
user's account might be empty when this first interrogation is user's account might be empty when this first interrogation is
performed. In this case, the subscriber can be offered a chance to performed. In this case, the subscriber can be offered a chance to
replenish the account and continue the service. The credit-control replenish the account and continue the service. When the credit-
client receives a Credit-Control-Answer or service specific control client receives (either at session or service-specific level)
authorization answer with the Final-Unit-Indication or the QoS-Final- a Final-Unit-Indication AVP or QoS-Final-Unit-Indication AVP,
Unit-Indication AVP and Validity-Time AVPs but no Granted-Service- together with Validity-Time AVPs, but without Granted-Service-Unit
Unit AVP. It immediately starts the graceful service termination AVP, it immediately starts the graceful service termination without
without sending any message to the server. An example of this case sending any message to the server. An example of this case is
is illustrated in Appendix B. illustrated in Appendix B.
5.6.3. Restrict Access Action 5.6.3. Restrict Access Action
A Final-Unit-Indication AVP with the Final-Unit-Action A Final-Unit-Indication AVP with the Final-Unit-Action
RESTRICT_ACCESS indicates to the device supporting this action that, RESTRICT_ACCESS indicates to the device supporting this action that,
upon consumption of the final granted units, the user's access MUST upon consumption of the final granted units, the user's access MUST
be restricted according to the IP packet filters given in the be restricted according to the IP packet filters given in the
Restriction-Filter-Rule AVP(s) or according to the IP packet filters Restriction-Filter-Rule AVP(s) or according to the IP packet filters
identified by the Filter-Id AVP(s). The credit-control server SHOULD identified by the Filter-Id AVP(s). The credit-control server SHOULD
include either the Restriction-Filter-Rule AVP or the Filter-Id AVP include either the Restriction-Filter-Rule AVP or the Filter-Id AVP
skipping to change at page 41, line 6 skipping to change at page 41, line 6
AAA server, from the credit-control server, or may be configured AAA server, from the credit-control server, or may be configured
locally. The CCFH value received from the home AAA server overrides locally. The CCFH value received from the home AAA server overrides
the locally configured value. The CCFH value received from the the locally configured value. The CCFH value received from the
credit-control server in the Credit-Control-Answer message always credit-control server in the Credit-Control-Answer message always
overrides any existing value. overrides any existing value.
The authorization server MAY include the Accounting-Realtime-Required The authorization server MAY include the Accounting-Realtime-Required
AVP to determine what to do if the sending of accounting records to AVP to determine what to do if the sending of accounting records to
the accounting server has been temporarily prevented, as defined in the accounting server has been temporarily prevented, as defined in
[RFC6733]. It is RECOMMENDED that the client complement the credit- [RFC6733]. It is RECOMMENDED that the client complement the credit-
control failure procedures with backup accounting flow toward an control failure procedures with a backup accounting flow toward an
accounting server. By using different combinations of Accounting- accounting server. By using different combinations of Accounting-
Realtime-Required and Credit-Control-Failure-Handling AVPs, different Realtime-Required and Credit-Control-Failure-Handling AVPs, different
safety levels can be built. For example, by choosing a Credit- safety levels can be built. For example, by choosing a Credit-
Control-Failure-Handling AVP equal to CONTINUE for the credit-control Control-Failure-Handling AVP equal to CONTINUE for the credit-control
flow and an Accounting-Realtime-Required AVP equal to flow and an Accounting-Realtime-Required AVP equal to
DELIVER_AND_GRANT for the accounting flow, the service can be granted DELIVER_AND_GRANT for the accounting flow, the service can be granted
to the end user even if the connection to the credit-control server to the end user even if the connection to the credit-control server
is down, as long as the accounting server is able to collect the is down, as long as the accounting server is able to collect the
accounting information and information exchange is taking place accounting information and information exchange is taking place
between the accounting server and credit-control server. between the accounting server and credit-control server.
skipping to change at page 42, line 5 skipping to change at page 42, line 5
Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the credit- Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the credit-
control message stream MUST NOT be moved to a backup server. control message stream MUST NOT be moved to a backup server.
For new credit-control sessions, failover to an alternative credit- For new credit-control sessions, failover to an alternative credit-
control server SHOULD be performed if possible. For instance, if an control server SHOULD be performed if possible. For instance, if an
implementation of the credit-control client can determine primary implementation of the credit-control client can determine primary
credit-control server unavailability, it can establish the new credit-control server unavailability, it can establish the new
credit-control sessions with a possibly available secondary credit- credit-control sessions with a possibly available secondary credit-
control server. control server.
The AAA transport profile [RFC3539] defines the application layer The AAA transport profile [RFC3539] defines an application layer
watchdog algorithm that enables failover from a peer that has failed watchdog algorithm that enables failover from a peer that has failed
and is controlled by a watchdog timer (Tw) defined in [RFC3539]. The and is controlled by a watchdog timer (Tw) defined in [RFC3539]. The
recommended default initial value for Tw (Twinit) is 30 seconds. recommended default initial value for Tw (Twinit) is 30 seconds.
Twinit may be set as low as 6 seconds; however, according to Twinit may be set as low as 6 seconds; however, according to
[RFC3539], 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
an increased probability of duplicates, as well as an increase in an increased probability of duplicates, as well as an increase in
spurious failover and failback attempts. The Diameter base protocol spurious failover and failback attempts. The Diameter base protocol
is common to several different types of Diameter AAA applications [RFC6733] is common to several different types of Diameter AAA
that may be run in the same service element. Therefore, tuning the applications that may be run in the same service element. Therefore,
timer Twinit to a lower value in order to satisfy the requirements of tuning the timer Twinit to a lower value in order to satisfy the
real-time applications, such as the Diameter credit-control requirements of real-time applications, such as the Diameter credit-
application, will certainly cause the above mentioned problems. For control application, will certainly cause the above mentioned
prepaid services, however, the end user expects an answer from the problems. For prepaid services, however, the end user expects an
network in a reasonable time. Thus, the Diameter credit-control answer from the network in a reasonable time. Thus, the Diameter
client will react faster than would the underlying base protocol. credit-control client will react faster than would the underlying
Therefore this specification defines the timer Tx that is used by the base protocol. Therefore this specification defines the Tx timer
credit-control client (as defined in Section 13) to supervise the that is used by the credit-control client (as defined in Section 13)
communication with the credit-control server. When the timer Tx to supervise the communication with the credit-control server. When
elapses, the credit-control client takes an action to the end user the Tx timer elapses, the credit-control client takes an action to
according to the Credit-Control-Failure-Handling AVP. the end user according to the Credit-Control-Failure-Handling AVP.
When Tx expires, the Diameter credit-control client always terminates When Tx timer expires, the Diameter credit-control client always
the service if the Credit-Control-Failure-Handling (CCFH) AVP is set terminates the service if the Credit-Control-Failure-Handling (CCFH)
to the value TERMINATE. The credit-control session may be moved to AVP is set to the value TERMINATE. The credit-control session may be
an alternative server only if a protocol error DIAMETER_TOO_BUSY or moved to an alternative server only if a protocol error
DIAMETER_UNABLE_TO_DELIVER is received before Tx expires. Therefore, DIAMETER_TOO_BUSY or DIAMETER_UNABLE_TO_DELIVER is received before Tx
the value TERMINATE is not appropriate if proper failover behavior is timer expires. Therefore, the value TERMINATE is not appropriate if
desired. proper failover behavior is desired.
If the Credit-Control-Failure-Handling AVP is set to the value If the Credit-Control-Failure-Handling AVP is set to the value
CONTINUE or RETRY_AND_TERMINATE, the service will be granted to the CONTINUE or RETRY_AND_TERMINATE, the service will be granted to the
end user when the timer Tx expires. An answer message with granted end user when the Tx timer expires. An answer message with granted
units may arrive later if the base protocol transport failover units may arrive later if the base protocol transport failover
occurred in the path to the credit-control server. (The Twinit occurred in the path to the credit-control server. (The Twinit
default value is 3 times more than the Tx recommended value.) The default value is 3 times more than the Tx timeout recommended value.)
credit-control client SHOULD grant the service to the end user, start The credit-control client SHOULD grant the service to the end user,
monitoring the resource usage, and wait for the possible late answer start monitoring the resource usage, and wait for the possible late
until the timeout of the request (e.g., 120 seconds). If the request answer until the timeout of the request (e.g., 120 seconds). If the
fails and the CC-Session-Failover AVP is set to request fails and the CC-Session-Failover AVP is set to
FAILOVER_NOT_SUPPORTED, the credit-control client terminates or FAILOVER_NOT_SUPPORTED, the credit-control client terminates or
continues the service depending on the value set in the CCFH and MUST continues the service depending on the value set in the CCFH and MUST
free all the reserved resources for the credit-control session. If free all the reserved resources for the credit-control session. If
the protocol error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is the protocol error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is
received or the request times out and the CC-Session-Failover AVP is received or the request times out and the CC-Session-Failover AVP is
set to FAILOVER_SUPPORTED, the credit-control client MAY send the set to FAILOVER_SUPPORTED, the credit-control client MAY send the
request to a backup server, if possible. If the credit-control request to a backup server, if possible. If the credit-control
client receives a successful answer from the backup server, it client receives a successful answer from the backup server, it
continues the credit-control session with such a server. If the re- continues the credit-control session with such a server. If the re-
transmitted request also fails, the credit-control client terminates transmitted request also fails, the credit-control client terminates
skipping to change at page 44, line 37 skipping to change at page 44, line 37
event. Services offered by application service providers whose event. Services offered by application service providers whose
prices are not known in the credit-control client might exist. The prices are not known in the credit-control client might exist. The
end user might also want to get an estimation of the price of a end user might also want to get an estimation of the price of a
service event before requesting it. service event before requesting it.
A Diameter credit-control client requesting the cost information MUST A Diameter credit-control client requesting the cost information MUST
set the CC-Request-Type AVP equal to EVENT_REQUEST, include the set the CC-Request-Type AVP equal to EVENT_REQUEST, include the
Requested-Action AVP set to PRICE_ENQUIRY, and set the requested Requested-Action AVP set to PRICE_ENQUIRY, and set the requested
service event information into the Service-Identifier AVP in the service event information into the Service-Identifier AVP in the
Credit-Control-Request message. Additional service event information Credit-Control-Request message. Additional service event information
may be sent as service specific AVPs or within the Service-Parameter- may be sent as service-specific AVPs or within the Service-Parameter-
Info AVP. The Service-Context-Id AVP indicates the service specific Info AVP. The Service-Context-Id AVP indicates the service-specific
document applicable to the request. document applicable to the request.
The credit-control server calculates the cost of the requested The credit-control server calculates the cost of the requested
service event, but it does not perform any account balance check or service event, but it does not perform any account balance check or
credit-reservation from the account. credit-reservation from the account.
The estimated cost of the requested service event is returned to the The estimated cost of the requested service event is returned to the
credit-control client in the Cost-Information AVP in the Credit- credit-control client in the Cost-Information AVP in the Credit-
Control-Answer message. Control-Answer message.
skipping to change at page 45, line 19 skipping to change at page 45, line 19
without reserving any units from the account at the time of the without reserving any units from the account at the time of the
inquiry. This method does not guarantee that credit would be left inquiry. This method does not guarantee that credit would be left
when the Diameter credit-control client requests the debiting of the when the Diameter credit-control client requests the debiting of the
account with a separate request. account with a separate request.
A Diameter credit-control client requesting the balance check MUST A Diameter credit-control client requesting the balance check MUST
set the CC-Request-Type AVP equal to EVENT_REQUEST, include a set the CC-Request-Type AVP equal to EVENT_REQUEST, include a
Requested-Action AVP set to CHECK_BALANCE, and include the Requested-Action AVP set to CHECK_BALANCE, and include the
Subscription-Id AVP or Subscription-Id-Extension AVP in order to Subscription-Id AVP or Subscription-Id-Extension AVP in order to
identify the end user in the credit-control server. The Service- identify the end user in the credit-control server. The Service-
Context-Id AVP indicates the service specific document applicable to Context-Id AVP indicates the service-specific document applicable to
the request. the request.
The credit-control server makes the balance check, but it does not The credit-control server makes the balance check, but it does not
make any credit-reservation from the account. make any credit-reservation from the account.
The result of balance check (ENOUGH_CREDIT/NO_CREDIT) is returned to The result of balance check (ENOUGH_CREDIT/NO_CREDIT) is returned to
the credit-control client in the Check-Balance-Result AVP in the the credit-control client in the Check-Balance-Result AVP in the
Credit-Control-Answer message. Credit-Control-Answer message.
6.3. Direct Debiting 6.3. Direct Debiting
skipping to change at page 45, line 48 skipping to change at page 45, line 48
client SHOULD be sure that the requested service event execution client SHOULD be sure that the requested service event execution
would be successful when this scenario is used. would be successful when this scenario is used.
In the Credit-Control-Request message, the CC-Request-Type is set to In the Credit-Control-Request message, the CC-Request-Type is set to
the value EVENT_REQUEST and the Requested-Action AVP is set to the value EVENT_REQUEST and the Requested-Action AVP is set to
DIRECT_DEBITING. The Subscription-Id AVP or Subscription-Id- DIRECT_DEBITING. The Subscription-Id AVP or Subscription-Id-
Extension AVP SHOULD be included to identify the end user in the Extension AVP SHOULD be included to identify the end user in the
credit-control server. The Event-Timestamp AVP SHOULD be included in credit-control server. The Event-Timestamp AVP SHOULD be included in
the request and contain the time when the service event is requested the request and contain the time when the service event is requested
in the service element. The Service-Context-Id AVP indicates the in the service element. The Service-Context-Id AVP indicates the
service specific document applicable to the request. service-specific document applicable to the request.
The Diameter credit-control client MAY include the monetary amount to The Diameter credit-control client MAY include the monetary amount to
be charged in the Requested-Service-Unit AVP, if it knows the cost of be charged in the Requested-Service-Unit AVP, if it knows the cost of
the service event. If the Diameter credit-control client does not the service event. If the Diameter credit-control client does not
know the cost of the service event, the Requested-Service-Unit AVP know the cost of the service event, the Requested-Service-Unit AVP
MAY contain the number of requested service events. The Service- MAY contain the number of requested service events. The Service-
Identifier AVP always indicates the service concerned. Additional Identifier AVP always indicates the service concerned. Additional
service event information to be rated MAY be sent as service specific service event information to be rated MAY be sent as service-specific
AVPs or within the Service-Parameter-Info AVP. AVPs or within the Service-Parameter-Info AVP.
The credit-control server SHOULD rate the service event and deduct The credit-control server SHOULD rate the service event and deduct
the corresponding monetary amount from the end user's account. If the corresponding monetary amount from the end user's account. If
the type of the Requested-Service-Unit AVP is money, no rating is the type of the Requested-Service-Unit AVP is money, no rating is
needed, but the corresponding monetary amount is deducted from the needed, but the corresponding monetary amount is deducted from the
end user's account. end user's account.
The credit-control server returns the Granted-Service-Unit AVP in the The credit-control server returns the Granted-Service-Unit AVP in the
Credit-Control-Answer message to the Diameter credit-control client. Credit-Control-Answer message to the Diameter credit-control client.
The Granted-Service-Unit AVP contains the amount of service units The Granted-Service-Unit AVP contains the amount of service units
that the Diameter credit-control client can provide to the end user. that the Diameter credit-control client can provide to the end user.
The type of the Granted-Service-Unit can be time, volume, service The type of the Granted-Service-Unit can be time, volume, service-
specific, or money, depending on the type of service event. specific, or money, depending on the type of service event.
If the credit-control server determines that no credit-control is If the credit-control server determines that no credit-control is
needed for the service, it can include the result code indicating needed for the service, it can include the result code indicating
that the credit-control is not applicable (e.g., service is free of that the credit-control is not applicable (e.g., service is free of
charge). charge).
For informative purposes, the Credit-Control-Answer message MAY also For informative purposes, the Credit-Control-Answer message MAY also
include the Cost-Information AVP containing the estimated total cost include the Cost-Information AVP containing the estimated total cost
of the requested service. of the requested service.
skipping to change at page 46, line 42 skipping to change at page 46, line 42
6.4. Refund 6.4. Refund
Some services may refund service units to the end user's account; for Some services may refund service units to the end user's account; for
example, gaming services. example, gaming services.
The credit-control client MUST set CC-Request-Type to the value The credit-control client MUST set CC-Request-Type to the value
EVENT_REQUEST and the Requested-Action AVP to REFUND_ACCOUNT in the EVENT_REQUEST and the Requested-Action AVP to REFUND_ACCOUNT in the
Credit-Control-Request message. The Subscription-Id AVP or Credit-Control-Request message. The Subscription-Id AVP or
Subscription-Id-Extension AVP SHOULD be included to identify the end Subscription-Id-Extension AVP SHOULD be included to identify the end
user in the credit-control server. The Service-Context-Id AVP user in the credit-control server. The Service-Context-Id AVP
indicates the service specific document applicable to the request. indicates the service-specific document applicable to the request.
The Diameter credit-control client MAY include the monetary amount to The Diameter credit-control client MAY include the monetary amount to
be refunded in the Requested-Service-Unit AVP. The Service- be refunded in the Requested-Service-Unit AVP. The Service-
Identifier AVP always indicates the concerned service. If the Identifier AVP always indicates the concerned service. If the
Diameter credit-control client does not know the monetary amount to Diameter credit-control client does not know the monetary amount to
be refunded, in addition to the Service-Identifier AVP it MAY send be refunded, in addition to the Service-Identifier AVP it MAY send
service specific AVPs or the Service-Parameter-Info AVP containing service-specific AVPs or the Service-Parameter-Info AVP containing
additional service event information to be rated. additional service event information to be rated.
For informative purposes, the Credit-Control-Answer message MAY also For informative purposes, the Credit-Control-Answer message MAY also
include the Cost-Information AVP containing the estimated monetary include the Cost-Information AVP containing the estimated monetary
amount of refunded unit. amount of refunded unit.
6.5. Failure Procedure 6.5. Failure Procedure
Failover to an alternative credit-control server is allowed for a one Failover to an alternative credit-control server is allowed for a one
time event, as the server is not maintaining session states. For time event, as the server is not maintaining session states. For
skipping to change at page 47, line 28 skipping to change at page 47, line 28
server. Failover may occur at any point in the path between the server. Failover may occur at any point in the path between the
credit-control client and the credit-control server if a transport credit-control client and the credit-control server if a transport
failure is detected with a peer, as described in [RFC6733]. Because failure is detected with a peer, as described in [RFC6733]. Because
there can be duplicate requests for various reasons, the credit- there can be duplicate requests for various reasons, the credit-
control server is responsible for real time duplicate detection. control server is responsible for real time duplicate detection.
Implementation issues for duplicate detection are discussed in Implementation issues for duplicate detection are discussed in
[RFC6733], Appendix C. [RFC6733], Appendix C.
When the credit-control client detects a communication failure with When the credit-control client detects a communication failure with
the credit-control server, its behavior depends on the requested the credit-control server, its behavior depends on the requested
action. The timer Tx (as defined in Section 13) is used in the action. The Tx timer (as defined in Section 13) is used in the
credit-control client to supervise the communication with the credit- credit-control client to supervise the communication with the credit-
control server. control server.
If the requested action is PRICE_ENQUIRY or CHECK_BALANCE and If the requested action is PRICE_ENQUIRY or CHECK_BALANCE and
communication failure is detected, the credit-control client SHOULD communication failure is detected, the credit-control client SHOULD
forward the request messages to an alternative credit-control server, forward the request messages to an alternative credit-control server,
if possible. The secondary credit-control server name, if received if possible. The secondary credit-control server name, if received
from the home Diameter AAA server, can be used as an address of from the home Diameter AAA server, can be used as an address of
backup server. backup server.
skipping to change at page 48, line 18 skipping to change at page 48, line 18
service will be debited, as the user's account may be empty when the service will be debited, as the user's account may be empty when the
server successfully processes the request.) The credit-control server successfully processes the request.) The credit-control
client MUST mark these request messages as possible duplicates by client MUST mark these request messages as possible duplicates by
setting the T-flag in the command header as described in [RFC6733], setting the T-flag in the command header as described in [RFC6733],
Section 3. Section 3.
If the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the If the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the
service SHOULD be granted, even if credit-control messages cannot be service SHOULD be granted, even if credit-control messages cannot be
delivered and messages are not buffered. delivered and messages are not buffered.
If the timer Tx expires, the credit-control client MUST continue the If the Tx timer expires, the credit-control client MUST continue the
service and wait for a possible late answer. If the request times service and wait for a possible late answer. If the request times
out, the credit-control client re-transmits the request (marked with out, the credit-control client re-transmits the request (marked with
T-flag) to a backup credit-control server, if possible. If the re- T-flag) to a backup credit-control server, if possible. If the re-
transmitted request also times out, or if a temporary error is transmitted request also times out, or if a temporary error is
received in answer, the credit-control client buffers the request if received in answer, the credit-control client buffers the request if
the value of the Direct-Debiting-Failure-Handling AVP is set to the value of the Direct-Debiting-Failure-Handling AVP is set to
TERMINATE_OR_BUFFER. If a failed answer is received for the re- TERMINATE_OR_BUFFER. If a failed answer is received for the re-
transmitted request, the credit-control client frees all the transmitted request, the credit-control client frees all the
resources reserved for the event message and deletes the request resources reserved for the event message and deletes the request
regardless of the value of the DDFH. regardless of the value of the DDFH.
skipping to change at page 51, line 14 skipping to change at page 51, line 14
+----------+-------------------------------+-------------+----------+ +----------+-------------------------------+-------------+----------+
| State | Event | Action | New | | State | Event | Action | New |
| | | | State | | | | | State |
+----------+-------------------------------+-------------+----------+ +----------+-------------------------------+-------------+----------+
| Idle | Client or device requests | Send AA | PendingI | | Idle | Client or device requests | Send AA | PendingI |
| | access/service | request | | | | access/service | request | |
| | | with added | | | | | with added | |
| | | CC AVPs, | | | | | CC AVPs, | |
| | | start Tx | | | | | start Tx | |
| | | timer | |
| PendingI | Successful AA req. answer | Grant | Open | | PendingI | Successful AA req. answer | Grant | Open |
| | received | service to | | | | received | service to | |
| | | end user, | | | | | end user, | |
| | | stop Tx | | | | | stop Tx | |
| PendingI | Tx expired | Disconnect | Idle | | | | timer | |
| PendingI | Tx timer expired | Disconnect | Idle |
| | | user/dev | | | | | user/dev | |
| PendingI | Failed AA answer received | Disconnect | Idle | | PendingI | Failed AA answer received | Disconnect | Idle |
| | | user/dev | | | | | user/dev | |
| PendingI | AA answer received with | Grant | Idle | | PendingI | AA answer received with | Grant | Idle |
| | result code equal to | service to | | | | result code equal to | service to | |
| | CREDIT_CONTROL_NOT_APPLICABLE | end user | | | | CREDIT_CONTROL_NOT_APPLICABLE | end user | |
| PendingI | User service terminated | Queue | PendingI | | PendingI | User service terminated | Queue | PendingI |
| | | termination | | | | | termination | |
| | | event | | | | | event | |
| PendingI | Change in rating condition | Queue | PendingI | | PendingI | Change in rating condition | Queue | PendingI |
skipping to change at page 52, line 12 skipping to change at page 52, line 12
Table 2: CLIENT, SESSION BASED for the first interrogation with AA Table 2: CLIENT, SESSION BASED for the first interrogation with AA
request request
+----------+-------------------------------+-------------+----------+ +----------+-------------------------------+-------------+----------+
| State | Event | Action | New | | State | Event | Action | New |
| | | | State | | | | | State |
+----------+-------------------------------+-------------+----------+ +----------+-------------------------------+-------------+----------+
| Idle | Client or device requests | Send CC | PendingI | | Idle | Client or device requests | Send CC | PendingI |
| | access/service | initial | | | | access/service | initial | |
| | | req., start | | | | | req., start | |
| | | Tx | | | | | Tx timer | |
| PendingI | Successful CC initial answer | Stop Tx | Open | | PendingI | Successful CC initial answer | Stop Tx | Open |
| | received | | | | | received | timer | |
| PendingI | Failure to send, or temporary | Grant | Idle | | PendingI | Failure to send, or temporary | Grant | Idle |
| | error and CCFH equal to | service to | | | | error and CCFH equal to | service to | |
| | CONTINUE | end user | | | | CONTINUE | end user | |
| PendingI | Failure to send, or temporary | Terminate | Idle | | PendingI | Failure to send, or temporary | Terminate | Idle |
| | error and CCFH equal to | end user's | | | | error and CCFH equal to | end user's | |
| | TERMINATE or to | service | | | | TERMINATE or to | service | |
| | RETRY_AND_TERMINATE | | | | | RETRY_AND_TERMINATE | | |
| PendingI | Tx expired and CCFH equal to | Terminate | Idle | | PendingI | Tx timer expired and CCFH | Terminate | Idle |
| | TERMINATE | end user's | | | | equal to TERMINATE | end user's | |
| | | service | | | | | service | |
| PendingI | Tx expired and CCFH equal to | Grant | PendingI | | PendingI | Tx timer expired and CCFH | Grant | PendingI |
| | CONTINUE or to | service to | | | | equal to CONTINUE or to | service to | |
| | RETRY_AND_TERMINATE | end user | | | | RETRY_AND_TERMINATE | end user | |
| PendingI | CC initial answer received | Terminate | Idle | | PendingI | CC initial answer received | Terminate | Idle |
| | with result code | end user's | | | | with result code | end user's | |
| | END_USER_SERVICE_DENIED or | service | | | | END_USER_SERVICE_DENIED or | service | |
| | USER_UNKNOWN | | | | | USER_UNKNOWN | | |
| PendingI | CC initial answer received | Grant | Idle | | PendingI | CC initial answer received | Grant | Idle |
| | with result code equal to | service to | | | | with result code equal to | service to | |
| | CREDIT_CONTROL_NOT_APPLICABLE | end user | | | | CREDIT_CONTROL_NOT_APPLICABLE | end user | |
| PendingI | Failed CC initial answer | Grant | Idle | | PendingI | Failed CC initial answer | Grant | Idle |
| | received and CCFH equal to | service to | | | | received and CCFH equal to | service to | |
skipping to change at page 53, line 12 skipping to change at page 53, line 12
Table 3: CLIENT, SESSION BASED for the first interrogation with CCR Table 3: CLIENT, SESSION BASED for the first interrogation with CCR
+----------+-------------------------------+-------------+----------+ +----------+-------------------------------+-------------+----------+
| State | Event | Action | New | | State | Event | Action | New |
| | | | State | | | | | State |
+----------+-------------------------------+-------------+----------+ +----------+-------------------------------+-------------+----------+
| Open | Granted unit elapses and no | Send CC | PendingU | | Open | Granted unit elapses and no | Send CC | PendingU |
| | final unit indication | update | | | | final unit indication | update | |
| | received | req., start | | | | received | req., start | |
| | | Tx | | | | | Tx timer | |
| Open | Granted unit elapses and | Terminate | PendingT | | Open | Granted unit elapses and | Terminate | PendingT |
| | final unit action equal to | end user's | | | | final unit action equal to | end user's | |
| | TERMINATE received | service, | | | | TERMINATE received | service, | |
| | | send CC | | | | | send CC | |
| | | termination | | | | | termination | |
| | | req. | | | | | req. | |
| Open | Change in rating condition in | Send CC | PendingU | | Open | Change in rating condition in | Send CC | PendingU |
| | queue | update | | | | queue | update | |
| | | req., Start | | | | | req., Start | |
| | | Tx | | | | | Tx timer | |
| Open | Service terminated in queue | Send CC | PendingT | | Open | Service terminated in queue | Send CC | PendingT |
| | | termination | | | | | termination | |
| | | req. | | | | | req. | |
| Open | Change in rating condition or | Send CC | PendingU | | Open | Change in rating condition or | Send CC | PendingU |
| | Validity-Time elapses | update | | | | Validity-Time elapses | update | |
| | | req., Start | | | | | req., Start | |
| | | Tx | | | | | Tx timer | |
| Open | User service terminated | Send CC | PendingT | | Open | User service terminated | Send CC | PendingT |
| | | termination | | | | | termination | |
| | | req. | | | | | req. | |
| Open | RAR received | Send RAA | PendingU | | Open | RAR received | Send RAA | PendingU |
| | | followed by | | | | | followed by | |
| | | CC update | | | | | CC update | |
| | | req., start | | | | | req., start | |
| | | Tx | | | | | Tx timer | |
| PendingU | Successful CC update answer | Stop Tx | Open | | PendingU | Successful CC update answer | Stop Tx | Open |
| | received | | | | | received | timer | |
| PendingU | Failure to send, or temporary | Grant | Idle | | PendingU | Failure to send, or temporary | Grant | Idle |
| | error and CCFH equal to | service to | | | | error and CCFH equal to | service to | |
| | CONTINUE | end user | | | | CONTINUE | end user | |
| PendingU | Failure to send, or temporary | Terminate | Idle | | PendingU | Failure to send, or temporary | Terminate | Idle |
| | error and CCFH equal to | end user's | | | | error and CCFH equal to | end user's | |
| | TERMINATE or to | service | | | | TERMINATE or to | service | |
| | RETRY_AND_TERMINATE | | | | | RETRY_AND_TERMINATE | | |
| PendingU | Tx expired and CCFH equal to | Terminate | Idle | | PendingU | Tx timer expired and CCFH | Terminate | Idle |
| | TERMINATE | end user's | | | | equal to TERMINATE | end user's | |
| | | service | | | | | service | |
| PendingU | Tx expired and CCFH equal to | Grant | PendingU | | PendingU | Tx timer expired and CCFH | Grant | PendingU |
| | CONTINUE or to | service to | | | | equal to CONTINUE or to | service to | |
| | RETRY_AND_TERMINATE | end user | | | | RETRY_AND_TERMINATE | end user | |
| PendingU | CC update answer received | Terminate | Idle | | PendingU | CC update answer received | Terminate | Idle |
| | with result code | end user's | | | | with result code | end user's | |
| | END_USER_SERVICE_DENIED | service | | | | END_USER_SERVICE_DENIED | service | |
| PendingU | CC update answer received | Grant | Idle | | PendingU | CC update answer received | Grant | Idle |
| | with result code equal to | service to | | | | with result code equal to | service to | |
| | CREDIT_CONTROL_NOT_APPLICABLE | end user | | | | CREDIT_CONTROL_NOT_APPLICABLE | end user | |
| PendingU | Failed CC update answer | Grant | Idle | | PendingU | Failed CC update answer | Grant | Idle |
| | received and CCFH equal to | service to | | | | received and CCFH equal to | service to | |
| | CONTINUE | end user | | | | CONTINUE | end user | |
skipping to change at page 54, line 44 skipping to change at page 54, line 44
interrogations interrogations
+----------+--------------------------------+------------+----------+ +----------+--------------------------------+------------+----------+
| State | Event | Action | New | | State | Event | Action | New |
| | | | State | | | | | State |
+----------+--------------------------------+------------+----------+ +----------+--------------------------------+------------+----------+
| Idle | Client or device requests a | Send CC | PendingE | | Idle | Client or device requests a | Send CC | PendingE |
| | one-time service | event | | | | one-time service | event | |
| | | req., | | | | | req., | |
| | | Start Tx | | | | | Start Tx | |
| | | timer | |
| Idle | Request in storage | Send | PendingB | | Idle | Request in storage | Send | PendingB |
| | | stored | | | | | stored | |
| | | request | | | | | request | |
| PendingE | Successful CC event answer | Grant | Idle | | PendingE | Successful CC event answer | Grant | Idle |
| | received | service to | | | | received | service to | |
| | | end user | | | | | end user | |
| PendingE | Failure to send, temporary | Indicate | Idle | | PendingE | Failure to send, temporary | Indicate | Idle |
| | error, failed CC event answer | service | | | | error, failed CC event answer | service | |
| | received, or Tx expired; | error | | | | received, or Tx timer expired; | error | |
| | requested action CHECK_BALANCE | | | | | requested action CHECK_BALANCE | | |
| | or PRICE_ENQUIRY | | | | | or PRICE_ENQUIRY | | |
| PendingE | CC event answer received with | Terminate | Idle | | PendingE | CC event answer received with | Terminate | Idle |
| | result code | end user's | | | | result code | end user's | |
| | END_USER_SERVICE_DENIED or | service | | | | END_USER_SERVICE_DENIED or | service | |
| | USER_UNKNOWN and Tx running | | | | | USER_UNKNOWN and Tx timer | | |
| | running | | |
| PendingE | CC event answer received with | Grant | Idle | | PendingE | CC event answer received with | Grant | Idle |
| | result code | service to | | | | result code | service to | |
| | CREDIT_CONTROL_NOT_APPLICABLE; | end user | | | | CREDIT_CONTROL_NOT_APPLICABLE; | end user | |
| | requested action | | | | | requested action | | |
| | DIRECT_DEBITING | | | | | DIRECT_DEBITING | | |
| PendingE | Failure to send, temporary | Grant | Idle | | PendingE | Failure to send, temporary | Grant | Idle |
| | error, failed CC event answer | service to | | | | error, failed CC event answer | service to | |
| | received; requested action | end user | | | | received; requested action | end user | |
| | DIRECT_DEBITING; DDFH equal to | | | | | DIRECT_DEBITING; DDFH equal to | | |
| | CONTINUE | | | | | CONTINUE | | |
| PendingE | Failed CC event answer | Terminate | Idle | | PendingE | Failed CC event answer | Terminate | Idle |
| | received or temporary error; | end user's | | | | received or temporary error; | end user's | |
| | requested action | service | | | | requested action | service | |
| | DIRECT_DEBITING; DDFH equal to | | | | | DIRECT_DEBITING; DDFH equal to | | |
| | TERMINATE_OR_BUFFER and Tx | | | | | TERMINATE_OR_BUFFER and Tx | | |
| | running | | | | | timer running | | |
| PendingE | Tx expired; requested action | Grant | PendingE | | PendingE | Tx timer expired; requested | Grant | PendingE |
| | DIRECT_DEBITING | service to | | | | action DIRECT_DEBITING | service to | |
| | | end user | | | | | end user | |
| PendingE | Failure to send; requested | Store | Idle | | PendingE | Failure to send; requested | Store | Idle |
| | action DIRECT_DEBITING; DDFH | request | | | | action DIRECT_DEBITING; DDFH | request | |
| | equal to TERMINATE_OR_BUFFER | with | | | | equal to TERMINATE_OR_BUFFER | with | |
| | | T-flag | | | | | T-flag | |
| PendingE | Temporary error; requested | Store | Idle | | PendingE | Temporary error; requested | Store | Idle |
| | action DIRECT_DEBITING; DDFH | request | | | | action DIRECT_DEBITING; DDFH | request | |
| | equal to TERMINATE_OR_BUFFER; | | | | | equal to TERMINATE_OR_BUFFER; | | |
| | Tx expired | | | | | Tx timer expired | | |
| PendingE | Failed answer or answer | | Idle | | PendingE | Failed answer or answer | | Idle |
| | received with result code | | | | | received with result code | | |
| | END_USER_SERVICE DENIED or | | | | | END_USER_SERVICE DENIED or | | |
| | USER_UNKNOWN; requested action | | | | | USER_UNKNOWN; requested action | | |
| | DIRECT_DEBITING; Tx expired | | | | | DIRECT_DEBITING; Tx timer | | |
| | expired | | |
| PendingE | Failed CC event answer | Indicate | Idle | | PendingE | Failed CC event answer | Indicate | Idle |
| | received; requested action | service | | | | received; requested action | service | |
| | REFUND_ACCOUNT | error and | | | | REFUND_ACCOUNT | error and | |
| | | delete | | | | | delete | |
| | | request | | | | | request | |
| PendingE | Failure to send or Tx expired; | Store | Idle | | PendingE | Failure to send or Tx timer | Store | Idle |
| | requested action | request | | | | expired; requested action | request | |
| | REFUND_ACCOUNT | with | | | | REFUND_ACCOUNT | with | |
| | | T-flag | | | | | T-flag | |
| PendingE | Temporary error, and requested | Store | Idle | | PendingE | Temporary error, and requested | Store | Idle |
| | action REFUND_ACCOUNT | request | | | | action REFUND_ACCOUNT | request | |
| PendingB | Successful CC answer received | Delete | Idle | | PendingB | Successful CC answer received | Delete | Idle |
| | | request | | | | | request | |
| PendingB | Failed CC answer received | Delete | Idle | | PendingB | Failed CC answer received | Delete | Idle |
| | | request | | | | | request | |
| PendingB | Failure to send or temporary | | Idle | | PendingB | Failure to send or temporary | | Idle |
| | error | | | | | error | | |
skipping to change at page 60, line 11 skipping to change at page 60, line 42
-Info-IMEI | | | | -Info-IMEI | | | |
Value-Digits 447 8.10 Integer64 | M | | V | Value-Digits 447 8.10 Integer64 | M | | V |
Validity-Time 448 8.33 Unsigned32 | M | | V | Validity-Time 448 8.33 Unsigned32 | M | | V |
8.1. CC-Correlation-Id AVP 8.1. CC-Correlation-Id AVP
The CC-Correlation-Id AVP (AVP Code 411) is of type OctetString and The CC-Correlation-Id AVP (AVP Code 411) is of type OctetString and
contains information to correlate credit-control requests generated contains information to correlate credit-control requests generated
for different components of the service; e.g., transport and service for different components of the service; e.g., transport and service
level. The one who allocates the Service-Context-Id (i.e., unique level. The one who allocates the Service-Context-Id (i.e., unique
identifier of a service specific document) is also responsible for identifier of a service-specific document) is also responsible for
defining the content and encoding of the CC-Correlation-Id AVP. defining the content and encoding of the CC-Correlation-Id AVP.
8.2. CC-Request-Number AVP 8.2. CC-Request-Number AVP
The CC-Request-Number AVP (AVP Code 415) is of type Unsigned32 and The CC-Request-Number AVP (AVP Code 415) is of type Unsigned32 and
identifies this request within one session. As Session-Id AVPs are identifies this request within one session. As Session-Id AVPs are
globally unique, the combination of Session-Id and CC-Request-Number globally unique, the combination of Session-Id and CC-Request-Number
AVPs is also globally unique and can be used in matching credit- AVPs is also globally unique and can be used in matching credit-
control messages with confirmations. An easy way to produce unique control messages with confirmations. An easy way to produce unique
numbers is to set the value to 0 for a credit-control request of type numbers is to set the value to 0 for a credit-control request of type
skipping to change at page 73, line 46 skipping to change at page 74, line 35
order to implement the policy-defined action. order to implement the policy-defined action.
The Final-Unit-Action AVP defines the behavior of the service element The Final-Unit-Action AVP defines the behavior of the service element
when the user's account cannot cover the cost of the service and MUST when the user's account cannot cover the cost of the service and MUST
always be present if the Final-Unit-Indication AVP is included in a always be present if the Final-Unit-Indication AVP is included in a
command. command.
If the Final-Unit-Action AVP is set to TERMINATE, the Final-Unit- If the Final-Unit-Action AVP is set to TERMINATE, the Final-Unit-
Indication group MUST NOT contain any other AVPs. Indication group MUST NOT contain any other AVPs.
If the Final-Unit-Action AVP is set to REDIRECT at least the If the Final-Unit-Action AVP is set to REDIRECT at least one of the
Redirect-Server AVP MUST be present. The Restriction-Filter-Rule AVP Redirect-Server and Redirect-Server-Extension AVPs MUST be present.
or the Filter-Id AVP MAY be present in the Credit-Control-Answer The Restriction-Filter-Rule AVP or the Filter-Id AVP MAY be present
message if the user is also allowed to access other services that are in the Credit-Control-Answer message if the user is also allowed to
not accessible through the address given in the Redirect-Server AVP. 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 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. Restriction-Filter-Rule AVP or the Filter-Id AVP SHOULD be present.
The Filter-Id AVP is defined in [RFC7155]. The Filter-Id AVP can be The Filter-Id AVP is defined in [RFC7155]. The Filter-Id AVP can be
used to reference an IP filter list installed in the access device by used to reference an IP filter list installed in the access device by
means other than the Diameter credit-control application, e.g., means other than the Diameter credit-control application, e.g.,
locally configured or configured by another entity. locally configured or configured by another entity.
If the Final-Unit-Action AVP is set to REDIRECT and the type of If the Final-Unit-Action AVP is set to REDIRECT and the type of
skipping to change at page 78, line 4 skipping to change at page 78, line 38
contains the refunded units. contains the refunded units.
CHECK_BALANCE 2 CHECK_BALANCE 2
This indicates a balance check request. In this case, the checking This indicates a balance check request. In this case, the checking
of the account balance is done without any credit reservation from of the account balance is done without any credit reservation from
the account. The Check-Balance-Result AVP in the Credit-Control- the account. The Check-Balance-Result AVP in the Credit-Control-
Answer command contains the result of the balance check. Answer command contains the result of the balance check.
PRICE_ENQUIRY 3 PRICE_ENQUIRY 3
This indicates a price enquiry request. In this case, neither This indicates a price enquiry request. In this case, neither
checking of the account balance nor reservation from the account will 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- be done; only the price of the service will be returned in the Cost-
Information AVP in the Credit-Control-Answer Command. Information AVP in the Credit-Control-Answer Command.
8.42. Service-Context-Id AVP 8.42. Service-Context-Id AVP
The Service-Context-Id AVP is of type UTF8String (AVP Code 461) and The Service-Context-Id AVP is of type UTF8String (AVP Code 461) and
contains a unique identifier of the Diameter credit-control service contains a unique identifier of the Diameter credit-control service-
specific document that applies to the request (as defined in specific document that applies to the request (as defined in
Section 4.1.2). This is an identifier allocated by the service Section 4.1.2). This is an identifier allocated by the service
provider, by the service element manufacturer, or by a provider, by the service element manufacturer, or by a
standardization body, and MUST uniquely identify a given Diameter standardization body, and MUST uniquely identify a given Diameter
credit-control service specific document. The format of the Service- credit-control service-specific document. The format of the Service-
Context-Id is: Context-Id is:
"service-context" "@" "domain" "service-context" "@" "domain"
service-context = Token service-context = Token
The Token is an arbitrary string of characters and digits. The Token is an arbitrary string of characters and digits.
'domain' represents the entity that allocated the Service-Context-Id. 'domain' represents the entity that allocated the Service-Context-Id.
It can be ietf.org, 3gpp.org, etc., if the identifier is allocated by It can be ietf.org, 3gpp.org, etc., if the identifier is allocated by
skipping to change at page 79, line 24 skipping to change at page 80, line 14
Service-Parameter-Info ::= < AVP Header: 440 > Service-Parameter-Info ::= < AVP Header: 440 >
{ Service-Parameter-Type } { Service-Parameter-Type }
{ Service-Parameter-Value } { Service-Parameter-Value }
8.44. Service-Parameter-Type AVP 8.44. Service-Parameter-Type AVP
The Service-Parameter-Type AVP is of type Unsigned32 (AVP Code 441) The Service-Parameter-Type AVP is of type Unsigned32 (AVP Code 441)
and defines the type of the service event specific parameter (e.g., and defines the type of the service event specific parameter (e.g.,
it can be the end-user location or service name). The different it can be the end-user location or service name). The different
parameters and their types are service specific, and the meanings of parameters and their types are service-specific, and the meanings of
these parameters are not defined in this document. Whoever allocates these parameters are not defined in this document. Whoever allocates
the Service-Context-Id (i.e., unique identifier of a service-specific the Service-Context-Id (i.e., unique identifier of a service-specific
document) is also responsible for assigning Service-Parameter-Type document) is also responsible for assigning Service-Parameter-Type
values for the service and ensuring their uniqueness within the given values for the service and ensuring their uniqueness within the given
service. The Service-Parameter-Value AVP contains the value service. The Service-Parameter-Value AVP contains the value
associated with the service parameter type. associated with the service parameter type.
8.45. Service-Parameter-Value AVP 8.45. Service-Parameter-Value AVP
The Service-Parameter-Value AVP is of type OctetString (AVP Code 442) The Service-Parameter-Value AVP is of type OctetString (AVP Code 442)
skipping to change at page 80, line 12 skipping to change at page 80, line 47
{ Subscription-Id-Type } { Subscription-Id-Type }
{ Subscription-Id-Data } { Subscription-Id-Data }
8.47. Subscription-Id-Type AVP 8.47. Subscription-Id-Type AVP
The Subscription-Id-Type AVP (AVP Code 450) is of type Enumerated, The Subscription-Id-Type AVP (AVP Code 450) is of type Enumerated,
and it is used to determine which type of identifier is carried by and it is used to determine which type of identifier is carried by
the Subscription-Id AVP. the Subscription-Id AVP.
This specification defines the following subscription identifiers. This specification defines the following subscription identifiers.
However, new Subscription-Id-Type values can be assigned by an IANA However, new Subscription-Id-Type values can be assigned by IANA as
designated expert, as defined in Section 12. A server MUST implement defined in Section 12. A server MUST implement all the Subscription-
all the Subscription-Id-Types required to perform credit Id-Types required to perform credit authorization for the services it
authorization for the services it supports, including possible future supports, including possible future values. Unknown or unsupported
values. Unknown or unsupported Subscription-Id-Types MUST be treated Subscription-Id-Types MUST be treated according to the 'M' flag rule,
according to the 'M' flag rule, as defined in [RFC6733]. as defined in [RFC6733].
END_USER_E164 0 END_USER_E164 0
The identifier is in international E.164 format (e.g., MSISDN), The identifier is in international E.164 format (e.g., MSISDN),
according to the ITU-T E.164 numbering plan defined in [E164] and according to the ITU-T E.164 numbering plan defined in [E164] and
[CE164]. [CE164].
END_USER_IMSI 1 END_USER_IMSI 1
The identifier is in international IMSI format, according to the The identifier is in international IMSI format, according to the
skipping to change at page 81, line 26 skipping to change at page 82, line 13
{ User-Equipment-Info-Value } { User-Equipment-Info-Value }
8.50. User-Equipment-Info-Type AVP 8.50. User-Equipment-Info-Type AVP
The User-Equipment-Info-Type AVP is of type Enumerated (AVP Code 459) The User-Equipment-Info-Type AVP is of type Enumerated (AVP Code 459)
and defines the type of user equipment information contained in the and defines the type of user equipment information contained in the
User-Equipment-Info-Value AVP. User-Equipment-Info-Value AVP.
This specification defines the following user equipment types. This specification defines the following user equipment types.
However, new User-Equipment-Info-Type values can be assigned by an However, new User-Equipment-Info-Type values can be assigned by an
IANA designated expert, as defined in Section 12. IANA as defined in Section 12.
IMEISV 0 IMEISV 0
The identifier contains the International Mobile Equipment Identifier The identifier contains the International Mobile Equipment Identifier
and Software Version in the international IMEISV format according to and Software Version in the international IMEISV format according to
3GPP TS 23.003 [TGPPIMEI]. 3GPP TS 23.003 [TGPPIMEI].
MAC 1 MAC 1
The 48-bit MAC address is formatted as described in [RFC3580]. The 48-bit MAC address is formatted as described in section 3.21 of
[RFC3580].
EUI64 2 EUI64 2
The 64-bit identifier used to identify the hardware instance of the The 64-bit identifier used to identify the hardware instance of the
product, as defined in [EUI64]. product, as defined in [EUI64].
MODIFIED_EUI64 3 MODIFIED_EUI64 3
There are a number of types of terminals that have identifiers other There are a number of types of terminals that have identifiers other
than IMEI, IEEE 802 MACs, or EUI-64. These identifiers can be than IMEI, IEEE 802 MACs, or EUI-64. These identifiers can be
skipping to change at page 82, line 45 skipping to change at page 83, line 30
The User-Equipment-Info-IMEISV (AVP Code TBD2) is of type The User-Equipment-Info-IMEISV (AVP Code TBD2) is of type
OctetString. The User-Equipment-Info-IMEISV AVP contains the OctetString. The User-Equipment-Info-IMEISV AVP contains the
International Mobile Equipment Identifier and Software Version in the International Mobile Equipment Identifier and Software Version in the
international IMEISV format according to 3GPP TS 23.003 [TGPPIMEI]. international IMEISV format according to 3GPP TS 23.003 [TGPPIMEI].
8.54. User-Equipment-Info-MAC AVP 8.54. User-Equipment-Info-MAC AVP
The User-Equipment-Info-MAC (AVP Code TBD3) is of type OctetString. The User-Equipment-Info-MAC (AVP Code TBD3) is of type OctetString.
The User-Equipment-Info-MAC AVP contains the 48-bit MAC address is The User-Equipment-Info-MAC AVP contains the 48-bit MAC address is
formatted as described in [RFC3580]. formatted as described in section 4.1.7.8 of [RFC5777].
8.55. User-Equipment-Info-EUI64 AVP 8.55. User-Equipment-Info-EUI64 AVP
The User-Equipment-Info-EUI64 (AVP Code TBD4) is of type OctetString. The User-Equipment-Info-EUI64 (AVP Code TBD4) is of type OctetString.
The UUser-Equipment-Info-EUI64 AVP contains the 64-bit identifier The UUser-Equipment-Info-EUI64 AVP contains the 64-bit identifier
used to identify the hardware instance of the product, as defined in used to identify the hardware instance of the product, as defined in
[EUI64]. [EUI64].
8.56. User-Equipment-Info-ModifiedEUI64 AVP 8.56. User-Equipment-Info-ModifiedEUI64 AVP
skipping to change at page 85, line 31 skipping to change at page 86, line 21
8.65. Redirect-Address-IPAddress AVP 8.65. Redirect-Address-IPAddress AVP
The Redirect-Address-IPAddress AVP (AVP Code TBD14) is of type The Redirect-Address-IPAddress AVP (AVP Code TBD14) is of type
Address and defines the IPv4 or IPv6 address of the redirect server Address and defines the IPv4 or IPv6 address of the redirect server
with which the end user is to be connected when the account cannot with which the end user is to be connected when the account cannot
cover the service cost. cover the service cost.
When encoded as an IPv6 address in 16 bytes, the IPv4-mapped IPv6 When encoded as an IPv6 address in 16 bytes, the IPv4-mapped IPv6
format [RFC4291] MAY be used to indicate an IPv4 address. format [RFC4291] MAY be used to indicate an IPv4 address.
The interpretation of Redirect-Address-IPAddress by the Diameter
Credit-control Client is a matter of local policy.
8.66. Redirect-Address-URL AVP 8.66. Redirect-Address-URL AVP
The Redirect-Address-URL AVP (AVP Code TBD15) is of type UTF8String The Redirect-Address-URL AVP (AVP Code TBD15) is of type UTF8String
and defines the address of the redirect server with which the end and defines the address of the redirect server with which the end
user is to be connected when the account cannot cover the service user is to be connected when the account cannot cover the service
cost. The address type is in the form of Uniform Resource Locator, cost. The address type is in the form of Uniform Resource Locator,
as defined in [RFC3986]. as defined in [RFC3986]. Note that individual URL schemes may
restrict the contents of the UTF8String.
8.67. Redirect-Address-SIP-URI AVP 8.67. Redirect-Address-SIP-URI AVP
The Redirect-Address-SIP-URI AVP (AVP Code TBD16) is of type The Redirect-Address-SIP-URI AVP (AVP Code TBD16) is of type
UTF8String and defines the address of the redirect server with which UTF8String and defines the address of the redirect server with which
the end user is to be connected when the account cannot cover the the end user is to be connected when the account cannot cover the
service cost. The address type is in the form of SIP Uniform service cost. The address type is in the form of SIP Uniform
Resource Identifier, as defined in [RFC3261]. Resource Identifier, as defined in [RFC3261].
8.68. QoS-Final-Unit-Indication AVP 8.68. QoS-Final-Unit-Indication AVP
skipping to change at page 86, line 35 skipping to change at page 87, line 26
order to implement the policy-defined action. order to implement the policy-defined action.
The Final-Unit-Action AVP defines the behavior of the service element The Final-Unit-Action AVP defines the behavior of the service element
when the user's account cannot cover the cost of the service and MUST when the user's account cannot cover the cost of the service and MUST
always be present if the QoS-Final-Unit-Indication AVP is included in always be present if the QoS-Final-Unit-Indication AVP is included in
a command. a command.
If the Final-Unit-Action AVP is set to TERMINATE, the QoS-Final-Unit- If the Final-Unit-Action AVP is set to TERMINATE, the QoS-Final-Unit-
Indication group MUST NOT contain any other AVPs. Indication group MUST NOT contain any other AVPs.
If the Final-Unit-Action AVP is set to REDIRECT at least the If the Final-Unit-Action AVP is set to REDIRECT at least one of the
Redirect-Server-Extension AVP MUST be present. The Filter-Rule AVP Redirect-Server and Redirect-Server-Extension AVPs MUST be present.
or the Filter-Id AVP MAY be present in the Credit-Control-Answer The Filter-Rule AVP or the Filter-Id AVP MAY be present in the
message if the user is also allowed to access other services that are Credit-Control-Answer message if the user is also allowed to access
not accessible through the address given in the Redirect-Server- other services that are not accessible through the address given in
Extension AVP or if the access to these services needs to be limited the Redirect-Server-Extension AVP or if the access to these services
in some way (e.g., QoS). needs to be limited in some way (e.g., QoS).
If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the
Filter-Rule AVP or the Filter-Id AVP SHOULD be present. Filter-Rule AVP or the Filter-Id AVP SHOULD be present.
The Filter-Rule AVP is defined in [RFC5777]. The Filter-Rule AVP can The Filter-Rule AVP is defined in [RFC5777]. The Filter-Rule AVP can
be used to define a specific condition and action combination. If be used to define a specific condition and action combination. If
used only with traffic conditions, it should define which traffic used only with traffic conditions, it should define which traffic
should allowed when no more service units are granted. However, if should allowed when no more service units are granted. However, if
QoS or treatment information exists in the AVP, these actions should QoS or treatment information exists in the AVP, these actions should
be executed, e.g., limiting the allowed traffic with certain QoS. be executed, e.g., limiting the allowed traffic with certain QoS.
skipping to change at page 89, line 18 skipping to change at page 90, line 8
0-1 Zero or one instance of the AVP MAY be present in the 0-1 Zero or one instance of the AVP MAY be present in the
message. It is considered an error if there is more message. It is considered an error if there is more
than one instance of the AVP. than one instance of the AVP.
1 One instance of the AVP MUST be present in the message. 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 1+ At least one instance of the AVP MUST be present in the
message. message.
10.1. Credit-Control AVP Table 10.1. Credit-Control AVP Table
The table in this section is used to represent which credit-control The table in this section is used to represent which credit-control
applications specific AVPs defined in this document are to be present application-specific AVPs defined in this document are to be present
in the credit-control messages. in the credit-control messages.
+-----------+ +-----------+
| Command | | Command |
| Code | | Code |
|-----+-----+ |-----+-----+
Attribute Name | CCR | CCA | Attribute Name | CCR | CCA |
------------------------------|-----+-----+ ------------------------------|-----+-----+
Acct-Multi-Session-Id | 0-1 | 0-1 | Acct-Multi-Session-Id | 0-1 | 0-1 |
Auth-Application-Id | 1 | 1 | Auth-Application-Id | 1 | 1 |
skipping to change at page 93, line 45 skipping to change at page 94, line 45
| |<-----------------------| | |<-----------------------|
| Access-Accept | | | Access-Accept | |
|<-----------------------| | |<-----------------------| |
| | | | | |
Figure 10: Message flow example with RADIUS prepaid - Diameter Figure 10: Message flow example with RADIUS prepaid - Diameter
credit-control interworking credit-control interworking
12. IANA Considerations 12. IANA Considerations
This section contains the namespaces that have either been created in This document uses several registries that were originally created in
this specification, or the values assigned to existing namespaces [RFC4006] or the values assigned to existing namespaces managed by
managed by IANA. IANA. IANA [SHALL update/has updated] these to reference this
document. The registries and their allocation policies are below.
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.
12.1. Application Identifier 12.1. Application Identifier
This specification assigns the value 4, 'Diameter Credit Control', to This specification assigns the value 4, 'Diameter Credit Control', to
the Application Identifier namespace defined in [RFC6733]. See the Application Identifier namespace defined in [RFC6733]. See
Section 1.3 for more information. Section 1.3 for more information.
12.2. Command Codes 12.2. Command Codes
This specification uses the value 272 from the Command code namespace This specification uses the value 272 from the Command code namespace
defined in [RFC6733] for the Credit-Control-Request (CCR) and Credit- defined in [RFC6733] for the Credit-Control-Request (CCR) and Credit-
Control-Answer (CCA) commands. Control-Answer (CCA) commands.
12.3. AVP Codes 12.3. AVP Codes
See Section 8 for the assignment of the namespace in this See Section 8 for the assignment of the namespace in this
specification. specification.
This document describes new AVP codes beyond those described in This document describes new AVP codes beyond those described in
RFC4006. IANA is requested to allocated codes for the AVPs defined [RFC4006]. IANA is requested to allocate codes for the AVPs defined
in the following Table 7. in the following Table 7.
+-----------------------------------+-------+--------------------+ +-----------------------------------+-------+--------------------+
| Attribute Name | Code | Defined in section | | Attribute Name | Code | Defined in section |
+-----------------------------------+-------+--------------------+ +-----------------------------------+-------+--------------------+
| User-Equipment-Info-Extension | TBD1 | 8.52 | | User-Equipment-Info-Extension | TBD1 | 8.52 |
| User-Equipment-Info-IMEISV | TBD2 | 8.53 | | User-Equipment-Info-IMEISV | TBD2 | 8.53 |
| User-Equipment-Info-MAC | TBD3 | 8.54 | | User-Equipment-Info-MAC | TBD3 | 8.54 |
| User-Equipment-Info-EUI64 | TBD4 | 8.55 | | User-Equipment-Info-EUI64 | TBD4 | 8.55 |
| User-Equipment-Info-ModifiedEUI64 | TBD5 | 8.56 | | User-Equipment-Info-ModifiedEUI64 | TBD5 | 8.56 |
skipping to change at page 95, line 15 skipping to change at page 96, line 15
12.4. Result-Code AVP Values 12.4. Result-Code AVP Values
This specification assigns the values 4010, 4011, 4012, 5030, 5031 This specification assigns the values 4010, 4011, 4012, 5030, 5031
from the Result-Code AVP value namespace defined in [RFC6733]. See from the Result-Code AVP value namespace defined in [RFC6733]. See
Section 9 for the assignment of the namespace in this specification. Section 9 for the assignment of the namespace in this specification.
12.5. CC-Request-Type AVP 12.5. CC-Request-Type AVP
As defined in Section 8.3, the CC-Request-Type AVP includes As defined in Section 8.3, the CC-Request-Type AVP includes
Enumerated type values 1 - 4. IANA has created and is maintaining a Enumerated type values 1 - 4. IANA has created and is maintaining a
namespace for this AVP. All remaining values are available for namespace for this AVP. The definition of new values is subject to
assignment by a Designated Expert [RFC8126], under the conditions for the Specification Required policy [RFC8126] and conditions for
enumerated values described in [RFC7423] Section 5.6. enumerated values described in [RFC7423] Section 5.6.
12.6. CC-Session-Failover AVP 12.6. CC-Session-Failover AVP
As defined in Section 8.4, the CC-Failover-Supported AVP includes As defined in Section 8.4, the CC-Failover-Supported AVP includes
Enumerated type values 0 - 1. IANA has created and is maintaining a Enumerated type values 0 - 1. IANA has created and is maintaining a
namespace for this AVP. All remaining values are available for namespace for this AVP. The definition of new values is subject to
assignment by a Designated Expert [RFC8126], under the conditions for the Specification Required policy [RFC8126] and conditions for
enumerated values described in [RFC7423] Section 5.6. enumerated values described in [RFC7423] Section 5.6.
12.7. CC-Unit-Type AVP 12.7. CC-Unit-Type AVP
As defined in Section 8.32, the CC-Unit-Type AVP includes Enumerated 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 type values 0 - 5. IANA has created and is maintaining a namespace
for this AVP. All remaining values are available for assignment by a for this AVP. The definition of new values is subject to the
Designated Expert [RFC8126], under the conditions for enumerated Specification Required policy [RFC8126] and conditions for enumerated
values described in [RFC7423] Section 5.6. values described in [RFC7423] Section 5.6.
12.8. Check-Balance-Result AVP 12.8. Check-Balance-Result AVP
As defined in Section 8.6, the Check-Balance-Result AVP includes As defined in Section 8.6, the Check-Balance-Result AVP includes
Enumerated type values 0 - 1. IANA has created and is maintaining a Enumerated type values 0 - 1. IANA has created and is maintaining a
namespace for this AVP. All remaining values are available for namespace for this AVP. The definition of new values is subject to
assignment by a Designated Expert [RFC8126], under the conditions for the Specification Required policy [RFC8126] and conditions for
enumerated values described in [RFC7423] Section 5.6. enumerated values described in [RFC7423] Section 5.6.
12.9. Credit-Control AVP 12.9. Credit-Control AVP
As defined in Section 8.13, the Credit-Control AVP includes As defined in Section 8.13, the Credit-Control AVP includes
Enumerated type values 0 - 1. IANA has created and is maintaining a Enumerated type values 0 - 1. IANA has created and is maintaining a
namespace for this AVP. All remaining values are available for namespace for this AVP. The definition of new values is subject to
assignment by a Designated Expert [RFC8126], under the conditions for the Specification Required policy [RFC8126] and conditions for
enumerated values described in [RFC7423] Section 5.6. enumerated values described in [RFC7423] Section 5.6.
12.10. Credit-Control-Failure-Handling AVP 12.10. Credit-Control-Failure-Handling AVP
As defined in Section 8.14, the Credit-Control-Failure-Handling AVP As defined in Section 8.14, the Credit-Control-Failure-Handling AVP
includes Enumerated type values 0 - 2. IANA has created and is includes Enumerated type values 0 - 2. IANA has created and is
maintaining a namespace for this AVP. All remaining values are maintaining a namespace for this AVP. The definition of new values
available for assignment by a Designated Expert [RFC8126], under the is subject to the Specification Required policy [RFC8126] and
conditions for enumerated values described in [RFC7423] Section 5.6. conditions for enumerated values described in [RFC7423] Section 5.6.
12.11. Direct-Debiting-Failure-Handling AVP 12.11. Direct-Debiting-Failure-Handling AVP
As defined in Section 8.15, the Direct-Debiting-Failure-Handling AVP As defined in Section 8.15, the Direct-Debiting-Failure-Handling AVP
includes Enumerated type values 0 - 1. IANA has created and is includes Enumerated type values 0 - 1. IANA has created and is
maintaining a namespace for this AVP. All remaining values are maintaining a namespace for this AVP. The definition of new values
available for assignment by a Designated Expert [RFC8126], under the is subject to the Specification Required policy [RFC8126] and
conditions for enumerated values described in [RFC7423] Section 5.6. conditions for enumerated values described in [RFC7423] Section 5.6.
12.12. Final-Unit-Action AVP 12.12. Final-Unit-Action AVP
As defined in Section 8.35, the Final-Unit-Action AVP includes As defined in Section 8.35, the Final-Unit-Action AVP includes
Enumerated type values 0 - 2. IANA has created and is maintaining a Enumerated type values 0 - 2. IANA has created and is maintaining a
namespace for this AVP. All remaining values are available for namespace for this AVP. The definition of new values is subject to
assignment by a Designated Expert [RFC8126], under the conditions for the Specification Required policy [RFC8126] and conditions for
enumerated values described in [RFC7423] Section 5.6. enumerated values described in [RFC7423] Section 5.6.
12.13. Multiple-Services-Indicator AVP 12.13. Multiple-Services-Indicator AVP
As defined in Section 8.40, the Multiple-Services-Indicator AVP As defined in Section 8.40, the Multiple-Services-Indicator AVP
includes Enumerated type values 0 - 1. IANA has created and is includes Enumerated type values 0 - 1. IANA has created and is
maintaining a namespace for this AVP. All remaining values are maintaining a namespace for this AVP. The definition of new values
available for assignment by a Designated Expert [RFC8126], under the is subject to the Specification Required policy [RFC8126] and
conditions for enumerated values described in [RFC7423] Section 5.6. conditions for enumerated values described in [RFC7423] Section 5.6.
12.14. Redirect-Address-Type AVP 12.14. Redirect-Address-Type AVP
As defined in Section 8.38, the Redirect-Address-Type AVP includes As defined in Section 8.38, the Redirect-Address-Type AVP includes
Enumerated type values 0 - 3. IANA has created and is maintaining a Enumerated type values 0 - 3. IANA has created and is maintaining a
namespace for this AVP. All remaining values are available for namespace for this AVP. The definition of new values is subject to
assignment by a Designated Expert [RFC8126], under the conditions for the Specification Required policy [RFC8126] and conditions for
enumerated values described in [RFC7423] Section 5.6. enumerated values described in [RFC7423] Section 5.6.
12.15. Requested-Action AVP 12.15. Requested-Action AVP
As defined in Section 8.41, the Requested-Action AVP includes As defined in Section 8.41, the Requested-Action AVP includes
Enumerated type values 0 - 3. IANA has created and is maintaining a Enumerated type values 0 - 3. IANA has created and is maintaining a
namespace for this AVP. All remaining values are available for namespace for this AVP. The definition of new values is subject to
assignment by a Designated Expert [RFC8126], under the conditions for the Specification Required policy [RFC8126] and conditions for
enumerated values described in [RFC7423] Section 5.6. enumerated values described in [RFC7423] Section 5.6.
12.16. Subscription-Id-Type AVP 12.16. Subscription-Id-Type AVP
As defined in Section 8.47, the Subscription-Id-Type AVP includes As defined in Section 8.47, the Subscription-Id-Type AVP includes
Enumerated type values 0 - 4. IANA has created and is maintaining a Enumerated type values 0 - 4. IANA has created and is maintaining a
namespace for this AVP. All remaining values are available for namespace for this AVP. The definition of new values is subject to
assignment by a Designated Expert [RFC8126], under the conditions for the Specification Required policy [RFC8126] and conditions for
enumerated values described in [RFC7423] Section 5.6. enumerated values described in [RFC7423] Section 5.6.
12.17. Tariff-Change-Usage AVP 12.17. Tariff-Change-Usage AVP
As defined in Section 8.27, the Tariff-Change-Usage AVP includes As defined in Section 8.27, the Tariff-Change-Usage AVP includes
Enumerated type values 0 - 2. IANA has created and is maintaining a Enumerated type values 0 - 2. IANA has created and is maintaining a
namespace for this AVP. All remaining values are available for namespace for this AVP. The definition of new values is subject to
assignment by a Designated Expert [RFC8126], under the conditions for the Specification Required policy [RFC8126] and conditions for
enumerated values described in [RFC7423] Section 5.6. enumerated values described in [RFC7423] Section 5.6.
12.18. User-Equipment-Info-Type AVP 12.18. User-Equipment-Info-Type AVP
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
Enumerated type values 0 - 3. IANA has created and is maintaining a Enumerated type values 0 - 3. IANA has created and is maintaining a
namespace for this AVP. All remaining values are available for namespace for this AVP. The definition of new values is subject to
assignment by a Designated Expert [RFC8126], under the conditions for the Specification Required policy [RFC8126] and conditions for
enumerated values described in [RFC7423] Section 5.6. enumerated values described in [RFC7423] Section 5.6.
13. Credit-Control Application Related Parameters 13. Credit-Control Application Related Parameters
Tx timer Tx timer
When real-time credit-control is required, the credit-control client When real-time credit-control is required, the credit-control client
contacts the credit-control server before and while the service is contacts the credit-control server before and while the service is
provided to an end user. Due to the real-time nature of the provided to an end user. Due to the real-time nature of the
application, the communication delays SHOULD be minimized; e.g., to application, the communication delays SHOULD be minimized; e.g., to
skipping to change at page 98, line 48 skipping to change at page 99, line 48
manual configuration. manual configuration.
Another kind of threat is malicious modification, injection, or Another kind of threat is malicious modification, injection, or
deletion of AVPs or complete credit-control messages. The credit- deletion of AVPs or complete credit-control messages. The credit-
control messages contain sensitive billing related information (such control messages contain sensitive billing related information (such
as subscription Id, granted units, used units, cost information) as subscription Id, granted units, used units, cost information)
whose malicious modification can have financial consequences. whose malicious modification can have financial consequences.
Sometimes simply delaying the credit-control messages can cause Sometimes simply delaying the credit-control messages can cause
disturbances in the credit-control client or server. disturbances in the credit-control client or server.
Even without any modification to the messages, an adversary can Even without any modification to the messages, an adversary that can
eavesdrop on transactions that contain privacy-sensitive information eavesdrop on transactions can obtain privacy-sensitive information.
about the user. Also, by monitoring the credit-control messages one Also, by monitoring the credit-control messages one can collect
can collect information about the credit-control server's billing information about the credit-control server's billing models and
models and business relationships. business relationships.
When third-party relays or proxy are involved, the hop-by-hop When third-party relays or proxy are involved, the hop-by-hop
security does not necessarily provide sufficient protection for security does not necessarily provide sufficient protection for
Diameter user session. In some cases, it may be inappropriate to Diameter user session. In some cases, it may be inappropriate to
send Diameter messages, such as CCR and CCA, containing sensitive send Diameter messages, such as CCR and CCA, containing sensitive
AVPs via untrusted Diameter proxy agents, as there are no assurances AVPs via untrusted Diameter proxy agents, as there are no assurances
that third-party proxies will not modify the credit-control commands that third-party proxies will not modify the credit-control commands
or AVP values. or AVP values.
14.1. Direct Connection with Redirects 14.1. Direct Connection with Redirects
A Diameter credit-control agent cannot always know whether agents A Diameter credit-control agent cannot always know whether agents
between it and the end user's Diameter credit-control server are between it and the end user's Diameter credit-control server are
reliable. In this case, the Diameter credit-control agent doesn't reliable. In this case, the Diameter credit-control agent doesn't
have a routing entry in its Diameter Routing Table (defined in have a routing entry in its Diameter Routing Table (defined in
[RFC6733], section 2.7) for the realm of the credit-control server in [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 the end user's home realm. The Diameter credit-control agent can
have a default route configured to a local Redirect agent, and it have a default route configured to a local Redirect agent, and it
redirects the CCR message to the redirect agent. The local Redirect redirects the CCR message to the redirect agent. The local Redirect
agent then returns a redirect notification (Result-code 3006, agent then returns a redirect notification (Result-code 3006,
DIAMETER_REDIRECT_INDICATION) to the credit-control agent, as well as DIAMETER_REDIRECT_INDICATION) to the credit-control agent, as well as
Diameter credit-control server(s) information (Redirect-Host AVP) and Diameter credit-control server(s) information (Redirect-Host AVP) and
information (Redirect-Host-Usage AVP) about how the routing entry information (Redirect-Host-Usage AVP) about how the routing entry
resulting from the Redirect-Host is to be used. The Diameter credit- resulting from the Redirect-Host is to be used. The Diameter credit-
control agent then forwards the CCR message directly to one of the control agent then forwards the CCR message directly to one of the
hosts identified by the CCA message from the redirect agent. If 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 value of the Redirect-Host-Usage AVP is unequal to zero, all
skipping to change at page 100, line 7 skipping to change at page 101, line 7
As the Diameter protocol, and especially credit-control application, As the Diameter protocol, and especially credit-control application,
deals with subscribers and their actions, extra care should be taken deals with subscribers and their actions, extra care should be taken
regarding the privacy of the subscribers. In terms of [RFC6973], regarding the privacy of the subscribers. In terms of [RFC6973],
both the credit-control client and credit-control server are both the credit-control client and credit-control server are
intermediary entities, wherein the subscribers' privacy may be intermediary entities, wherein the subscribers' privacy may be
compromised even if no security issues exist, and only authorized compromised even if no security issues exist, and only authorized
entities have access to the privacy-sensitive information. entities have access to the privacy-sensitive information.
15.1. Privacy Sensitive AVPs 15.1. Privacy Sensitive AVPs
The privacy-sensitive AVPs listed in this section MUST NOT be sent
across non-trusted networks or Diameter agents without end-to-end
authentication and confidentiality protection, as described in
[RFC6733] section 13.3.
The following AVPs contain privacy-sensitive information at different The following AVPs contain privacy-sensitive information at different
levels: levels:
1. CC-Correlation-Id AVP: may contain privacy-sensitive information 1. CC-Correlation-Id AVP: may contain privacy-sensitive information
as the service-provider may encode personal information that as the service-provider may encode personal information that
helps it correlate different subscriptions and access helps it correlate different subscriptions and access
technologies. technologies.
2. Check-Balance-Result AVP: contains information on the balance 2. Check-Balance-Result AVP: contains information on the balance
status of the subscriber. status of the subscriber.
skipping to change at page 100, line 33 skipping to change at page 101, line 38
5. Service-Identifier AVP: may contain privacy-sensitive 5. Service-Identifier AVP: may contain privacy-sensitive
information about the subscriber's internet activity. information about the subscriber's internet activity.
6. Rating-Group AVP: may contain privacy-sensitive information 6. Rating-Group AVP: may contain privacy-sensitive information
about the subscriber's internet activity. about the subscriber's internet activity.
7. Restriction-Filter-Rule AVP: the information inside IPFilterRule 7. Restriction-Filter-Rule AVP: the information inside IPFilterRule
may be used to infer services used by the subscriber. may be used to infer services used by the subscriber.
8. Redirect-Server-Address AVP: the service-provider may embed 8. Redirect-Server-Address AVP: the service-provider might embed
personal information on the subscriber in the URL/I (e.g. to personal information on the subscriber in the URL/I (e.g. to
create a personalized message). However, the service-provider create a personalized message). However, the service-provider
may anonymise the subscriber's identity instead in the URL/I, may anonymise the subscriber's identity instead in the URL/I,
and let the redirect server query the information directly. and let the redirect server query the information directly.
Similar AVPs are: Redirect-Address-URL, Redirect-Address-SIP- Such anonymized information must not allow personal information
URI. or the subscriber's identity to be easily guessed. Similar AVPs
are: Redirect-Address-URL, Redirect-Address-SIP-URI.
9. Service-Context-Id AVP: depending with how the service-provider 9. Service-Context-Id AVP: depending with how the service-provider
uses it, it may contain privacy-sensitive information about the uses it, it may contain privacy-sensitive information about the
service (e.g. in a 3GPP network Service-Context-Id AVP has a service (e.g. in a 3GPP network Service-Context-Id AVP has a
different value for: Packet Switching, SMS and MMS etc.) different value for: Packet Switching, SMS and MMS etc.)
10. Service-Parameter-Info AVP: depending with how the service- 10. Service-Parameter-Info AVP: depending with how the service-
provider uses it, it may contain privacy-sensitive information provider uses it, it may contain privacy-sensitive information
about the subscriber (e.g. location). about the subscriber (e.g. location).
skipping to change at page 104, line 39 skipping to change at page 105, line 39
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
DOI 10.17487/RFC7542, May 2015, DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/info/rfc7542>. <https://www.rfc-editor.org/info/rfc7542>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[TGPPIMEI] [TGPPIMEI]
3rd Generation Partnership Project, "Technical 3rd Generation Partnership Project, "Technical
Specification Group Core Network, Numbering, addressing Specification Group Core Network, Numbering, addressing
and identification, (release 13), 3GPP TS 23.003 v. and identification, (release 13), 3GPP TS 23.003 v.
13.5.0", 2016-04. 13.5.0", 2016-04.
16.2. Informative References 16.2. Informative References
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
DOI 10.17487/RFC2866, June 2000, DOI 10.17487/RFC2866, June 2000,
skipping to change at page 107, line 40 skipping to change at page 109, line 35
access to the end user (6). At the expiry of the allocated quota, 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 the NAS sends a Diameter Credit-Control-Request with CC-Request-Type
set to UPDATE_REQUEST to the Home Diameter AAA server (7). This set to UPDATE_REQUEST to the Home Diameter AAA server (7). This
message contains the units used thus far. The home Diameter AAA message contains the units used thus far. The home Diameter AAA
server forwards the CCR to the Diameter credit-control server (8). server forwards the CCR to the Diameter credit-control server (8).
The Diameter credit-control server debits the used units from the end 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 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 Diameter AAA server in the Diameter Credit-Control-Answer (9). The
message is forwarded to the NAS (10). During the ongoing credit- message is forwarded to the NAS (10). During the ongoing credit-
control session, the authorization lifetime expires, and the control session, the authorization lifetime expires, and the
authorization/authentication client in the NAS performs service authorization/authentication client in the NAS performs service-
specific re-authorization to the home Diameter AAA server, as usual. specific re-authorization to the home Diameter AAA server, as usual.
The credit-control client populates the AAR with the Credit-Control The credit-control client populates the AAR with the Credit-Control
AVP set to RE_AUTHORIZATION, indicating that the credit-control AVP set to RE_AUTHORIZATION, indicating that the credit-control
server shall not be contacted, as the credit authorization is server shall not be contacted, as the credit authorization is
controlled by the burning rate of the granted units (11). The home controlled by the burning rate of the granted units (11). The home
Diameter AAA server performs service-specific re-authorization as Diameter AAA server performs service-specific re-authorization as
usual and returns the AA-Answer to the NAS (12). The end user logs 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 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 user's account and to stop the credit-control session, the NAS sends
a Diameter Credit-Control-Request with CC-Request-Type set to a Diameter Credit-Control-Request with CC-Request-Type set to
skipping to change at page 108, line 25 skipping to change at page 110, line 20
|------------->|(ii) | | | |------------->|(ii) | | |
| |------------->| | | | |------------->| | |
| |authentication & | | | |authentication & | |
| |authorization | | | | |authorization | | |
| |<-------------| | | | |<-------------| | |
|(iii)200 OK | | | |(iii)200 OK | | |
|<-------------| | | |<-------------| | |
: : : : : : : :
|(1) INVITE | : |(1) INVITE | :
|------------->| |------------->|
| |(2) CCR (Initial, SIP specific AVP) | | |(2) CCR (Initial, SIP-specific AVP) |
| |------------------------------------------->| | |------------------------------------------->|
| |(3) CCA (Granted-Units) | | |(3) CCA (Granted-Units) |
| |<-------------------------------------------| | |<-------------------------------------------|
| |(4) INVITE | | | |(4) INVITE | |
| |---------------------------->| | | |---------------------------->| |
: : : : : : : :
| |(5) CCR (update, Used-Units) | | |(5) CCR (update, Used-Units) |
| |------------------------------------------->| | |------------------------------------------->|
| |(6) CCA (Granted-Units) | | |(6) CCA (Granted-Units) |
| |<-------------------------------------------| | |<-------------------------------------------|
skipping to change at page 110, line 14 skipping to change at page 112, line 12
termination by sending a Diameter Credit-Control-Answer to the SIP termination by sending a Diameter Credit-Control-Answer to the SIP
Proxy (10). Proxy (10).
B.3. Flow III B.3. Flow III
MMS Server MMS Server
A (CC Client) B CC Server A (CC Client) B CC Server
|(1) Send MMS | | | |(1) Send MMS | | |
|--------------->| | | |--------------->| | |
| |(2) CCR (event, DIRECT_DEBITING,| | |(2) CCR (event, DIRECT_DEBITING,|
| | MMS specific AVP) | | | MMS-specific AVP) |
| |-------------------------------->| | |-------------------------------->|
| |(3) CCA (Granted-Units) | | |(3) CCA (Granted-Units) |
| |<--------------------------------| | |<--------------------------------|
|(4) Send MMS Ack| | | |(4) Send MMS Ack| | |
|<---------------| | | |<---------------| | |
| |(5) Notify MMS | | | |(5) Notify MMS | |
| |--------------->| | | |--------------->| |
: : : : : : : :
| |(6) Retrieve MMS| | | |(6) Retrieve MMS| |
| |<---------------| | | |<---------------| |
| |(7) Retrieve MMS| | | |(7) Retrieve MMS| |
| | Ack | | | | Ack | |
| |--------------->| | | |--------------->| |
| | | | | | | |
Figure 13: Flow III Figure 13: Flow III
This is an example of Diameter credit-control for direct debiting
using the Multimedia Messaging Service environment. Although the
flow focuses on illustrating the usage of credit-control messages,
the MMS signaling is inaccurate, and the diagram is not by any means
an attempt to define any service provider's MMS configuration or
billing model.
A credit-control flow for Multimedia Messaging Services is shown in A credit-control flow for Multimedia Messaging Services is shown in
Figure 13. The sender is charged as soon as the messaging server Figure 13. The sender is charged as soon as the messaging server
successfully stores the message. successfully stores the message.
The end user A sends a Multimedia Message (MMS) to the MMS server The end user A sends a Multimedia Message (MMS) to the MMS server
(1). The MMS server stores the message and sends a Diameter Credit- (1). The MMS server stores the message and sends a Diameter Credit-
Control-Request (EVENT_REQUEST with Requested-Action DIRECT_DEBITING) Control-Request (EVENT_REQUEST with Requested-Action DIRECT_DEBITING)
to the Diameter credit-control server (2). The Credit-Control- to the Diameter credit-control server (2). The Credit-Control-
Request contains information about the MMS message (e.g., size, Request contains information about the MMS message (e.g., size,
recipient address, image coding type). The Diameter credit-control recipient address, image coding type). The Diameter credit-control
server checks the end user's account balance, rates the service, and server checks the end user's account balance, rates the service, and
debits the service from the end user's account. The granted quota is debits the service from the end user's account. The granted quota is
returned to the MMS server in the Diameter Credit-Control-Answer (3). returned to the MMS server in the Diameter Credit-Control-Answer (3).
The MMS server acknowledges the successful reception of the MMS The MMS server acknowledges the successful reception of the MMS
message (4). The MMS Server notifies the recipient about the new MMS message (4). The MMS Server notifies the recipient about the new MMS
(5), and end user B retrieves the message from the MMS message store (5), and end user B retrieves the message from the MMS message store
(6),(7). (6),(7).
Note that the transfer of the MMS message can take an extended time
and can fail, in which case a recovery action is needed. The MMS
server should return the already debited units to the user's account
by using the REFUND action described in Section 6.4.
B.4. Flow IV B.4. Flow IV
MMS Server MMS Server
Content Server (CC Client) B CC Server Content Server (CC Client) B CC Server
|(1) Send MMS | | | |(1) Send MMS | | |
|--------------->| | | |--------------->| | |
| |(2) CCR (event, CHECK_BALANCE, | | |(2) CCR (event, CHECK_BALANCE, |
| | MMS specific AVP) | | | MMS-specific AVP) |
| |-------------------------------->| | |-------------------------------->|
| |(3) CCA (ENOUGH_CREDIT) | | |(3) CCA (ENOUGH_CREDIT) |
| |<--------------------------------| | |<--------------------------------|
|(4) Send MMS Ack| | | |(4) Send MMS Ack| | |
|<---------------| | | |<---------------| | |
| |(5) Notify MMS | | | |(5) Notify MMS | |
| |--------------->| | | |--------------->| |
: : : : : : : :
| |(6) Retrieve MMS| | | |(6) Retrieve MMS| |
| |<---------------| | | |<---------------| |
| |(7) CCR (event, DIRECT_DEBITING,| | |(7) CCR (event, DIRECT_DEBITING,|
| | MMS specific AVP) | | | MMS-specific AVP) |
| |-------------------------------->| | |-------------------------------->|
| |(8) CCA (Granted-Units) | | |(8) CCA (Granted-Units) |
| |<--------------------------------| | |<--------------------------------|
| |(9) Retrieve MMS| | | |(9) Retrieve MMS| |
| | Ack | | | | Ack | |
| |--------------->| | | |--------------->| |
| | | | | | | |
Figure 14: Flow IV Figure 14: Flow IV
skipping to change at page 112, line 27 skipping to change at page 115, line 4
service, and debits the service from the end user's account. The service, and debits the service from the end user's account. The
granted quota is returned to the MMS server in the Diameter Credit- granted quota is returned to the MMS server in the Diameter Credit-
Control-Request (8). The MMS is transferred to end user B (9). Control-Request (8). The MMS is transferred to end user B (9).
Note that the transfer of the MMS message can take an extended time Note that the transfer of the MMS message can take an extended time
and can fail, in which case a recovery action is needed. The MMS and can fail, in which case a recovery action is needed. The MMS
server should return the already debited units to the user's account server should return the already debited units to the user's account
by using the REFUND action described in Section 6.4. by using the REFUND action described in Section 6.4.
B.5. Flow V B.5. Flow V
SIP Controller SIP Controller
A (CC Client) B CC Server A (CC Client) B CC Server
|(1)INVITE B(SDP)| | | |(1)INVITE B(SDP)| | |
|--------------->| | | |--------------->| | |
| |(2) CCR (event, PRICE_ENQUIRY, | | |(2) CCR (event, PRICE_ENQUIRY, |
| | SIP specific AVPs) | | | SIP-specific AVPs) |
| |-------------------------------->| | |-------------------------------->|
| |(3) CCA (Cost-Information) | | |(3) CCA (Cost-Information) |
| |<--------------------------------| | |<--------------------------------|
| (4)MESSAGE(URL)| | | | (4)MESSAGE(URL)| | |
|<---------------| | | |<---------------| | |
|(5)HTTP GET | | | |(5)HTTP GET | | |
|--------------->| | | |--------------->| | |
|(6)HTTP POST | | | |(6)HTTP POST | | |
|--------------->|(7)INVITE(SDP) | | |--------------->|(7)INVITE(SDP) | |
| |--------------->| | | |--------------->| |
skipping to change at page 113, line 22 skipping to change at page 115, line 46
the SDP, and a button to accept/not accept the charges. (There may the SDP, and a button to accept/not accept the charges. (There may
be many other ways to deliver AoC information; however, this flow be many other ways to deliver AoC information; however, this flow
focuses on the use of the credit-control messages.) The user has focuses on the use of the credit-control messages.) The user has
been authenticated and authorized prior to initiating the call and been authenticated and authorized prior to initiating the call and
subscribed to AoC service. subscribed to AoC service.
UA A sends an INVITE with SDP to B (1). The SIP controller UA A sends an INVITE with SDP to B (1). The SIP controller
determines that the user is subscribed to AoC service and sends a determines that the user is subscribed to AoC service and sends a
Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action: Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action:
PRICE_ENQUIRY) to the Diameter credit-control server (2). The PRICE_ENQUIRY) to the Diameter credit-control server (2). The
Credit-Control-Request contains SIP specific AVPs derived from the Credit-Control-Request contains SIP-specific AVPs derived from the
SIP signaling, describing the requested service (e.g., calling party, SIP signaling, describing the requested service (e.g., calling party,
called party, Session Description Protocol attributes). The Diameter called party, Session Description Protocol attributes). The Diameter
credit-control server determines the cost of the service and returns credit-control server determines the cost of the service and returns
the Credit-Control-Answer including the Cost-Information AVP (3). the Credit-Control-Answer including the Cost-Information AVP (3).
The SIP controller manufactures the AoC web page with information The SIP controller manufactures the AoC web page with information
received in SIP signaling and with the cost information received from received in SIP signaling and with the cost information received from
the credit-control server. Then it sends a SIP MESSAGE that contains the credit-control server. Then it sends a SIP MESSAGE that contains
a URL pointing to the AoC information web page (4). At the receipt a URL pointing to the AoC information web page (4). At the receipt
of the SIP MESSAGE, A's UA automatically invokes the web browser that of the SIP MESSAGE, A's UA automatically invokes the web browser that
retrieves the AoC information (5). The user clicks on a proper retrieves the AoC information (5). The user clicks on a proper
skipping to change at page 117, line 44 skipping to change at page 119, line 44
Figure 18 is an example of the graceful service termination initiated Figure 18 is an example of the graceful service termination initiated
when the first interrogation takes place because the user's account when the first interrogation takes place because the user's account
is empty. In this example, the credit-control server supports the is empty. In this example, the credit-control server supports the
server-initiated credit re-authorization. The Diameter [RFC7155] is server-initiated credit re-authorization. The Diameter [RFC7155] is
implemented in the Network Access Server (NAS). implemented in the Network Access Server (NAS).
The user logs on to the network (1). The Diameter NAS sends a The user logs on to the network (1). The Diameter NAS sends a
Diameter AA-Request to the home Diameter AAA server. The credit- Diameter AA-Request to the home Diameter AAA server. The credit-
control client populates the AAR with the Credit-Control AVP set to control client populates the AAR with the Credit-Control AVP set to
CREDIT_AUTHORIZATION, and service specific AVPs are included, as CREDIT_AUTHORIZATION, and service-specific AVPs are included, as
usual [RFC7155]. The home Diameter AAA server performs service usual [RFC7155]. The home Diameter AAA server performs service-
specific Authentication and Authorization, as usual. The home specific Authentication and Authorization, as usual. The home
Diameter AAA server determines that the user has a prepaid Diameter AAA server determines that the user has a prepaid
subscription and notices from the Credit-Control AVP that the NAS has subscription and notices from the Credit-Control AVP that the NAS has
credit-control capabilities. It sends a Diameter Credit-Control- credit-control capabilities. It sends a Diameter Credit-Control-
Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter
credit-control server to perform credit authorization (3) and to credit-control server to perform credit authorization (3) and to
establish a credit-control session. (The home Diameter AAA server establish a credit-control session. (The home Diameter AAA server
may forward service specific AVPs received from the NAS as input for may forward service-specific AVPs received from the NAS as input for
the rating process.) The Diameter credit-control server checks the the rating process.) The Diameter credit-control server checks the
end user's account balance, determines that the account cannot cover end user's account balance, determines that the account cannot cover
the cost of the service, and initiates the graceful service the cost of the service, and initiates the graceful service
termination. The Credit-Control-Answer is returned to the home termination. The Credit-Control-Answer is returned to the home
Diameter AAA server (4). This message contains the Final-Unit- Diameter AAA server (4). This message contains the Final-Unit-
Indication AVP and the Validity-Time AVP set to a reasonable amount Indication AVP and the Validity-Time AVP set to a reasonable amount
of time to give the user a chance to replenish his/her account (e.g., of time to give the user a chance to replenish his/her account (e.g.,
10 minutes). The Final-Unit-Indication AVP includes the Final-Unit- 10 minutes). The Final-Unit-Indication AVP includes the Final-Unit-
Action set to REDIRECT, the Redirect-Address-Type set to URL, and the Action set to REDIRECT, the Redirect-Address-Type set to URL, and the
Redirect-Server-Address set to the HTTP Top-up server name. The home Redirect-Server-Address set to the HTTP Top-up server name. The home
skipping to change at page 119, line 17 skipping to change at page 121, line 17
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
that Service-Identifiers, Rating-Groups, and their associated that Service-Identifiers, Rating-Groups, and their associated
parameters (e.g., IP 5-tuple) are locally configured in the service parameters (e.g., IP 5-tuple) are locally configured in the service
element or provisioned by an entity other than the credit-control element or provisioned by an entity other than the credit-control
server. server.
End User Service Element CC Server End User Service Element CC Server
(CC client) (CC client)
|(1)User logon | | |(1)User logon | |
|------------------>|(2)CCR(initial, Service-Id access, | |------------------>|(2)CCR(initial, Service-Id access, |
| | Access specific AVPs, | | | Access-specific AVPs, |
| | Multiple-Service-Indicator) | | | Multiple-Service-Indicator) |
| |---------------------------------------->| | |---------------------------------------->|
| |(3)CCA(Multiple-Services-CC ( | | |(3)CCA(Multiple-Services-CC ( |
| | Granted-Units(Total-Octets), | | | Granted-Units(Total-Octets), |
| | Service-Id access, | | | Service-Id access, |
| | Validity-time, | | | Validity-time, |
| | G-S-U-Pool-Reference(Pool-Id 1, | | | G-S-U-Pool-Reference(Pool-Id 1, |
| | Multiplier 10))) | | | Multiplier 10))) |
| |<----------------------------------------| | |<----------------------------------------|
: : : : : :
skipping to change at page 121, line 30 skipping to change at page 123, line 30
The user logs on to the network (1). The service element sends a The user logs on to the network (1). The service element sends a
Diameter Credit-Control-Request with CC-Request-Type set to Diameter Credit-Control-Request with CC-Request-Type set to
INITIAL_REQUEST to the Diameter credit-control server to perform INITIAL_REQUEST to the Diameter credit-control server to perform
credit authorization for the bearer service (e.g., Internet access credit authorization for the bearer service (e.g., Internet access
service) and to establish a credit-control session (2). In this service) and to establish a credit-control session (2). In this
message, the credit-control client indicates support for independent message, the credit-control client indicates support for independent
credit-control of multiple services within the session by including credit-control of multiple services within the session by including
the Multiple-Service-Indicator AVP. The Diameter credit-control the Multiple-Service-Indicator AVP. The Diameter credit-control
server checks the end user's account balance, with rating information server checks the end user's account balance, with rating information
received from the client (i.e., Service-Id and access specific AVPs), received from the client (i.e., Service-Id and access-specific AVPs),
rates the request, and reserves credit from the end user's account. rates the request, and reserves credit from the end user's account.
Suppose that the server reserves $5 and determines that the cost is Suppose that the server reserves $5 and determines that the cost is
$1/MB. It then returns to the service element a Credit-Control- $1/MB. It then returns to the service element a Credit-Control-
Answer message that includes the Multiple-Services-Credit-Control AVP Answer message that includes the Multiple-Services-Credit-Control AVP
with a quota of 5MB associated to the Service-Id (access), to a with a quota of 5MB associated to the Service-Id (access), to a
multiplier value of 10, and to the Pool-Id 1 (3). multiplier value of 10, and to the Pool-Id 1 (3).
The user uses Service 1 (4). The service element sends a Diameter The user uses Service 1 (4). The service element sends a Diameter
Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to
the credit-control server to perform credit authorization for service the credit-control server to perform credit authorization for service
skipping to change at page 124, line 24 skipping to change at page 126, line 24
Clarify that IPv6 representation in Redirect-Address-Type AVP Clarify that IPv6 representation in Redirect-Address-Type AVP
conforms to RFC5952 (Section 8.38). conforms to RFC5952 (Section 8.38).
Describe immediate graceful service termination procedure (in Describe immediate graceful service termination procedure (in
Section 5.6). Section 5.6).
Add extensible User-Equipment-Info-Extension AVP and included Add extensible User-Equipment-Info-Extension AVP and included
types (from Section 8.52 to Section 8.57). types (from Section 8.52 to Section 8.57).
Define binary MAC formatting in User-Equipment-Info-MAC instead of
the textual formatting in User-Equipment-Info-Data when type is
MAC.
Add extensible Subscription-Id-Extension AVP and included types Add extensible Subscription-Id-Extension AVP and included types
(from Section 8.58 to Section 8.63). (from Section 8.58 to Section 8.63).
Add extensible Redirect-Server-Extension AVP and included types Add extensible Redirect-Server-Extension AVP and included types
(from Section 8.64 to Section 8.67). (from Section 8.64 to Section 8.67).
Add extensible QoS-Final-Unit-Indication AVP (in Section 8.68). Add extensible QoS-Final-Unit-Indication AVP (in Section 8.68).
Updated Security Section to include language consistent with Updated Security Section to include language consistent with
structures of latest base protocol specification. structures of latest base protocol specification.
Update references to obsolete RFC 5226 to refer to RFC 8126, and Update references to obsolete RFC 5226 to refer to RFC 8126, and
resulting updates to Section 12. resulting updates to Section 12.
Add section on Privacy Considerations. Add section on Privacy Considerations.
Authors' Addresses Language updated from RFC 2119 updated to RFC 8174.
Authors' Addresses
Lyle Bertz (editor) Lyle Bertz (editor)
Sprint Sprint
6220 Sprint Parkway 6220 Sprint Parkway
Overland Park, KS 66251 Overland Park, KS 66251
United States United States
Email: lyleb551144@gmail.com Email: lyleb551144@gmail.com
David Dolson (editor) David Dolson (editor)
Sandvine Sandvine
408 Albert Street 408 Albert Street
Waterloo, ON N2L 3V3 Waterloo, ON N2L 3V3
Canada Canada
Email: ddolson@acm.org Email: ddolson@acm.org
Yuval Lifshitz (editor) Yuval Lifshitz (editor)
Sandvine Sandvine
 End of changes. 153 change blocks. 
358 lines changed or deleted 396 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/