-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-bertz-dime-rfc4006bis.xml
executable file
·6110 lines (5984 loc) · 299 KB
/
draft-bertz-dime-rfc4006bis.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC791 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0791.xml">
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC7542 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7542.xml">
<!ENTITY RFC2866 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2866.xml">
<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC5952 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5952.xml">
<!ENTITY RFC3539 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3539.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC3580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3580.xml">
<!ENTITY RFC3725 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3725.xml">
<!ENTITY RFC6733 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6733.xml">
<!ENTITY RFC4004 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4004.xml'>
<!ENTITY RFC4072 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4072.xml'>
<!ENTITY RFC7155 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7155.xml'>
<!ENTITY RFC4006 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4006.xml">
<!ENTITY RFC5777 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5777.xml">
<!ENTITY RFC7423 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7423.xml">
<!ENTITY RFC6973 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6973.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ietf-dime-rfc4006bis-12" ipr="pre5378Trust200902" obsoletes="4006">
<front>
<title>Diameter Credit-Control Application</title>
<author fullname="Lyle Bertz" initials="L." surname="Bertz" role="editor">
<organization>Sprint</organization>
<address>
<postal>
<street>6220 Sprint Parkway</street>
<city>Overland Park</city>
<region>KS</region>
<code>66251</code>
<country>United States</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="David Dolson" initials="D." surname="Dolson" role="editor">
<organization>Sandvine</organization>
<address>
<postal>
<street>408 Albert Street</street>
<city>Waterloo</city>
<region>ON</region>
<code>N2L 3V3</code>
<country>Canada</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Yuval Lifshitz" initials="Y." surname="Lifshitz" role="editor">
<organization>Sandvine</organization>
<address>
<postal>
<street>408 Albert Street</street>
<city>Waterloo</city>
<region>ON</region>
<code>N2L 3V3</code>
<country>Canada</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date year="2018"/>
<area>General</area>
<workgroup>Network Working Group</workgroup>
<keyword>diameter</keyword>
<keyword>charging</keyword>
<abstract>
<t>This document specifies a Diameter application that can be used to
implement real-time credit-control for a variety of end user services
such as network access, Session Initiation Protocol (SIP) services,
messaging services, and download services. The Diameter Credit-Control application
as defined in this document obsoletes RFC4006, and it must be supported by all new
Diameter Credit-Control Application implementations.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>
This document specifies a Diameter application that can be used to
implement real-time credit-control for a variety of end user services
such as network access, Session Initiation Protocol (SIP) services,
messaging services, and download services. It provides a general
solution to real-time cost and credit-control.
</t>
<t>
The prepaid model has been shown to be very successful, for instance,
in GSM networks, where network operators offering prepaid services
have experienced a substantial growth of their customer base and
revenues. Prepaid services are now cropping up in many other
wireless and wire line based networks.
</t>
<t>
In mobile networks, additional functionality is
required beyond that specified in the Diameter base protocol <xref target="RFC6733"/>. For
example, the 3GPP Charging and Billing requirements <xref target="TGPPCHARG"/> state
that an application must be able to rate service information in
real-time. In addition, it is necessary to check that the end user's
account provides coverage for the requested service prior to
initiation of that service. When an account is exhausted or expired,
the user must be denied the ability to compile additional chargeable
events.
</t><t>
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
are services such as gaming and advertising that may credit as well
as debit a user account.
</t><t>
The other Diameter applications provide service-specific
authorization, and they do not provide credit authorization for
prepaid users. The credit authorization shall be generic and
applicable to all the service environments required to support
prepaid services.
</t><t>
To fulfill these requirements, it is necessary to facilitate
credit-control communication between the network element providing the
service (e.g., Network Access Server, SIP Proxy, and Application
Server) and a credit-control server.
</t><t>
The scope of this specification is the credit authorization.
Service-specific authorization and authentication is out of scope.
</t>
<section title="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.
</t>
</section>
<section anchor="terms" title="Terminology">
<t>
<list style="hanging">
<t hangText="AAA">
Authentication, Authorization, and Accounting
</t>
<t hangText="AA answer">
AA answer generically refers to a service-specific authorization and
authentication answer. AA answer commands are defined in service-specific
authorization applications, e.g., <xref target="RFC7155"/> and <xref target="RFC4004"/>.
</t>
<t hangText="AA request">
AA request generically refers to a service-specific authorization and
authentication request. AA request commands are defined in service-specific
authorization applications e.g., <xref target="RFC7155"/> and <xref target="RFC4004"/>.
</t>
<t hangText="Credit-control">
Credit-control is a mechanism that directly interacts in real-time
with an account and controls or monitors the charges related to the
service usage. Credit-control is a process of checking whether
credit is available, credit-reservation, deduction of credit from the
end user account when service is completed and refunding of reserved
credit that is not used.
</t>
<t hangText="Diameter Credit-control Server">
A Diameter credit-control server acts as a prepaid server, performing
real-time rating and credit-control. It is located in the home
domain and is accessed by service elements or Diameter AAA servers in
real-time for purpose of price determination and credit-control
before the service event is delivered to the end-user. It may also
interact with business support systems.
</t>
<t hangText="Diameter Credit-control Client">
A Diameter credit-control client is an entity that interacts with a
credit-control server. It monitors the usage of the granted quota
according to instructions returned by credit-control server.
</t>
<t hangText="Interrogation">
The Diameter credit-control client uses interrogation to initiate a
session based credit-control process. During the credit-control
process, it is used to report the used quota and request a new one.
An interrogation maps to a request/answer transaction.
</t>
<t hangText="One-time event">
Basically, a request/answer transaction of type event.
</t>
<t hangText="Rating">
The act of determining the cost of the service event.
</t>
<t hangText="Service">
A type of task performed by a service element for an end user.
</t>
<t hangText="Service Element">
A network element that provides a service to the end users. The
Service Element may include the Diameter credit-control client, or
another entity (e.g., RADIUS AAA server) that can act as a
credit-control client on behalf of the Service Element. In the latter case,
the interface between the Service Element and the Diameter credit-control
client is outside the scope of this specification. Examples
of the Service Elements include Network Access Server (NAS), SIP
Proxy, and Application Servers such as messaging server, content
server, and gaming server.
</t>
<t hangText="Service Event">
An event relating to a service provided to the end user.
</t>
<t hangText="Session based credit-control">
A credit-control process that makes use of several interrogations:
the first, a possible intermediate, and the final. The first
interrogation is used to reserve money from the user's account and to
initiate the process. The intermediate interrogations may be needed
to request new quota while the service is being rendered. The final
interrogation is used to exit the process. The credit-control server
is required to maintain session state for session-based credit-control.
</t>
</list>
</t>
</section>
<section anchor="sec-1.3" title="Advertising Application Support">
<t>
Diameter nodes conforming to this specification MUST advertise
support by including the value of 4 in the Auth-Application-Id of the
Capabilities-Exchange-Request and Capabilities-Exchange-Answer
command <xref target="RFC6733"/>.
</t>
</section>
</section>
<section anchor="sec-2" title="Architecture Models">
<t>
The current accounting models specified in the Radius Accounting
<xref target="RFC2866"/> and Diameter base <xref target="RFC6733"/> are not sufficient for
real-time credit-control, where credit-worthiness is to be determined
prior to service initiation. Also, the existing Diameter
authorization applications, <xref target="RFC7155"/> and <xref target="RFC4004"/>, only provide
service authorization, but do not provide credit authorization for
prepaid users. In order to support real-time credit-control, a new
type of server is needed in the AAA infrastructure: Diameter credit-control
server. The Diameter credit-control server is the entity
responsible for credit authorization for prepaid subscribers.
</t>
<t>
A service element may authenticate and authorize the end user with
the AAA server by using AAA protocols; e.g., RADIUS or a Diameter
base protocol with a possible Diameter application.
</t>
<t>
Accounting protocols such as RADIUS accounting and the Diameter base
accounting protocol can be used to provide accounting data to the
accounting server after service is initiated, and to provide possible
interim reports until service completion. However, for real-time
credit-control, these authorization and accounting models are not
sufficient.
</t>
<t>
When real-time credit-control is required, the credit-control client
contacts the credit-control server with information about a possible
service event. The credit-control process is performed to determine
potential charges and to verify whether the end user's account
balance is sufficient to cover the cost of the service being
rendered.
</t>
<t>
<xref target="fig-typical-cca"/> illustrates the typical credit-control architecture, which
consists of a Service Element with an embedded Diameter credit-control
client, a Diameter credit-control server, and an AAA server.
A Business Support System is usually deployed; it includes at least
the billing functionality. The credit-control server and AAA server
in this architecture model are logical entities. The real
configuration can combine them into a single host. The credit-control
protocol is the Diameter base protocol <xref target="RFC6733"/> with the Diameter
credit-control application.
</t>
<t>
When an end user requests services such as SIP or messaging, the
request is typically forwarded to a service element (e.g., SIP Proxy)
in the user's home realm as defined in <xref target="RFC6733"/>. In some cases it might be possible that
the service element in the local realm <xref target="RFC6733"/> can offer services to the
end user; however, a commercial agreement must exist between the
local realm and the home realm. Network access is an example of
a service offered in the local realm where the NAS, through an AAA
infrastructure, authenticates and authorizes the user with the user's
home network.
</t>
<figure title="Typical credit-control architecture" anchor="fig-typical-cca">
<artwork><![CDATA[
Service Element AAA and CC
+----------+ +---------+ Protocols+-----------+ +--------+
| End |<---->|+-------+|<------------>| AAA | |Business|
| User | +->|| CC || | Server |->|Support |
| | | || Client||<-----+ | | |System |
+----------+ | |+-------+| | +-----------+ | |
| +---------+ | ^ +--------+
+----------+ | | CC Protocol | ^
| End |<--+ | +-----v----+ |
| User | +------>|Credit- | |
+----------+ Credit-Control |Control |--------+
Protocol |Server |
+----------+
]]>
</artwork>
</figure>
<t>
There can be multiple credit-control servers in the system for
redundancy and load balancing. The system can also contain separate
rating server(s), and accounts can be located in a centralized
database. To ensure that the end user's account is not debited or
credited multiple times for the same service event, only one place in
the credit-control system should perform duplicate detection. System
internal interfaces can exist to relay messages between servers and
an account manager. However, the detailed architecture of the
credit-control system and its interfaces are implementation specific
and are out of scope of this specification.
</t>
<t>
Protocol transparent Diameter relays can exist between the credit-control
client and credit-control server. Also, Diameter Redirect
agents that refer credit-control clients to credit-control servers
and allow them to communicate directly can exist. These agents
transparently support the Diameter credit-control application. The
different roles of Diameter Agents are defined in Diameter base
<xref target="RFC6733"/>, section 2.8.
</t>
<t>
If Diameter credit-control proxies exist between the credit-control
client and the credit-control server, they MUST advertise the
Diameter credit-control application support.
</t>
</section>
<section anchor="sec-3" title="Credit-Control Messages">
<t>
This section defines new Diameter message Command-Code values that
MUST be supported by all Diameter implementations that conform to
this specification. The Command Codes are as follows:
</t>
<texttable anchor="table_command_codes" title="Credit-Control Commands">
<ttcol align="left">Command-Name</ttcol>
<ttcol align="left">Abbrev.</ttcol>
<ttcol align="left">Code</ttcol>
<ttcol align="left">Reference</ttcol>
<c>Credit-Control-Request</c><c>CCR</c><c>272</c><c>3.1</c>
<c>Credit-Control-Answer</c><c>CCA</c><c>272</c><c>3.2</c>
</texttable>
<t>
Diameter Base <xref target="RFC6733"/> defines in the section 3.2 the Command Code
format specification. These formats are observed in Credit-Control
messages.
</t>
<section anchor="sec-3.1" title="Credit-Control-Request (CCR) Command">
<t>
The Credit-Control-Request message (CCR) is indicated by the
command-code field being set to 272 and the 'R' bit being set in the
Command Flags field. It is used between the Diameter credit-control
client and the credit-control server to request credit authorization
for a given service.
</t>
<t>
The Auth-Application-Id MUST be set to the value 4, indicating the
Diameter credit-control application.
</t>
<t>The CCR is extensible via the inclusion of one or more Attribute
Value Pairs (AVPs).</t>
<t>
Message Format
</t>
<figure><artwork><![CDATA[
<Credit-Control-Request> ::= < Diameter Header: 272, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
{ Service-Context-Id }
{ CC-Request-Type }
{ CC-Request-Number }
[ Destination-Host ]
[ User-Name ]
[ CC-Sub-Session-Id ]
[ Acct-Multi-Session-Id ]
[ Origin-State-Id ]
[ Event-Timestamp ]
*[ Subscription-Id ]
*[ Subscription-Id-Extension ]
[ Service-Identifier ]
[ Termination-Cause ]
[ Requested-Service-Unit ]
[ Requested-Action ]
*[ Used-Service-Unit ]
[ Multiple-Services-Indicator ]
*[ Multiple-Services-Credit-Control ]
*[ Service-Parameter-Info ]
[ CC-Correlation-Id ]
[ User-Equipment-Info ]
[ User-Equipment-Info-Extension ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]
]]>
</artwork>
</figure>
</section>
<section anchor="sec-3.2" title="Credit-Control-Answer (CCA) Command">
<t>
The Credit-Control-Answer message (CCA) is indicated by the command-code
field being set to 272 and the 'R' bit being cleared in the
Command Flags field. It is used between the credit-control server
and the Diameter credit-control client to acknowledge a Credit-Control-Request
command.
</t>
<t>
Message Format
</t>
<figure>
<artwork><![CDATA[
<Credit-Control-Answer> ::= < Diameter Header: 272, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Auth-Application-Id }
{ CC-Request-Type }
{ CC-Request-Number }
[ User-Name ]
[ CC-Session-Failover ]
[ CC-Sub-Session-Id ]
[ Acct-Multi-Session-Id ]
[ Origin-State-Id ]
[ Event-Timestamp ]
[ Granted-Service-Unit ]
*[ Multiple-Services-Credit-Control ]
[ Cost-Information]
[ Final-Unit-Indication ]
[ QoS-Final-Unit-Indication ]
[ Check-Balance-Result ]
[ Credit-Control-Failure-Handling ]
[ Direct-Debiting-Failure-Handling ]
[ Validity-Time ]
*[ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ Failed-AVP ]
*[ AVP ]
]]>
</artwork>
</figure>
</section>
</section>
<section anchor="sec-4" title="Credit-Control Application Overview">
<t>
The credit authorization process takes place before and during
service delivery to the end user and generally requires the user's
authentication and authorization before any request is sent to the
credit-control server. The credit-control application defined in
this specification supports two different credit authorization
models: credit authorization with money reservation and credit
authorization with direct debiting. In both models, the credit-control
client requests credit authorization from the credit-control
server prior to allowing any service to be delivered to the end user.
</t>
<t>
In the first model, the credit-control server rates the request,
reserves a suitable amount of money from the user's account, and
returns the amount of credit reserved. Note that
credit resources may not imply actual monetary credit; credit
resources may be granted to the credit-control client in the form of
units (e.g., data volume or time) to be metered.
</t>
<t>
Upon receipt of a successful credit authorization answer with a
certain amount of credit resources, the credit-control client allows
service delivery to the end user and starts monitoring the usage of
the granted resources. When the credit resources granted to the user
have been consumed or the service has been successfully delivered or
terminated, the credit-control client reports back to the server the
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
reservation if the service delivery is continuing. This process is
accomplished with session based credit-control that includes the
first interrogation, possible intermediate interrogations, and the
final interrogation. For session based credit-control, both the
credit-control client and the credit-control server are required to
maintain credit-control session state. Session based credit-control
is described in more detail, with more variations, in <xref target="sec-5"/>.
</t>
<t>
In contrast, credit authorization with direct debiting is a single
transaction process wherein the credit-control server directly
deducts a suitable amount of money from the user's account as soon as
the credit authorization request is received. Upon receipt of a
successful credit authorization answer, the credit-control client
allows service delivery to the end user. This process is
accomplished with the one-time event. Session state is not
maintained.
</t>
<t>
In a multi-service environment, an end user can issue an additional
service request (e.g., data service) during an ongoing service (e.g.,
voice call) toward the same account. Alternatively, during an active
multimedia session, an additional media type is added to the session,
causing a new simultaneous request toward same account.
Consequently, this needs to be considered when credit resources are
granted to the services.
</t>
<t>
The credit-control application also supports operations such as
service price enquiry, user's balance check, and refund of credit on
the user's account. These operations are accomplished with the
one-time event. Session state is not maintained.
</t>
<t>
Flexible failure handling, specific to the credit-control, is
defined in the application. This allows the the service provider
to control the credit-control client behavior according to its own
risk management policy.
</t>
<t>
The Credit-Control-Failure-Handling AVP and the Direct-Debiting-Failure-Handling
AVP are defined to determine what is done if the
sending of credit-control messages to the credit-control server has
been temporarily prevented. The usage of the Credit-Control-Failure-Handling
AVP and the Direct-Debiting-Failure-Handling AVP
allows flexibility, as failure handling for the credit-control
session and one-time event direct debiting may be different.
</t>
<section anchor="sec-4.1" title="Service-Specific Rating Input and Interoperability">
<t>
The Diameter credit-control application defines the framework for
credit-control; it provides generic credit-control mechanisms
supporting multiple service applications. The credit-control
application, therefore, does not define AVPs that could be used as
input in the rating process. Listing the possible services that
could use this Diameter application is out of scope for this generic
mechanism.
</t>
<t>
It is reasonable to expect that a service level agreement will exist
between providers of the credit-control client and the credit-control
server covering the charging, services offered, roaming agreements,
agreed rating input (i.e., AVPs), and so on.
</t>
<t>
Therefore, it is assumed that a Diameter credit-control server will
provide service only for Diameter credit-control clients that have
agreed beforehand as to the content of credit-control messages.
Naturally, it is possible that any arbitrary Diameter credit-control
client can interchange credit-control messages with any Diameter
credit-control server, but with a higher likelihood that unsupported
services/AVPs could be present in the credit-control message, causing
the server to reject the request with an appropriate result-code.
</t>
<section anchor="sec-4.1.1" title="Specifying Rating Input AVPs">
<t>
There are two ways to provide rating input to the credit-control
server: either by using AVPs or by including them in the Service-Parameter-Info
AVP. The general principles for sending rating
parameters are as follows:
</t>
<t>
1a. The service SHOULD re-use existing AVPs if it can use AVPs
defined in existing Diameter applications (e.g., <xref target="RFC7155"/>
for network
access services). Re-use of existing AVPs is strongly recommended in
<xref target="RFC6733"/>.
</t>
<t>
For AVPs of type Enumerated, the service may require a new value to
be defined. Allocation of new AVP values is done as specified in
<xref target="RFC6733"/>, section 1.3.
</t>
<t>
1b. New AVPs can be defined if the existing AVPs do not provide
sufficient rating information. In this case, the procedures defined
in <xref target="RFC6733"/> for creating new AVPs MUST be followed.
</t><t>
1c. For services specific only to one vendor's implementation, a
Vendor-Specific AVP code for Private use can be used. Where a
Vendor-Specific AVP is implemented by more than one vendor,
allocation of global AVPs is encouraged instead; refer to <xref target="RFC6733"/>.
</t>
<t>
2. The Service-Parameter-Info AVP MAY be used as a container to pass
legacy rating information in its original encoded form (e.g., ASN.1
BER). This method can be used to avoid unnecessary conversions from
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
<xref target="sec-8.43"/>.
</t>
<t>
New service applications SHOULD favor the use of explicitly defined
AVPs as described in items 1a and 1b, to simplify interoperability.
</t>
</section>
<section anchor="sec-4.1.2" title="Service-Specific Documentation">
<t>
The service-specific rating input AVPs, the contents of the Service-Parameter-Info
AVP or Service-Context-Id AVP (defined in <xref target="sec-8.42"/>)
are not within the scope of this document. To facilitate interoperability,
it is RECOMMENDED that the rating input and the values of the
Service-Context-Id be coordinated via an informational RFC or other
permanent and readily available reference, preferably, of another
cooperative standardization body (e.g., 3GPP, OMA, or 3GPP2). However,
private services may be deployed that are subject to agreements
between providers of the credit-control server and client. In
this case, vendor-specific AVPs can be used.
</t>
<t>
This specification, together with the above service-specific
documents, governs the credit-control message. Service-specific
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
applications), and thus have to be included in the Credit-Control-Request
command by a Diameter credit-control client supporting a
given service as *[AVP]. Should Service-Parameter-Info be used, then
the service-specific document MUST specify the exact content of this
grouped AVP.
</t>
<t>
The Service-Context-Id AVP MUST be included at the command level of a
Credit-Control Request to identify the service-specific document that
applies to the request. The specific service or rating group the
request relates to is uniquely identified by the combination of
Service-Context-Id and Service-Identifier or Rating-Group.
</t>
</section>
<section anchor="sec-4.1.3" title="Handling of Unsupported/Incorrect Rating Input">
<t>
Diameter credit-control implementations are required to support the
Mandatory rating AVPs defined in service-specific documentation of
the services they support, according to the 'M' bit rules in
<xref target="RFC6733"/>.
</t>
<t>
If a rating input required for the rating process is incorrect in the
Credit-control request, or if the credit-control server does not
support the requested service context (identified by the Service-Context-Id
AVP at command level), the Credit-control answer MUST
contain the error code DIAMETER_RATING_FAILED. A CCA message with
this error MUST contain one or more Failed-AVP AVPs containing the
missing and/or unsupported AVPs that caused the failure. A Diameter
credit-control client that receives the error code
DIAMETER_RATING_FAILED in response to a request MUST NOT send similar
requests in the future.
</t>
</section>
<section anchor="sec-4.1.4" title="RADIUS Vendor-Specific Rating Attributes">
<t>
When service-specific documents include RADIUS vendor-specific
attributes that could be used as input in the rating process, the
rules described in <xref target="RFC7155"/> for formatting the Diameter AVP MUST be
followed.
</t>
<t>
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
set to the IANA Vendor identification value. The Diameter AVP data
field contains only the attribute value of the RADIUS attribute.
</t>
</section>
</section>
</section>
<section anchor="sec-5" title="Session Based Credit-Control">
<section anchor="sec-5.1" title="General Principles">
<t>
For a session-based credit-control, several interrogations are
needed: the first, intermediate (optional) and the final
interrogations. This is illustrated in
<xref target="first_interrogation"/> and
<xref target="first_interrogation_auth"/>.
</t>
<t>
If the credit-control client performs credit-reservation before
granting service to the end user, it MUST use several interrogations
toward the credit-control server (i.e., session based credit-control).
In this case, the credit-control server MUST maintain the
credit-control session state.
</t>
<t>
Each credit-control session MUST have a globally unique Session-Id as
defined in <xref target="RFC6733"/>, which MUST NOT be
changed during the lifetime of a credit-control session.
</t>
<t>
Certain applications require multiple credit-control sub-sessions.
These applications would send messages with a constant Session-Id
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
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
are in use.
</t>
<t>
Note that the service element might send a service-specific
re-authorization message to the AAA server due to expiration of the
authorization-lifetime during an ongoing credit-control session.
However, the service-specific re-authorization does not influence the
credit authorization that is ongoing between the credit-control
client and credit-control server, as credit authorization is
controlled by the burning rate of the granted quota.
</t>
<t>
If service-specific re-authorization fails, the user will be
disconnected, and the credit-control client MUST send a final
interrogation to the credit-control server.
</t>
<t>
The Diameter credit-control server may seek to control the validity
time of the granted quota and/or the production of intermediate
interrogations. Thus, it MAY include the Validity-Time AVP in the
answer message to the credit-control client. Upon expiration of the
Validity-Time, the credit-control client MUST generate a credit-control
update request and report the used quota to the credit-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
granted service unit(s) (G-S-U). If the Validity-Time is used, its value
SHOULD be given as input to set the session supervision timer Tcc
(the session supervision timer MAY be set to two times the value of
the Validity-Time, as defined in <xref target="sec-13"/>). Since credit-control
update requests are also produced at the expiry of granted service
units and/or for mid-session service events, the omission of
Validity-Time does not mean that intermediate interrogation for the
purpose of credit-control is not performed.
</t>
<section anchor="sec-5.1.1" title="Basic Tariff-Time Change Support">
<t>
The Diameter credit-control server and client MAY optionally support
a tariff change mechanism. The Diameter credit-control server may
include a Tariff-Time-Change AVP in the answer message. Note that
the granted units should be allocated based on the worst-case
scenario in case of forthcoming tariff change, so that the overall
reported used units would never exceed the credit reservation.
</t>
<t>
When the Diameter credit-control client reports the used units and a
tariff change has occurred during the reporting period, the Diameter
credit-control client MUST separately itemize the units used before
and after the tariff change. If the client is unable to distinguish
whether units straddling the tariff change were used before or after
the tariff change, the credit-control client MUST itemize those units
in a third category.
</t>
<t>
If a client does not support the tariff change mechanism and it
receives a CCA message carrying the Tariff-Time-Change AVP, it MUST
terminate the credit-control session, giving a reason of
DIAMETER_BAD_ANSWER in the Termination-Cause AVP.
</t>
<t>
For time based services, the quota is continuously consumed at the
regular rate of 60 seconds per minute (ignoring leap seconds). At the time when credit
resources are allocated, the server already knows how many units will
be consumed before the tariff time change and how many units will be
consumed afterward. Similarly, the server can determine the units
consumed at the before rate and the units consumed at the rate
afterward in the event that the end-user closes the session before
the consumption of the allotted quota. There is no need for
additional traffic between client and server in the case of tariff
time changes for continuous time based service. Therefore, the
tariff change mechanism is not used for such services. For time-based
services in which the quota is NOT continuously consumed at a
regular rate, the tariff change mechanism described for volume and
event units MAY be used.
</t>
</section>
<section anchor="sec-5.1.2" title="Credit-Control for Multiple Services within a (sub-)Session">
<t>
When multiple services are used within the same user session and each
service or group of services is subject to different cost, it is
necessary to perform credit-control for each service independently.
Making use of credit-control sub-sessions to achieve independent
credit-control will result in increased signaling load and usage of
resources in both the credit-control client and the credit-control
server. For instance, during one network access session the end user
may use several http-services subject to different access cost. The
network-access-specific attributes such as the quality of service
(QoS) are common to all the services carried within the access
bearer, but the cost of the bearer may vary depending on its content.
</t>
<t>
To support these scenarios optimally, the credit-control application
enables independent credit-control of multiple services in a single
credit-control (sub-)session. This is achieved by including the
optional Multiple-Services-Credit-Control AVP in Credit-Control-Request/Answer
messages. It is possible to request and allocate
resources as a credit pool shared between multiple services. The
services can be grouped into rating groups in order to achieve even
further aggregation of credit allocation. It is also possible to
request and allocate quotas on a per service basis. Where quotas are
allocated to a pool by means of the Multiple-Services-Credit-Control
AVP, the quotas remain independent objects that can be re-authorized
independently at any time. Quotas can also be given independent
result codes, validity times, and Final-Unit-Indications
or QoS-Final-Unit-Indications.
</t>
<t>
A Rating-Group gathers a set of services, identified by a Service-Identifier,
and subject to the same cost and rating type (e.g.,
$0.1/minute). It is assumed that the service element is provided
with Rating-Groups, Service-Identifiers, and their associated
parameters that define what has to be metered by means outside the
scope of this specification. (Examples of parameters associated to
Service-Identifiers are IP 5-tuple and HTTP URL.) Service-Identifiers
enable authorization on a per-service based credit as well as
itemized reporting of service usage. It is up to the credit-control
server whether to authorize credit for one or more services or for
the whole rating-group. However, the client SHOULD always report
used units at the finest supported level of granularity. Where quota
is allocated to a rating-group, all the services belonging to that
group draw from the allotted quota. The following is a graphical
representation of the relationship between service-identifiers,
rating-groups, credit pools, and credit-control (sub-)session.
</t>
<figure title="Multiple-Service (sub)-Session Example" anchor="multiservice">
<artwork><![CDATA[
DCC (Sub-)Session
|
+------------+-----------+-------------+--------------- +
| | | | |
Service-Id a Service-Id b Service-Id c Service-Id d.....Service-Id z
\ / \ / /
\ / \ / /
\ / Rating-Group 1.......Rating-Group n
\ / | |
Quota ---------------Quota Quota
| / |
| / |
Credit-Pool Credit-Pool
]]>
</artwork>
</figure>
<t>
If independent credit-control of multiple services is used, the
Validity-Time AVP and Final-Unit-Indication AVP or QoS-Final-Unit-Indication AVP
SHOULD be present either in the Multiple-Services-Credit-Control AVP(s) or at
command level as single AVPs. However, the Result-Code AVP MAY be present
both on the command level and within the Multiple-Services-Credit-Control AVP.
If the Result-Code AVP on the command level indicates a value other than
SUCCESS, then the Result-Code AVP on command level takes precedence over
any included in the Multiple-Services-Credit-Control AVP.
</t>
<t>
The credit-control client MUST indicate support for independent
credit-control of multiple services within a (sub-)session by
including the Multiple-Services-Indicator AVP in the first
interrogation. A credit-control server not supporting this feature
MUST treat the Multiple-Services-Indicator AVP and any received
Multiple-Services-Credit-Control AVPs as invalid AVPs.
</t>
<t>
If the client indicated support for independent credit-control of
multiple services, a credit-control server that wishes to use the
feature MUST return the granted units within the Multiple-Services-Credit-Control
AVP associated to the corresponding service-identifier
and/or rating-group.
</t>
<t>
To avoid a situation where several parallel (and typically also
small) credit reservations must be made on the same account (i.e.,
credit fragmentation), and also to avoid unnecessary load on the
credit-control server, it is possible to provide service units as a
pool that applies to multiple services or rating groups. This is
achieved by providing the service units in the form of a quota for a
particular service or rating group in the Multiple-Services-Credit-Control
AVP, and also by including a reference to a credit pool for
that unit type.
</t>
<t>
The reference includes a multiplier derived from the rating
parameter, which translates from service units of a specific type to
the abstract service units in the pool. For instance, if the rating
parameter for service 1 is $1/MB and the rating parameter for service
2 is $0.5/MB, the multipliers could be 10 and 5 for services 1 and 2,
respectively.
</t>
<t>
If S is the total service units within the pool, M1, M2, ..., Mn are
the multipliers provided for services 1, 2, ..., n, and C1, C2, ...,
Cn are the used resources within the session, then the pool credit is
exhausted and re-authorization MUST be sought when:
</t>
<figure>
<artwork><![CDATA[
C1*M1 + C2*M2 + ... + Cn*Mn >= S
]]></artwork>
</figure>
<t>
The total credit in the pool, S, is calculated from the quotas, which
are currently allocated to the pool as follows:
</t>
<figure>
<artwork><![CDATA[
S = Q1*M1 + Q2*M2 + ... + Qn*Mn
]]></artwork>
</figure>
<t>
If services or rating groups are added to or removed from the pool,
then the total credit is adjusted appropriately. Note that when the
total credit is adjusted because services or rating groups are
removed from the pool, the value that need to be removed is the
consumed one (i.e., Cx*Mx).
</t>
<t>
Re-authorizations for an individual service or rating group may be
sought at any time; for example, if a 'non-pooled' quota is used up
or the Validity-Time expires.
</t>
<t>
Where multiple G-S-U-Pool-Reference AVPs (<xref target="sec-8.30"/>) with the same
G-S-U-Pool-Identifier are provided within a Multiple-Services-Credit-Control
AVP (<xref target="sec-8.16"/>) along with the Granted-Service-Unit
AVP, then these MUST have different CC-Unit-Type values, and they all
draw from the credit pool separately. For instance, if one
multiplier for time (M1t) and one multiplier for volume (M1v) are
given, then the used resources from the pool is the sum C1t*M1t +
C1v*M1v, where C1t is the time unit and C1v is the volume unit.
</t>
<t>
Where service units are provided within a Multiple-Services-Credit-Control
AVP without a corresponding G-S-U-Pool-Reference AVP, then
these are handled independently from any credit pool and from any
other services or rating groups within the session.
</t>
<t>
The credit pool concept is an optimal tool to avoid the over-reservation
effect of the basic single quota tariff time change
mechanism (the mechanism described in <xref target="sec-5.1.1"/>). Therefore,
Diameter credit-control clients and servers implementing the
independent credit-control of multiple services SHOULD leverage the
credit pool concept when supporting the tariff time change. The
Diameter credit-control server SHOULD include both the Tariff-Time-Change
and Tariff-Change-Usage AVPs in two quota allocations in the
answer message (i.e., two instances of the Multiple-Services-Credit-Control
AVP). One of the granted units is allocated to be used
before the potential tariff change, while the second granted units
are for use after a tariff change. Both granted unit quotas MUST
contain the same Service-Identifier and/or Rating-Group. This dual
quota mechanism ensures that the overall reported used units would
never exceed the credit reservation. The Diameter credit-control
client reports both the used units before and after the tariff change
in a single instance of the Multiple-Services-Credit-Control AVP.
</t>
<t>
The failure handling for credit-control sessions is defined in
<xref target="sec-5.7"/> and reflected in the basic credit-control state machine
in <xref target="sec-7"/>. Credit-control clients and servers implementing the
independent credit-control of multiple services in a (sub-)session
functionality MUST ensure failure handling and general behavior fully
consistent with the above mentioned sections, while maintaining the
ability to handle parallel ongoing credit re-authorization within a
(sub-)session. Therefore, it is RECOMMENDED that Diameter credit-control
clients maintain a PendingU message queue and restart the Tx
timer (<xref target="sec-13"/>) every time a CCR message with the value
UPDATE_REQUEST is sent while they are in PendingU state. When
answers to all pending messages are received, the state machine moves
to OPEN state, and Tx timer is stopped. Naturally, the action performed
when a problem for the session is detected according to <xref target="sec-5.7"/>
affects all the ongoing services (e.g., failover to a backup server
if possible affect all the CCR messages with the value UPDATE_REQUEST
in the PendingU queue).
</t>
<t>
Since the client may send CCR messages with the value UPDATE_REQUEST
while in PendingU (i.e., without waiting for an answer to ongoing
credit re-authorization), the time space between these requests may
be very short, and the server may not have received the previous
request(s) yet. Therefore, in this situation the server may receive
out of sequence requests and SHOULD NOT consider this an error
condition. A proper answer is to be returned to each of those
requests.
</t>
</section>
</section>
<section anchor="sec-5.2" title="First Interrogation">
<t>
When session based credit-control is required (e.g., the
authentication server indicated a prepaid user), the first