File: rfc3334.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (2467 lines) | stat: -rw-r--r-- 103,014 bytes parent folder | download | duplicates (5)
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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467






Network Working Group                                           T. Zseby
Request for Comments: 3334                                     S. Zander
Category: Experimental                                          G. Carle
                                                        Fraunhofer FOKUS
                                                            October 2002


                        Policy-Based Accounting

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document describes policy-based accounting which is an approach
   to provide flexibility to accounting architectures.  Accounting
   policies describe the configuration of an accounting architecture in
   a standardized way.  They are used to instrument the accounting
   architecture and can be exchanged between Authentication,
   Authorization and Accounting (AAA) entities in order to share
   configuration information.

   This document describes building blocks and message sequences for
   policy-based accounting in the generic AAA architecture (RFC 2903).
   Examples are given for the usage of accounting policies in different
   scenarios.  It is also shown how accounting components can be
   integrated into the AAA authorization framework (RFC 2904).  This
   document does not propose a language for the description of
   accounting policies.  Rather, it is assumed that a suitable policy
   language can be chosen from existing or upcoming standards.

Table of Contents

   1.    Introduction...............................................2
   1.1   Motivation.................................................2
   1.2   Document Scope.............................................3
   2.    Terminology................................................4
   3.    Impact of Provider Network Characteristics on Accounting...7
   4.    Business roles and relations...............................8
   5.    Reference Model and Building Blocks.......................11



Zseby, et. al.                Experimental                      [Page 1]

RFC 3334                Policy-Based Accounting             October 2002


   6.    Accounting Policies.......................................14
   6.1   Accounting Policy Condition...............................15
   6.2   Accounting Policy Action..................................16
   6.3   Example for Meter Configuration...........................17
   7.    Accounting Services.......................................19
   7.1   Integrated Accounting.....................................19
   7.2   Discrete Accounting.......................................21
   7.3   Intra-Domain Accounting...................................22
   7.4   Inter-Domain Accounting...................................23
   8.    Accounting with different Authorization Models............25
   8.1   Agent Sequence............................................25
   8.2   Pull Sequence.............................................26
   8.3   Push Sequence.............................................27
   8.4   Roaming...................................................28
   9.    Examples..................................................29
   9.1   Printing Service Example..................................29
   9.1.1 Intra-Domain Accounting...................................29
   9.1.2 Inter-Domain Accounting...................................30
   9.1.3 User Accounting Indication................................31
   9.2   Mobile/Roaming Example....................................31
   9.3   Diffserv Example..........................................33
   9.4   User Accounting Indication Example........................37
   10.   Security Considerations...................................39
   11.   References................................................41
   12.   Acknowledgments...........................................42
   Author's Addresses..............................................43
   Full Copyright Statement........................................44

1. Introduction

1.1 Motivation

   Even if we will have much more bandwidth in the future than now, the
   control of network resource utilization remains essential for the
   support of applications with special demands and for the prevention
   of (malicious or accidental) waste of bandwidth.  Charging provides a
   possibility to control utilization and sharing of network resources.
   Charging in multi-service networks can be done based on the reserved
   or the actual used resources.  Charging on reserved resources is an
   important concept since reservation usually precludes other users
   from using the reserved resources.  Nevertheless, if charging is
   limited to reservation parameters only, the applied charge depends on
   the ability of the user to give a good prediction of the expected
   traffic characteristics.  This can be extenuated by using a charging
   scheme that is based on both the reserved and the used resources.  In
   order to support usage-based charging, the collection of information
   about the resource reservation and utilization is required.  The
   collection of data about resource usage is called accounting.



Zseby, et. al.                Experimental                      [Page 2]

RFC 3334                Policy-Based Accounting             October 2002


   Service providers have various options for service differentiation,
   charging schemes and the provisioning of accounting services.  The
   applied charging schemes for the provided services are one
   significant feature used by providers to distinguish themselves from
   competitors.  Therefore, providers use different charging schemes and
   may change the schemes in accordance with their business plan.
   Providers can also offer different accounting services (e.g.
   standard, comprehensive, etc.) in order to allow customers/users to
   choose one scheme that meets the customers/users needs.  Furthermore,
   it may be advantageous for a provider to outsource accounting
   functionality to a third party.  Users introduce various traffic
   profiles and may have individual preferences regarding accounting
   services (like itemized invoices, accounting indications, spending
   limits etc.).

   One further challenge for the configuration of accounting services
   are heterogeneous metering and accounting infrastructures within
   provider domains.  Also, the usage of different accounting and
   metering solutions used in different provider networks complicates
   the sharing of configuration parameters (e.g. in roaming scenarios).

   The configuration and dynamic adaptation of the accounting process to
   the business model and specific user demands requires a flexible
   configurable accounting infrastructure.  The utilization of
   standardized policies for the expression of conditions and related
   configuration actions also allows the configuration of heterogeneous
   infrastructures.  For this purpose we propose to use accounting
   policies to configure the accounting infrastructure and use the
   Authentication, Authorization and Accounting (AAA) architecture to
   exchange and to deploy these policies.

1.2 Document Scope

   This document describes the structure and usage of accounting
   policies.  It shows how the characteristics of the provider network
   influence the requirements for accounting.  The relations between the
   different roles that are involved in the accounting process and the
   required building blocks for an accounting architecture are
   introduced.  This document describes an architecture and mechanisms
   to configure the accounting service.  It proposes to use the AAA
   protocol for the exchange of accounting configuration information
   expressed in policies.  It does not propose a specific protocol for
   the accounting configuration itself.  The configuration itself can be
   done by existing protocols (e.g. Common Open Policy Service Protocol
   for Support of Policy Provisioning - COPS-PR, Simple Network
   Management Protocol - SNMP, etc.).  Furthermore, it is shown how
   different accounting services can be provided in intra- and inter-
   domain scenarios.  Examples are given for the usage of accounting



Zseby, et. al.                Experimental                      [Page 3]

RFC 3334                Policy-Based Accounting             October 2002


   policies in different scenarios.  They show how accounting components
   can be integrated into the authorization framework proposed in
   [RFC2904].

   Accounting management architectures and objectives as well as the
   transport of accounting records are discussed in [RFC2975] and are
   not further explained here.  This document focuses on the
   configuration of the accounting architecture and measurement devices.

   The policy-based accounting architecture represented in this document
   describes policy-based accounting from the perspective of a Generic
   AAA Server [RFC2903].  Such a server combines into a single entity
   the functions of managing accounting policy, together with the
   functions of managing user-specific authentication, authorization and
   service provisioning.  Some service providers may choose to implement
   an approach that does not combine these functions into a single
   entity or protocol, in which case that particular aspect of this
   architecture does not apply.

   This document does not propose a language for the description of
   accounting policies.  It is rather assumed that a suitable policy
   language can be chosen from existing or upcoming standards.

2. Terminology

   Accounting Indication/Confirmation
           Accounting indication messages are pushed from the
           originating AAA server (the server where the accounting
           information was generated) to the recipient which can be an
           AAA server or a customer/user application.  Accounting
           indications contain accounting records which describe the
           resource consumption for a service.  Accounting indication
           messages can also contain aggregated information for multiple
           services.  There can be interim and end-of-session accounting
           indication messages.  Interim indications are delivered in
           specified intervals to the recipient during the service
           session while end-of-session indications are given to the
           recipient at the end of the session only.  Accounting
           indications may be acknowledged by accounting confirmations
           to provide application layer reliability.

   Accounting Policy Indication/Confirmation
           Accounting policy indication messages contain accounting
           policies and are sent from a customer/user or a AAA server to
           another AAA server.  Accounting policy indications may be
           acknowledged by accounting policy confirmations to provide
           application layer reliability.




Zseby, et. al.                Experimental                      [Page 4]

RFC 3334                Policy-Based Accounting             October 2002


   Accounting Request/Answer
           Accounting requests are sent by an AAA server to another AAA
           server to request the current accounting information for a
           particular session set (polling).  The request is answered
           with an accounting answer which contains the accounting
           records.

   Accounting Policy Request/Answer
           Accounting policy requests are sent by an AAA server to
           another AAA server or a customer/user to request accounting
           policies for a service.  The request is answered by an
           accounting policy answer that contains the accounting policy.

   Accounting Policies
           Accounting policies describe rules for generation, transport
           and storage of accounting data.  These rules are used for the
           configuration of the accounting process.

   Application Specific Module (ASM)
           An ASM provides the functionalities required for the user
           configuration of a service to an authenticated and authorized
           user.  It gets application specific information (ASI) (e.g.
           for user configuration) from the AAA server, either in a
           generic format or in an application specific format,
           encapsulated in a standard message sent to the ASM.  The ASM
           either extracts the ASI from the message or converts
           information given in a generic format into the appropriate
           application specific format.  Further information on how the
           ASM is used can be found in [RFC2903].

   Charging Schemes
           A charging scheme is an instruction for calculating a charge.
           Usually, a charging scheme is represented by a formula that
           consists of charging variables (e.g. volume, time, reserved
           peak rate) and charging coefficients (e.g. price per time
           unit).  The charging variables are usually filled by
           information from accounting data.

   Classifier
           This document uses the definition of classifier as given in
           [RFC2475].  Since this document assumes that meters already
           include classification functions, the term classifier is only
           used for entities that perform additional classification
           (e.g. as part of data post processing).







Zseby, et. al.                Experimental                      [Page 5]

RFC 3334                Policy-Based Accounting             October 2002


   Meter
           This document uses the definition of meter as given in
           [RFC2722].  This meter definition already includes the
           classification of packets.  It differs from the DiffServ
           model [RFC2475] where classifier and meter are considered as
           separate entities.

   Meter Reader/Collector
           This document uses the definition of meter reader and
           collector as given in [RFC2722].

   Meter Manager
           This document uses the definition of meter manager as given
           in [RFC2722].

   Policy, policy condition, policy action
           The terms policy, policy condition and policy action are used
           as defined in [RFC3198].

   QoS Auditing
           Quality of Service (QoS) Auditing is the process of
           evaluating whether a given quality of service guarantee (e.g.
           thresholds for QoS parameters given in a Service Level
           Agreement -  SLA) has been met during the service
           provisioning.

   Service Class
           A service class specifies the handling of a service (as
           defined in [RFC3198]) belonging to that class by the service
           provider.  A service class has some kind of identifier (e.g.
           name) and the handling of the service is defined by a Service
           Level Specification (SLS) as described in [RFC3198].

   User Configuration
           We refer to User Configuration as the process of configuring
           a service for a user which has been authenticated and
           authorized by the AAA architecture.  Although an AAA
           architecture is not directly responsible for this user-
           dependent configuration, it may be responsible for triggering
           the process.

   Further definitions of service related terms (Service, Service
   Subscriber, Service User, Network Provider, Service Provider, Broker)
   can be found in section 4 (business roles and their relations).







Zseby, et. al.                Experimental                      [Page 6]

RFC 3334                Policy-Based Accounting             October 2002


3. Impact of Provider Network Characteristics on Accounting

   There are many options for future service providers for the
   realization of service differentiation and provisioning.  Therefore,
   provider networks can vary with respect to several characteristics
   that impact accounting and charging:

   - Size and Purpose
   A small ISP that deals with individual customers may charge
   individual users based on single flows.  Backbone operators often
   have small ISPs and large corporations as customers, and usually
   charge based on traffic aggregates instead of individual flows.

   - QoS provisioning technique
   Diffserv accounting requirements differ from Intserv accounting
   requirements (e.g. meter granularity).

   - Service classes
   The definition of service classes within a network and the degree of
   freedom that customers are given (e.g. gold/silver/bronze service vs.
   a free choice of individual traffic profile parameters) is important,
   e.g. for the flow classification within the network, and influences
   the accounting functions required.

   - Charging scheme
   There exists a wide variety of charging schemes using tariff
   variables based on different technical and/or economic models.  The
   chosen charging scheme(s) influence the accounting requirements for
   the provider.  While some charging schemes lead to zero or only few
   accounting requirements, other charging schemes may be highly
   demanding.  For instance, flat rate charging schemes require no
   accounting infrastructure at all.  In contrast to this, volume-based
   charging schemes require the measurement of the transmitted volume
   and, with this, increases the complexity for accounting.  Tariffs
   that introduce variable prices may require to provide the users
   regularly with accounting information (e.g. by interim accounting
   indications).

   - Accounting Services
   Providers may offer different accounting services (e.g. accounting
   indication, itemized invoice, etc.)

   - Accounting agreements with other providers
   Providers may have agreements with other providers in order to share
   accounting tasks and distribute accounting data so that, e.g.,
   metering need only be done once.  If so, it may be useful if
   providers can not only exchange accounting data, but also information
   on the configuration of accounting modules (e.g. meters).  It is



Zseby, et. al.                Experimental                      [Page 7]

RFC 3334                Policy-Based Accounting             October 2002


   important for providers to agree beforehand how accounting data will
   be collected and monitored, and how disputes concerning accounting
   data will be resolved.  In order to minimize disputes between
   providers, it is important for them to agree that either both will
   collect accounting data - and will compare it with the other's data
   at regular intervals, e.g. monthly - or both will use a single source
   of accounting data provided by one of them (or by a trusted third
   party).

   - Exploiting Capabilities of Existing Infrastructure (meters, data
   collection points)
   Providers may already have functions within the network that can
   provide accounting functions (e.g. MIB objects, profile meters,
   proprietary accounting solutions).  In order to avoid duplicated
   functionality, it should be possible to use these accounting
   resources.  Therefore, the configuration of different types of
   accounting modules (e.g. meters) should be possible. A common
   language to express accounting module configurations would be useful
   for this purpose.

4. Business roles and relations

   In investigating service provisions in the current and forthcoming
   Internet, we identified different business roles which are part of
   the service usage lifecycle.  In this section we first define the
   term service.  Afterwards, the different roles and their
   relationships are defined.  The business roles in this model are used
   in the later examples.

   - Service
   A service is a set of capabilities offered by a provider to a
   customer.  In this definition, provider and customer can be one of
   the business roles defined later.  Different kinds of services have
   to be recognized.

        - Information services handle the delivery of information to the
        customer on top of transport services.  In content-based
        services, the service subscriber pays for the content (e.g. for
        a file, an image, a video, etc.).  In communication-based
        services, the service subscriber pays for the provisioning of a
        certain form of communication (e.g. video conferencing or IP
        telephony).

        - Transport services describe the provisioning of pure
        transportation of IP packets.  At the IP layer, this may include
        the differentiation of packets (e.g. number of packets with a
        certain DSCP), Intserv based reservation or other methods for
        QoS enhancement (e.g. Automatic Repeat reQuest -  ARQ, Forward



Zseby, et. al.                Experimental                      [Page 8]

RFC 3334                Policy-Based Accounting             October 2002


        Error Correction -  FEC).  A transport service might also
        include mechanisms on other layers for improving the transport
        (e.g. MPLS).

        - Management services are responsible for the management of
        resources (e.g. configuration, accounting, security).
        Accounting services describe the provisioning of data about the
        current or previous resource reservation and usage.  Accounting
        services are needed by providers to generate a bill or by users
        to monitor their resource usage.

   - Service Subscriber
   The service subscriber is the entity that has subscribed to a service
   and thus has a contractual relationship with a service provider and a
   network provider which provides the underlying transport service.  A
   service subscriber can also act as a service user.  The service
   subscriber might have a relationship with a broker that provides
   service relevant information.

   - Service User
   The service user is the entity that uses the service.  The service
   user can be identical to the service subscriber.  In cases where
   subscriber and user are not identical, the service subscriber should
   be able to control the service usage for all service users she is
   responsible for.

   - Network Provider
   A network provider is the entity that provides the underlying network
   infrastructure for the service user, service subscriber, service
   provider and broker.  A network provider provides transport services.
   The services are delivered on top of the network infrastructure.  The
   service provider has a contractual relationship with the service
   subscriber and service provider (and the broker).  The transport
   network of a network provider is probably not a global network which
   connects all subscribers, providers and brokers.  The transport
   network is segmented into a number of sub-networks or domains
   controlled by different network providers with business relations
   existing between them.  Each domain is responsible for intra-domain
   management and accounting.  For inter-domain management and
   accounting, appropriate communication interfaces between network
   providers must exist.

   - Service Provider
   A service provider entity provides a service.  A service provider can
   offer a service directly to the service subscriber/user.  A service
   provider can also act like a wholesaler selling a service to another
   service provider (retailer) which re-sells the service to the service
   subscriber.  The service provider has contractual relationships with



Zseby, et. al.                Experimental                      [Page 9]

RFC 3334                Policy-Based Accounting             October 2002


   other service providers, subscribers, brokers and network providers.
   A service provider provides information services on top of transport
   services provided by network providers.

   - Broker
   The broker entity allows the other roles to access the information
   controlled by the broker.  The broker can provide different
   information to different business roles.  For example, a service
   subscriber can get references to appropriate service providers and/or
   network providers (e.g. a broker gives the subscriber a reference to
   a network provider which can provide bandwidth as required by the
   subscriber).  A broker can also interact with other brokers to
   complete their information.  In this case, broker-to-broker business
   relationships exist.

   Figure 1 depicts the different roles and the business relations
   between them.

                                     +----+
                                     V    |
                       +---------------+  |
                       |  Broker       |<-+
               +------>|               |<-----------------+
               |       +---------------+                  |
               |               ^                          |
               |               |                          |
               |               V                          V
               |       +------------------+        +---------------+
               |       |  Service         |        |   Service     |
               |       |  Subscriber      |<------>|   Provider    |
               |       |                  |        |               |<-+
               |       | +--------------+ |        +---------------+  |
               |       | | Service User | |               ^      ^    |
               |       | +--------------+ |               |      +----+
               |       +------------------+               |
               |               ^                          |
               |               |                          |
               |               V                          |
               |       +---------------+                  |
               +------>|  Network      |<-----------------+
                       |  Provider     |<-+
                       +---------------+  |
                                     ^    |
                                     +----+

   Figure 1: Roles and business relations





Zseby, et. al.                Experimental                     [Page 10]

RFC 3334                Policy-Based Accounting             October 2002


   The following examples show how this business relationship model can
   be applied to different services.

   Example 1: This example describes an Internet printing scenario
   according to the "print-by-reference" model [RFC2566].  The
   subscriber is a company and the users are the employees of that
   company.  The file server and print server belong to two different
   service providers.  The company subscribes to the print server
   service which acts as reseller for the file service.  The file server
   service chooses the appropriate transport service (maybe based on
   user preference), thus the file server has a contract with a network
   provider using the offered transport service for downloading the data
   from the given location and sending them to the print server.

   Example 2: A company (service subscriber) has a contract with a video
   archive (service provider).  An employee can download clips in
   different qualities from the archive.  The employee can use different
   transport mechanisms for the download.  In order to get the
   appropriate transport, the user contacts an agency (broker) that
   returns a reference to a network provider which provides the required
   transport service.  As an alternative, the content (video) can be
   delivered in different qualities via different transport mechanisms
   by the service provider.  The service provider chooses an appropriate
   network provider which provides a transport service compliant with
   the conditions the service provider offers to the subscribers.  In
   this case the service provider can use the facilities of a broker to
   get a reference to appropriate network providers.

5. Reference Model and Building Blocks

   We have developed a reference model for describing the interactions
   between the different metering, accounting and charging processes and
   their configuration via policies.  This reference model is shown in
   Figure 2.  At the right side, five layers show the different building
   blocks.  The blocks are layered according to the processing of the
   data from the bottom level metering via accounting, up to the final
   billing process.  Data aggregation is not only done at the collection
   layer, it can also be done at the other layers.  The building blocks
   on the different layers are configured through the policies shown on
   the left side.  Higher layer policies can be translated into lower
   layer policies.  The configuration parameters are extracted from the
   policy and passed to the corresponding building block.  The tasks of
   the different building blocks are as follows:

   - Metering
   Meters are needed for capturing data about resource consumption in
   the network (e.g. transmitted volume).  They will probably be placed
   at the edges of the network.  Two types of meters can be



Zseby, et. al.                Experimental                     [Page 11]

RFC 3334                Policy-Based Accounting             October 2002


   distinguished: Static meters and configurable meters.  In the case of
   static meters, all flows are measured with a fixed granularity, not
   distinguishing if a subsequent charging process needs the specific
   meter data or not.  In most cases the large amount of captured data
   makes filtering and/or aggregation after the metering necessary.  In
   case of a configurable meter, the meter collects meter data only for
   flows specified by metering policies.

   For configuration of the meter process, the following issues must be
   addressed: (a) metering scope (whether to meter all flows or only
   selected flows), (b) flow granularity (e.g. micro flows or traffic
   aggregates) (c) metered flow attributes (i.e. which data is to be
   collected for a specific flow), and (d) meter accuracy (measurement
   intervals etc.).

   - Collection
   The data gathered by the meter(s) has to be collected for further
   processing.  Collection of meter data can be initiated by the meter
   itself (push model) or by a collector entity (pull model).  Collected
   data can be aggregated before being passed to the accounting layer.
   Metering policies define how collection and aggregation is done.






























Zseby, et. al.                Experimental                     [Page 12]

RFC 3334                Policy-Based Accounting             October 2002


         POLICY          CONFIGURATION          BUILDING BLOCKS

     +---------------+                   +-------------------------+
     |               |------------------>|        Billing          |
     |  Billing &    |                   +-------------------------+
     |  Charging     |                             ^ charging
     |               |                             | data
     |               |                   +-------------------------+
     |               |------------------>|        Charging         |
     +---------------+                   +-------------------------+
             |                                     ^ acct
             V                                     | data
     +---------------+                   +-------------------------+
     |  Accounting   |                   |                         |
     |               |------------------>|        Accounting       |
     +---------------+                   +-------------------------+
             |                                     ^ aggr. meter
             V                                     | data
     +---------------+                   +-------------------------+
     |               |------------------>|        Collection       |
     |  Metering     |                   |                         |
     |               |                   +-------------------------+
     |               |                             ^ meter
     |               |                             | data
     |               |                   +-------------------------+
     |               |------------------>|        Metering         |
     +---------------+                   +-------------------------+

   Figure 2: Reference Model

   - Accounting
   Accounting describes the collection of data about resource
   consumption.  This includes the control of data gathering (via
   metering), transport and storage of accounting data.  For subsequent
   charging, the metered data must be associated with a user that is the
   initiator of a flow and a customer (service subscriber) that is
   responsible for payment.  For initiation of an accounting process, a
   user or foreign provider must be authenticated and authorized.  These
   three functions can be performed by the AAA server.  The accounting
   process is configured through accounting policies.

   - Charging
   Charging derives non-monetary costs for accounting data sets based on
   service and customer specific tariff parameters.  Different cost
   metrics may be applied to the same accounting records even in
   parallel.  Charging policies define the tariffs and parameters which
   are applied.




Zseby, et. al.                Experimental                     [Page 13]

RFC 3334                Policy-Based Accounting             October 2002


   - Billing
   Billing translates costs calculated by the Charging into monetary
   units and generates a final bill for the customer.  Billing policies
   define among others the type (e.g. invoice, credit card), the form of
   the bill (e.g. itemized or not, partial anyomization, etc.) and the
   time for billing (e.g. weekly, monthly, etc.).

   We propose to use policies expressed in a standardized way to
   appropriately configure the meter, meter data collection and
   accounting processes.

6. Accounting Policies

   Accounting policies describe rules for generation, transport and
   storage of accounting data.  They can be exchanged between AAA
   instances at the user or provider premises.  They provide a
   standardized representation of configuration information that can be
   converted into the appropriate settings for different elements of the
   accounting infrastructures (e.g. different meters).

   As shown in Figure 2, accounting policies configure the accounting
   process.  Policies for the configuration of the metering and
   collection process can be derived from accounting policies.
   Accounting policies are not used to configure the charging or billing
   process.  Accounting policies reside in the AAA server (local
   policies) or are received from other AAA servers (extra-domain
   policies) or customers/users.  Two different models of obtaining
   accounting policies can be differentiated: push and pull model.

   Push Model
   In the push model, accounting policies are pushed from another AAA
   server or customer/user in order to establish the policies in the
   local accounting infrastructure.  The acceptance and use of pushed
   policies requires special security considerations.  The evaluation of
   the policy should not take place without an appropriate security
   check of the policy in advance.  Also, the evaluation of the
   condition can lead to unwanted actions in the AAA server if the
   condition contains critical data either intentionally (to attack the
   system) or by accident.  Even the evaluation of the condition can
   cause problems (e.g. DoS).  Therefore, not only the action, but also
   the condition, has to be checked for potential security hazards
   before it is evaluated.

   Pull Model
   In the pull model, the AAA server requests the policy from a remote
   AAA server or customer/user by sending an accounting policy request.
   The remote AAA server sends an accounting policy reply as an answer
   that contains the appropriate policy.



Zseby, et. al.                Experimental                     [Page 14]

RFC 3334                Policy-Based Accounting             October 2002


   Accounting policies are enforced by the network elements that are
   configured in accordance with the policies.  They influence the
   following settings in the accounting architecture:

   - meter configuration
   - data collection and aggregation
   - accounting record distribution and storage

6.1 Accounting Policy Condition

   An accounting policy consists of one or more rules, each having a
   condition part and an action part.  The condition part expresses
   under which condition the policy should be enforced.  The following
   attributes are examples for variables in a policy condition
   statement.

   - customer/user ID
   The customer/user ID identifies the customer or user of the service.
   It can be used in a policy condition in order to select a customer or
   user specific accounting configuration (as policy action).  For
   example, it can be user-dependent whether accounting indications are
   sent to the user or not.

   - IP address
   IP addresses specify the devices or networks from which the service
   usage takes place.  The address of specific hosts or subnets can be
   used to select accounting strategies specific to the customer or a
   user group associated with this address (e.g. all customers of an
   ISP, all public terminals etc.).

   - time of day
   The time of day can be used, for instance, to configure the level of
   detail for the accounting record, the report interval and the
   destination.

   - service class
   Service classes are defined by the provider.  They describe different
   levels or different kinds of services that are offered by the
   provider and are usually defined based on a business model.
   Customers/users select a service class.  This selected class can be
   used in accounting policies to define appropriate accounting settings
   per class.  With this it is possible, for instance, to provide more
   detailed accounting records for higher prioritized services than for
   standard services.







Zseby, et. al.                Experimental                     [Page 15]

RFC 3334                Policy-Based Accounting             October 2002


   - accounting type
   Accounting types combine multiple accounting settings under one
   keyword.  Like service classes, the offered accounting types are
   defined by the provider in accordance with the business model.  With
   this, providers can offer, for instance, different accounting types
   for one service and allow the customer/user to select one.  The
   combination of settings under one keyword simplifies the selection
   for users.  An example is the combination of high granular accounting
   records with short report intervals under a keyword (e.g.
   "comprehensive accounting"), or less frequent generation of less
   detailed records accessed by another keyword ("standard accounting").
   The definition of accounting types can also help in inter-domain
   scenarios if providers agree on accounting types.

6.2 Accounting Policy Action

   The action part defines the action that takes place if the condition
   is true.  The action for an accounting policy is usually the
   configuration of the accounting infrastructure.  This can already
   include settings for meters and collection entities.  The following
   list gives examples for parameters of the accounting infrastructure
   that can be configured by an accounting policy action:

   - accounting record type/structure
   The required accounting data depends on the charging scheme.
   Therefore, different accounting records should be supported.  There
   are two possibilities: Either different record types are defined, or
   a flexible record is used that consists of a variable set of
   accounting attributes.  Accounting policies can be used to
   communicate to neighbor providers which kind of accounting record is
   needed to provide appropriate data for the charging scheme.  The
   specification of the required accounting attributes can influence the
   settings of different components of the accounting architecture (e.g.
   which attributes have to be measured).  An overview of accounting
   attributes and records can be found in [RFC2924].

   - accounting record destination
   The accounting record destination describes to which entities
   accounting records are sent.  The accounting record destination can
   be a charging entity, a neighbor provider, a user entity or a
   specific database.  In these cases, authentication and authorization
   mechanisms have to be applied in order to ensure that unauthorized
   entities cannot get access to confidential data.

   - report interval
   The report interval specifies in what time intervals accounting
   records are generated and sent.  This influences the configuration of
   meters and collectors in the accounting architecture.



Zseby, et. al.                Experimental                     [Page 16]

RFC 3334                Policy-Based Accounting             October 2002


   - storage time
   If the accounting record destination is a database or a log file, the
   storage time specifies how long the accounting records have to be
   stored.

   - access list
   The access list specifies who has the permissions to read the stored
   accounting records.

   - flow granularity
   The flow granularity determines how fine grained (in coverage) the
   flows in the network are measured.  The granularity usually is
   configured by installing specific classification rules in the meter.
   It is also possible to set a specific granularity by configuring
   aggregation schemes that are applied after the metering process.  The
   granularity can range from individual micro flows (e.g. determined by
   the quintuple <src, dest, proto, src-port, dest-port>) up to coarse
   granular traffic aggregates (e.g. all traffic from one network).

   - meter accuracy
   The parameters for the meter accuracy can determine, for instance,
   how often measurements take place at the meter, how accurate
   timestamps should be, etc.  Meter accuracy parameters can also be
   used to configure sampling schemes.

6.3 Example for Meter Configuration

   Note: In the following examples, the use of NeTraMet or NetFlow to
         collect accounting information does not guarantee exact
         accounting data, so it is not recommended for use in situations
         where exact accounting data are needed.

   The following two examples show how accounting policies can be used
   to configure different meters.  The accounting policy is sent from
   the AAA server to the ASM and there converted to the appropriate
   configuration information for the used meter.

   If the meter NeTraMet [RFC2123] is used, the policy is converted into
   a NeTraMet ruleset that contains the relevant flows, attributes and
   reader instructions for the data collection.  This information is
   passed to the NeTraMet manager that configures the meter and meter
   reader in accordance with the given configuration.









Zseby, et. al.                Experimental                     [Page 17]

RFC 3334                Policy-Based Accounting             October 2002


     +------------------+
     |     AAA          |
     |                  |
     +------------------+
           |         ^
    Policy |         | Accounting Records
           V         |
     +------------------+
     |     ASM          |
     |                  |
     +------------------+
         |           ^
         |           |
         | config    +-----------------+
         |                             |
    +-------------------------------+  |
    |    |       Accounting         |  |
    |    V                          |  |
    | +----------------+            |  |
    | | Meter Manager  |            |  | Accounting Records
    | +----------------+            |  |
    |    |      |                   |  |
    |  SNMP     V                   |  |
    |  (conf)+---------------+      |  |
    |    |   | Meter Reader  |---------+
    |    |   +---------------+      |
    |    |              ^           |
    |    V              |           |
    | +-----------+     |           |
    | |   Meter   |-----+           |
    | +-----------+    SNMP(DATA)   |
    |                               |
    +-------------------------------+

   Figure 3: Policy based Accounting with NeTraMet

   If the meter NetFlow [NetFlow] is used, the meter policies are
   translated by the ASM into filter instructions for the flow
   collector.  The meter itself is static and therefore is not affected
   by the configuration information.











Zseby, et. al.                Experimental                     [Page 18]

RFC 3334                Policy-Based Accounting             October 2002


     +------------------+
     |    AAA           |
     |                  |
     +------------------+
           |         ^
    Policy |         | Accounting Records
           V         |
     +------------------+
     |     ASM          |
     |                  |
     +------------------+
         |           ^
         |           |
         | config    | Accounting Records
         |           |
    +-------------------------------+
    |    |    Accounting            |
    |    |                          |
    |    |  +---------------------+ |
    |    |  | Flow Collector      | |
    |    |  |      +------------+ | |
    |    |  |      | Classifier | | |
    |    |  |      | Aggregator | | |
    |    +->|      +------------+ | |
    |       +---------------------+ |
    |                   ^           |
    |                   |           |
    | +-----------+     |           |
    | |   Meter   |-----+           |
    | +-----------+   UDP (DATA)    |
    |                               |
    +-------------------------------+

   Figure 4: Policy based Accounting with NetFlow

7. Accounting Services

   Accounting can be seen as part of the service provisioning process
   (integrated accounting) or as a separate service (discrete
   accounting).  The different views and their impact on the accounting
   architecture are described below.

7.1 Integrated Accounting

   In the integrated accounting model, the accounting is seen as part of
   the provisioned service.  That means the accounting is coupled with a
   specific service.  Therefore, the accounting process is tailored to
   the specific service and might collect accounting information by



Zseby, et. al.                Experimental                     [Page 19]

RFC 3334                Policy-Based Accounting             October 2002


   directly exploiting some service specific entities.  For example,
   accounting for IP telephony could use call signaling information from
   a SIP server.  The configuration of the accounting architecture is
   done as part of the user configuration of the service equipment.
   Accounting policies are defined as part of the contractual agreement.
   The ASM converts the instructions from the AAA server into the
   appropriate user configuration including settings for the accounting
   architecture.

            +---------------------+
   <---1--->|  Generic AAA Server |<---1--->
            |                     |            ............
            |  Rule based engine  |<----|----->:  Policy  :
            |                     |    3|      :..........:
            +---------------------+<----|--+   ............
                        ^                  +-->:  Events  :
                        |                      :..........:
                        2
                        |
                        V
            +----------------------+       ...............
            | Application specific |<--3-->: Acct Policy :
            |         Module       |       :.............:
            +----------------------+
                        ^
                        |
                        5
                        |
                        V
         +-------------------------------------+
         | Service                             |
         | +-----------+    +----------------+ |     ..............
         | | Service   |<-->|  Accounting/   |<--3-->: Accounting :
         | | Provision |    |  Metering      | |     : Data       :
         | +-----------+    +----------------+ |     :............:
         +-------------------------------------+

   Figure 5: AAA Server with Integrated Accounting

   Data about the resource consumption is sent back to the AAA server
   via the ASM.  The accounting process within the service converts the
   metered data into accounting records which are sent to the AAA
   server.  For generating accounting records data conversion,
   aggregation and filtering of data might be performed.







Zseby, et. al.                Experimental                     [Page 20]

RFC 3334                Policy-Based Accounting             October 2002


7.2 Discrete Accounting

   In contrast to the integrated accounting approach, accounting can
   also be seen as a separate or discrete service on its own.  In this
   case the accounting does not have to be coupled with a specific
   service.  Discrete Accounting can be used for outsourcing the
   accounting task.  The accounting service can be provided by a general
   accounting system which is able to account for different services.

   For example, a generalized meter can do accounting for web traffic,
   FTP traffic and voice over IP traffic.  If accounting is a separate
   service, one provider can do the accounting (charging and billing)
   for several other service providers.  Accounting is offered just like
   any other service.  This means authentication and authorization might
   be required prior to the accounting service provisioning.
   Furthermore, it is important that the involved parties agree
   beforehand how the accounting service is provided, what parameters
   can be set and how disputes will be resolved.  After the accounting
   service has been configured, the AAA server can do the user
   configuration of the service.

            +---------------------+
   <---1--->|  Generic AAA Server |<---1--->
            |                     |            ............
            |  Rule based engine  |<----|----->:  Policy  :
            |                     |    3|      :..........:
            +---------------------+<----|--+   ............
                ^             ^            +-->:  Events  :
                |             |                :..........:
                2             2
                |             |
                V             V
        +-------------+    +--------------+       ...............
        | Application |    | Application  |<--3-->: Acct Policy :
        | Specific    |    | Specific     |       :.............:
        | Module      |    | Module       |
        +-------------+    +--------------+
               ^                  ^
               |                  |
               5                  5
               |                  |
               V                  V
        +-------------+    +---------------+       ..............
        |  Service    |    |  Accounting/  |<--3-->: Accounting :
        |             |    |  Metering     |       : Data       :
        +-------------+    +---------------+       :............:

   Figure 6: AAA Server with Discrete Accounting



Zseby, et. al.                Experimental                     [Page 21]

RFC 3334                Policy-Based Accounting             October 2002


   A service provider that has outsourced the accounting service has to
   request this service from an accounting service provider.  The
   generated accounting records are sent from the accounting provider to
   the service provider who may make modifications to the records before
   sending them to the final destination.  Having such a general
   accounting service might speed up the creation of new services -
   especially specialized content services - in the Internet.  This
   separation is also beneficial to support special accounting services
   (e.g. sending accounting indications to users) that are not directly
   coupled to a network service.  Furthermore, this separation is useful
   if the same set of accounting strategies can be applied to different
   services (e.g. different tariffs which can be used for a set of
   services).

   Another option is to outsource only the metering service.  The meter
   service provider generates meter data and sends them to the service
   provider who has requested them.  The service provider then generates
   accounting records based on the received meter data.  A separate
   accounting or metering service provider can be used to validate the
   accounting data generated by a service provider.  If the customer
   does not trust a service provider, or in the case of a legal action,
   a trusted accounting or metering provider is able to validate the
   correctness of the accounting data generated by the service provider.

7.3 Intra-Domain Accounting

   In Intra-Domain accounting [RFC2975], the data about resource
   consumption is collected in one administrative domain for usage in
   that domain.  Accounting policies are enforced locally.  Since no
   exchange of accounting data with other domains is required in this
   scenario, accounting policies do not need to be exchanged with other
   entities.



















Zseby, et. al.                Experimental                     [Page 22]

RFC 3334                Policy-Based Accounting             October 2002


                                +-------------+
                                |   Billing   |
                                +-------------+
                                        ^
                                        |
                                +-------------+
                                |     ASM     |
                                +-------------+
                                        ^
                                        |            ..............
                                +--------------+     : Accounting :
                                |    AAA       |<--->: Policies   :
                                +--------------+     :............:
                                     |      ^
                                     |      |
                                     V      |
                                +--------------+
                                |     ASM      |
                                +--------------+
                                     |      ^
                              config |      | Accounting Records
                                     V      |
   +------------+               +-----------|----------+
   |            | Service usage |  +--------+-------+  |
   | End System |-------------->|  | Accounting     |  |
   |            |               |  +----------------+  |
   +------------+               |                      |
                                |  Service             |
                                +----------------------+
        User                            Provider

   Figure 7: Intra-Domain Accounting

7.4 Inter-Domain Accounting

   For Inter-Domain Accounting, at least two administratively separated
   networks are involved in the accounting process.  These can be a
   Home- and a Foreign-Provider in a Roaming/Mobile IP Scenario
   [RFC2002] or a chain of providers if service provisioning involves
   data transfer and/or services from different domains.  In these
   scenarios, the exchange of accounting policies between providers is
   necessary if accounting tasks are delegated to one provider or shared
   among multiple providers.  The exchange of accounting policies is
   done by the AAA servers as shown in the figure below.







Zseby, et. al.                Experimental                     [Page 23]

RFC 3334                Policy-Based Accounting             October 2002


                                                    |     +-----------+
                                                    |     |  Billing  |
                                                    |     +-----------+
                                                    |           ^
                                                    |           |
                                                    |     +-----------+
                                                    |     |    ASM    |
                                                    |     +-----------+
                                                    |           ^
                                                    |           |
                        +------------------+ 1. AccPolInd +-----------+
                        |                  |<-------------|           |
                        |                  |        |     |           |
                        |     AAAF         | 2.AccPolConf |   AAAH    |
                        |                  |------------->|           |
                        |                  |        |     |           |
                        |                  | 3. AccRec    |           |
                        |                  |------------->|           |
                        +------------------+        |     +-----------+
                    config  |       ^               |           ^
                            |       |               |           |
                            V       |               |           V
                        +--------------+            |     .............
                        |     ASM      |            |     : Acct.     :
                        +--------------+            |     : Policies  :
                            |       ^               |     :...........:
                            |       |               |
                            |       | Acct. Records |
                 Service    V       |               |
   +------------+ usage +-----------|----------+    |
   |            |       |  +--------+-------+  |    |
   | End System |------>|  | Accounting     |  |    |
   |            |       |  +----------------+  |    |
   +------------+       |                      |    |
                        |  Service             |    |
                        +----------------------+    |

        User                   Foreign-Provider         Home-Provider

   Figure 8: Inter-Domain Accounting (Roaming Example)

   In this example, the foreign provider takes over the collection of
   accounting data.  The home provider is responsible for applying a
   charging scheme and sending the bill.  Therefore, the home provider
   needs accounting data from the foreign provider.  In order to
   instruct the foreign provider about the desired accounting record
   type and report frequency, the home AAA server sends an accounting
   policy indication to the foreign AAA server.  The indication contains



Zseby, et. al.                Experimental                     [Page 24]

RFC 3334                Policy-Based Accounting             October 2002


   the accounting policy.  Instead of sending an indication, the
   accounting policies could also be piggy backed onto an authorization
   reply.  If the foreign AAA server is able to configure devices in a
   way to enforce the desired policy (e.g. the meters are capable of
   metering the requested attributes) the accounting policy indication
   is acknowledged.  In case the requested policy cannot be enforced,
   the accounting service is denied.  Reasons to deny the enforcement of
   a specific accounting policy could be, e.g. because the meter is not
   capable of measuring the requested attributes or the frequency of
   records cannot be provided, or the home provider is not authorized to
   get the requested detailed data.  In this case procedures would be
   useful to negotiate the smallest common denominator for the involved
   AAA servers regarding the provisioning of accounting data.

8. Accounting with different Authorization Models

   The AAA authorization framework [RFC2904] introduces different
   message sequences for authorization.  The integration of configurable
   accounting services for the message sequences can be done as
   described in the following sections.

8.1 Agent Sequence

   The appropriate accounting policy for the authorized service is
   either stored together with the authorization policy or in a separate
   repository.  The configuration of the accounting infrastructure can
   be done together with the user configuration of the service equipment
   (messages 2 and 3 in Figure 9).  User-specific configuration of the
   service equipment and the accounting infrastructure configuration
   might involve the transfer of configuration data to multiple entities
   in the network (e.g. to different routers for setting up QoS
   provisioning or to dedicated accounting meters).



















Zseby, et. al.                Experimental                     [Page 25]

RFC 3334                Policy-Based Accounting             October 2002


                             +-------------------------+
               +------+      | Service Provider        |
               |      |   1  |  +-------------------+  |
               |      |------+->|    AAA Server     |  |
               |      |<-----+--|                   |  |
               |      |   4  |  +-------------------+  |
               | User |      |       |   ^    ^        |
               |      |      |       |2  |3   |AcctRec |
               |      |      |       V   |    |        |
               |      |      |  +-------------------+  |
               |      |      |  |      Service      |  |
               |      |      |  |     Equipment     |  |
               |      |      |  +-------------------+  |
               +------+      |                         |
                             +-------------------------+

   Figure 9: Accounting and Agent Sequence

   In the agent sequence, it is possible to allow the user to send
   accounting policies (e.g. for accounting indications) together with
   the authorization request to the AAA server.  Figure 9 shows the
   agent sequence authorization and accounting messages.

8.2 Pull Sequence

   The configuration of the accounting infrastructure can be done
   similar to the agent sequence during the user configuration of the
   service equipment.  Since the pull sequence does not involve the
   sending of a specific authorization request (e.g. if the service
   equipment is a Network Access Server (NAS) and the authorization
   sequence simply starts with the dial-in process), it would need
   additional communication to support accounting policy indications
   from users.


















Zseby, et. al.                Experimental                     [Page 26]

RFC 3334                Policy-Based Accounting             October 2002


                              +-------------------------+
               +------+       | Service Provider        |
               |      |AccPolInd +-------------------+  |
               |      |.........>|    AAA Server     |  |
               |      |<.........|                   |  |
               |      |       |  +-------------------+  |
               | User |       |       ^   |   ^         |
               |      |       |       |2  |3  |AcctRec  |
               |      |       |       |   V   |         |
               |      |   1   |  +-------------------+  |
               |      |-------+->|      Service      |  |
               |      |<------+--|     Equipment     |  |
               |      |   4   |  +-------------------+  |
               +------+       |                         |
                              +-------------------------+

   Figure 10: Accounting and Pull Sequence

   This can be, for instance, achieved by a hybrid model of agent and
   pull sequence where the user sends an accounting policy indication to
   the AAA server in addition to the messages exchange for the pull
   sequence.  Figure 10 shows the pull sequence authorization and
   accounting messages.

8.3 Push Sequence

   In the push sequence, there is no direct connection between the AAA
   server and the service equipment.  In this sequence there are three
   possibilities for setting up the accounting infrastructure:

   a) A standard fixed accounting procedure that has been assigned in
   advance for the specific combination of authorized user and service
   is used.

   b) The ticket (message 3 in Figure 11) contains information about the
   accounting policies used (e.g. different tickets for the same service
   with different accounting policies).

   c) The ticket acts as a kind of digital coin and no further
   accounting is needed.  This model also supports the anonymous usage
   of a service.










Zseby, et. al.                Experimental                     [Page 27]

RFC 3334                Policy-Based Accounting             October 2002


   Figure 11 shows push sequence authorization and accounting messages.

                               +-------------------------+
                 +------+      | Service Provider        |
                 |      |   1  |  +-------------------+  |
                 |      |------+->|    AAA Server     |  |
                 |      |<-----+--|                   |  |
                 |      |   2  |  +-------------------+  |
                 | User |      |              ^          |
                 |      |      |              | AcctRec  |
                 |      |      |              |          |
                 |      |   3  |  +-------------------+  |
                 |      |------+->|      Service      |  |
                 |      |<-----+--|     Equipment     |  |
                 |      |   4  |  +-------------------+  |
                 +------+      |                         |
                               +-------------------------+

   Figure 11: Accounting and Push Sequence

8.4 Roaming

   If the provisioning of the service and the final authentication/
   authorization process is done by different organizations, accounting
   is rather coupled to the service provisioning process than to the
   authentication/authorization process.  Since the data doesn't have to
   traverse the home providers network, the home provider has no
   possibility of collecting data about the resource consumption.
   Therefore, accounting will usually take place in the foreign provider
   domain (i.e. in the domain that does the service provisioning).
   Nevertheless, in order to ensure consistency of the authentication,
   authorization and accounting processes (e.g. allocation of user IDs
   to accounting records) and the production of a bill, a connection
   between the accounting process in the service provisioning domain and
   the deciding authentication/authorization process (e.g. at the home
   provider) is needed.

   A possible way of doing this is if the foreign provider gets the
   accounting policies from the home provider and sets up the accounting
   architecture in accordance to the given policies, the foreign
   provider can generate accounting records and send them back to the
   home provider.  The home provider then can apply charging and can
   produce a bill.  An example for this is given in section 9.2.  This
   scenario requires a prior agreement between the involved providers
   about the possible policies and parameters that are allowed to be
   set.





Zseby, et. al.                Experimental                     [Page 28]

RFC 3334                Policy-Based Accounting             October 2002


9. Examples

   The following examples illustrate the use of policy-based accounting.
   Please note that the services used in the examples are used only for
   illustration purposes and their use in reality requires different
   messages and parameters.

9.1 Printing Service Example

   The Internet Printing Protocol (IPP) [RFC2566], and especially the
   "print-by-reference" model, provides a very interesting example
   scenario for accounting and the interaction between authorization and
   accounting.  We will describe possible solutions for the accounting
   of this service and how the accounting is triggered by the
   authorization.  We will show how the model presented above can be
   used for this example.

   IPP "print-by-reference" allows a user to request a print service to
   print a particular file.  The file to be printed is not on the client
   system but rather on a public server.  That is, the clients print
   request can contain a reference, or pointer, to the document instead
   of the actual document itself.  The print service must then read the
   file to a file server (used for spooling) prior to the printing.
   There are two possible setups: The file and print server either
   belong to a single organization (Intra-Domain Accounting) or to two
   different organizations (Inter-Domain Accounting).  In the first
   case, the user must be authorized by a single service provider for
   service usage.  In the second case, two different possibilities for
   establishing a trust relationships between the involved entities have
   to be distinguished [RFC2905].

9.1.1   Intra-Domain Accounting

   In the case of a single organization, the file and print service is
   provided by a single service provider.  The service subscriber and
   user role are either one entity (e.g. private home user) or different
   entities (e.g. company as subscriber, employee as user).  For data
   transport via the underlying network, the transportation service of a
   network provider is used.  In this case, the AAA server of the
   provider controls the access to the file and the print server.  This
   means the AAA server enforces the accounting policies and collects
   accounting data for both servers.









Zseby, et. al.                Experimental                     [Page 29]

RFC 3334                Policy-Based Accounting             October 2002


9.1.2   Inter-Domain Accounting

   If two different organizations are involved there are two
   possibilities for trust relationships as shown in [RFC2905]:

   1. The user has an agreement with the print server; the print
      server has an agreement with the file server.
   2. The user has agreements with both print and file server.

   In case 1, the user is first authorized by the print service and the
   request is forwarded to the file server.  The file server authorizes
   the print server and determines if the printer is allowed to access
   the file.  In this case which is shown in Figure 12, the accounting
   policies from the user arrive at the print service AAA server.

    USER DOMAIN     PRINT SERVICE DOMAIN         FILE SERVICE DOMAIN
                |                            |
     +------+   |                            |
     |      |   |                            |
     |      |   |                            |
     |      |   |   +--------------------+   |   +-------------------+
     | User |---1-->| Print Service      |---1-->| File Service      |
     |      |<--2---| AAA Server         |<--2---| AAA Server        |
     |      |   |   +--------------------+   |   +-------------------+
     |      |   |   | Print Server       |   |   | File Server       |
     |      |   |   |  and Printer       |   |   |                   |
     +------+   |   +--------------------+   |   +-------------------+

     1: AccPolInd, 2: AccPolConf

   Figure 12: Inter-Domain Accounting and Printing Service

   The print service AAA server has to decide which policies can be
   enforced locally and which must be passed further to the file service
   AAA server.  The print service can add additional accounting
   policies.  In case the file server does not support the desired
   accounting policies, the print server must notify the user's AAA
   server and some policy conflict resolution must occur.  After the
   file server has transferred the file to the print service, it
   generates an accounting record according to the accounting policy and
   passes it to the print service.  The print service generates the
   final accounting record for the service session based on its own and
   the file service data after finishing printing.  This record will be
   used for the later billing process.  Additionally, the print server
   can send the final record to the user's AAA server.  There it can be
   used for later authorization decisions based on used resources, i.e.
   if the customer is a company and the user is an employee.




Zseby, et. al.                Experimental                     [Page 30]

RFC 3334                Policy-Based Accounting             October 2002


   In case 2, the customer AAA server has an agreement with file and
   print server.  In this case, the user's AAA server sends accounting
   policies to the file and the print server.  After finishing the
   service, both servers generate accounting records for the delivered
   services which are used for later billing.  As in the former case,
   the accounting data can be sent to the user's AAA server for use in
   later authorization decisions.  The user's AAA server can tie both
   accounting records together and assign them to the user using audited
   session information (authorization and accounting messages for a
   particular session could be coupled via a session ID) and policies
   that define which activities a certain session is composed of.

9.1.3   User Accounting Indication

   For the printing service, there are a number of possible options for
   sending accounting indications to the user.  Accounting indications
   give the user an indication of how much resources have been used
   until the time of the indication.  A user can receive accounting
   indications or not depending on the accounting policy for the user.

   For Internet printing with the "print-by-reference" model, such
   indications would be very helpful for the user.  Since the file is
   not on the clients site, the user might not have information on the
   file size or the number of pages that will be printed.  This means
   the user has no idea of the costs of the service usage.  If user and
   subscriber are a single entity, accounting indications would help
   users to avoid exceeding their spending limit.  Additionally,
   accounting indications give the user a hint as to which resource
   usage has caused the charges.  This can be compared to an itemized
   telephony bill where not only the monetary sum per month is printed
   but, in addition, information for every call (start time, duration,
   distance etc.) and its corresponding charge.

9.2 Mobile/Roaming Example

   In this section, the "Dial-in with Roaming" example from the
   authorization examples [RFC2905], [RFC2002] is used to show how
   accounting functions could interact with authorization functions.
   The accounting modules (e.g. collectors and meters) are seen here as
   part of the service equipment which is, in this example, located at
   the visited ISP premises.  The basic configuration of the accounting
   modules is probably done by the visited ISP itself, but the visited
   ISP can allow the home ISP to influence certain parameters (like
   report interval or accounting record format).  This is useful if the
   home provider generates the invoice and therefore needs appropriate
   accounting records to calculate the prices.





Zseby, et. al.                Experimental                     [Page 31]

RFC 3334                Policy-Based Accounting             October 2002


      User |         Visited ISP           |        Home  ISP
           |                               |
           |                               |  +-----------+  ..........
    <--------------------12-------------------| Charging, |<-:charging:
           |                               |  | Billing   |  :policies:
           |                               |  +-----------+  :........:
           |                               |        ^
           |                               |        |
           |                               |  +-----------+
           |                               |  |    ASM    |
           |                               |  +-----------+
           |                               |        ^
           |                               |        |11
           |                               |        |
           |          +------------+       |  +-------------+
           |          |            |       |  |             |
           |          |            |---10---->|             |
           |          |            |       |  |             |
       Acct. Records  | AAAF Server|----3---->| AAAH Server |
    <-----------------|            |<---4-----|             |
           |          |            |       |  |             |
           |          |            |       |  |             |
           |          +------------+       |  +-------------+
           |           ^  |      ^         |
           |           |  |      |         |
           |           |  5      9         |
           |           |  |      |         |
           |           |  V      |         |
           |           | +----------------+|
           |           | |     ASM        ||
           |           2 |                ||
           |           | +----------------+|
           |           |  |      ^         |
           |           |  |      |         |
           |           |  6      8         |
           |           |  |      |         |
           | +------------+------+-------+ |
        7  | |  Service   |      |       | |
    <--------| Equipment  |  +----------+| |
        1  | |            |->|Accounting|| |
    -------->|            |  +----------+| |
           | |     config |      |       | |
           | |            |  +---------+ | |
           | |            +->| Meters  | | |
           | |               +---------+ | |
           | +---------------------------+ |
           |                               |
   Figure 13: Roaming Example



Zseby, et. al.                Experimental                     [Page 32]

RFC 3334                Policy-Based Accounting             October 2002


   The exchange of authorization data corresponds to the example in
   [RFC2905].  As an additional component, we introduce an ASM between
   home AAA and service equipment for the user configuration which
   happens after successful authorization.  The extended roaming example
   is shown in Figure 13.  Steps (1), (2) and (3) describe the
   forwarding of an authentication/authorization request from the user
   via the AAA sever of the visited ISP to the home AAA server.  In step
   (4), user specific service parameters are given to the visited ISP's
   AAA server and are forwarded to the service equipment (5) where the
   user configuration is done.  The user-specific service parameters
   could additionally include the desired policies for the configuration
   of the accounting infrastructure of the visited ISP.  An accounting
   policy could be, for instance, "for user X one accounting record of
   type Y has to be generated every 30 seconds".  This accounting policy
   is used by the visited ISP to configure his modules (e.g. metering,
   data collection).

   User-dependent service parameters are converted by the ASM into the
   appropriate configuration information (6).  Then the user is informed
   about the completed authentication/authorization process (7).  The
   accounting architecture starts metering the resource usage and sends
   metering records to the ASM (8).  The ASM uses the metered data to
   fill the required accounting records and sends them to the visited
   ISP's AAA server (9).  The visited ISP can either post-process the
   data or directly forward them to the home ISP (10).  With this data
   as input, an invoice is generated by the charging and billing modules
   within the home providers domain (11) by using charging policies
   (tariff formulas), and then sent to the user/customer (12).

   As an additional option, accounting records can also be offered to
   the user (accounting indication) as a special service.  For this
   special service a separate authorization is required.

9.3 Diffserv Example

   This example explains how integrated accounting is configured via
   policies for a Diffserv service [RFC2475] based on bandwidth brokers
   [I2-BB].  The service is the transport of packets with a higher
   priority and the service includes accounting and QoS auditing.
   Figure 14 shows the service setup.  The user issues a Service Request
   (SR) for a Diffserv service to the AAA server.  The request contains
   a user ID and the parameter for the desired service class.

      User->AAA: user-x@nw-a, service=diffserv, class=gold,
                 amount=2Mbit, dest= nw-b






Zseby, et. al.                Experimental                     [Page 33]

RFC 3334                Policy-Based Accounting             October 2002


   In this example, user-x is located at network A (nw-a) and requests a
   gold class service for all flows from this network to the destination
   network B (nw-b).  After authentication and authorization has been
   completed successfully, the AAA server extracts the ASI from the
   request and passes them to the ASM of the Diffserv service.

      AAA->ASM: service=diffserv, class=gold, amount=2Mbit, src=nw-a
                dest=nw-b

   The ASM takes over the task of translating the application specific
   information into appropriate user configuration information for the
   service equipment.  For the given Diffserv example, the service
   equipment consists of three components: accounting equipment, the QoS
   auditing equipment and the bandwidth broker architecture.  The ASM
   has to address all three components to set up the requested service
   for the user.  The translation of the ASI into configuration
   information for the components can be done by evaluating service
   provisioning policies.  For example, the ASM could have the following
   service provisioning policy:

           if class==gold {
             set bw-request.class = gold
             set accounting.type = comprehensive
             set qos-audit.metric = one-way-delay
             ...
           }

   This results in sending a bandwidth request to the BB which asks for
   a gold service with the given parameters.  Furthermore, the ASM
   issues a request to the accounting equipment for comprehensive
   accounting and a request to the QoS auditing equipment for a one-
   way-delay measurement between the given networks.

   ASM->BB: BW-request(gold, src=nw-a, dest=nw-b, amount=2Mbit)

   ASM->Acct: Acct-request(comprehensive, src=nw-a)

   ASM->QoS: QoS-audit-request(one-way-delay, src=nw-a, dest=nw-b)

   The bandwidth broker then sets up the Diffserv infrastructure to
   provide the prioritized forwarding according to the definition of a
   gold class.  This is done in accordance with the actual bandwidth
   broker's architecture and is not further considered here.  For the
   Accounting Configuration and the QoS Audit Control, local
   configuration policies exist for setting up the service.






Zseby, et. al.                Experimental                     [Page 34]

RFC 3334                Policy-Based Accounting             October 2002


      Accounting-Policy:
                if type==comprehensive {
                  set meter-location = access-point(nw-a)
                  set record type =detailed
                  set report interval = 120 s
                  set report target = 193.175.12.8
                  ^ indent of last two lines
                 }

      QoS-Measurement-Policy:
                  if metric==one-way-delay {
                    set method = passive
                    set timestampsize = 48 bit
                    set ingress-meter-location = access-point(nw-a)
                    set egress-meter-location = access-point(nw-b)
                   }

   In this case, the local accounting policy sets the meter location to
   the network access point of network A.  It states that for
   comprehensive accounting, a detailed record type is required with a
   report interval of 120 s.  The resulting records have to be sent to
   the given report target.  The QoS measurement policy sets the
   measurement method to passive measurement.  It sets the size used for
   timestamp representation to 48 bits.  As meter locations, the meters
   at the access points of network A and network B are used.

   After evaluating these policies, the instructions for the meter
   configuration are passed down to the measurement infrastructure.  In
   our example, the accounting configuration instructs the meter at the
   first measurement point (MP1) to add a new rule with the given flow
   attributes and settings for storage and reporting of results.




















Zseby, et. al.                Experimental                     [Page 35]

RFC 3334                Policy-Based Accounting             October 2002


      Acct->MI: MP1: add rule dscp=23, src=a.a.a/24, dest=b.b.b.b/24
                     save volume
                     set report interval = 120 s
                     set report target = 193.175.12.8

              SR          +-------+
   User ----------------->|  AAA  |
                          +-------+
                              |
                              | ASI
                              V
                          +-------+
        +-----------------|  ASM  |--------------+--------------+
        |       Policy    +-------+  Policy      |   BW Request |
        |       Parameters           Parameters  |              |
        |                                        |              |
   -----|----------------------------------------|--------------|-----
        |       Service Equipment                |              |
        V                                        V              V
   +---------------+    ..............    +-----------+   +-----------+
   | Accounting    |<-->: Local      :<-->| QoS       |   | Bandwidth |
   |               |    : Policies   :    | Auditing  |   | Broker    |
   +---------------+    :............:    +-----------+   +-----------+
        |                                        |
        | Meter Instructions                     | Measurement Setup
        V                                        V
   +--------------------------------------------------+
   |  Measurement                                     |
   |  Infrastructure                                  |
   +--------------------------------------------------+

   Figure 14: Diffserv Service Provision Setup

   The QoS audit control instructs two meters (at MP1 and MP2) to set up
   a passive one-way-delay measurement.

      QoS->MI: MP1: add rule dscp=23, src=a.a.a.a/24 dest=b.b.b.b/24,
                    save timestamp-48
               MP2: add rule dscp=23, src=a.a.a.a/24, dest=b.b.b.b/24,
                    save timestamp-48











Zseby, et. al.                Experimental                     [Page 36]

RFC 3334                Policy-Based Accounting             October 2002


9.4 User Accounting Indication Example

   This example explains how discrete accounting can be used to provide
   accounting indications for the user.  Accounting indications are sent
   to the user in order to inform the user about current resource
   consumption.  The accounting indication is a special accounting
   service that can be provided in addition to the standard accounting
   performed by the provider.  Like for any other service, an
   authorization should take place before the accounting indication
   service provisioning.  Therefore, the accounting here is seen as a
   separate service.  That means the accounting service is independent
   of the main service and therefore can be applied to different
   services.  It might be used as an addition to an integrated
   accounting that is part of the service.  The authorization process
   for the accounting service is out of the scope of this document and
   therefore is not further explained here.

   Figure 15 illustrates the configuration message sequence for setting
   up the accounting service.  First, the user sends an Accounting
   Service Request (ASR) to the AAA server which includes desired
   parameters for the provisioning of the accounting service (e.g.
   report interval).

      user->AAA: user-x@nw-a, service= accounting indications,
                 report interval= 60 s

   The AAA server passes the ASI to the ASM of the accounting service
   after the user has been authenticated and authorized for the service
   usage.

      AAA->ASM: user-x@nw-a, service=accounting indications,
                report interval= 60 s



















Zseby, et. al.                Experimental                     [Page 37]

RFC 3334                Policy-Based Accounting             October 2002


   The ASM generates an accounting policy based on the ASI and passes
   this policy to the Accounting Configuration.

   ASM->Acct: If src=a.a.a.x {
                acc-indication = on
                report interval = 60s
                report target= a.a.a.x
              }

              ASR       +-------+
   User --------------->|  AAA  |
                        +-------+
                            |
                            | ASI
                            V
                        +-------+
                        |  ASM  |
                        +-------+
                            |
   -------------------------|---------------------------
   Service Equipment        | Accounting Policy
                            V
                    +-----------------+      ..............
                    |  Accounting     |<---->: Local Acct :
                    |                 |      : Policies   :
                    +-----------------+      :............:
                            |
                            | Meter Instructions
                            V
                    +-----------------+
                    |  Measurement    |
                    |  Infrastructure |
                    +-----------------+

   Figure 15: Accounting Indication Configuration

   The Accounting Configuration generates meter instructions according
   to the accounting policies from the ASM and local accounting policies
   and passes them to the measurement infrastructure.

      local Acct-Policy: if acc-indication {
                          record type = compact
                         }

      Acct->MI: MP1: set report interval = 60 s
                     add report target = a.a.a.x





Zseby, et. al.                Experimental                     [Page 38]

RFC 3334                Policy-Based Accounting             October 2002


10. Security Considerations

   Accounting services provide the basis for billing.  Therefore, the
   incentives (mainly saving money) and potential for fraud is extremely
   high in the field of configuration of the accounting architecture and
   the collection of accounting data.  In the presented framework, two
   types of data communications are required, the exchange of accounting
   policies and the collection of accounting records.  Both
   communications introduce potential security hazards.

   The following potential security hazards can be identified:

   - Forgery of accounting policies and accounting record information
   Both accounting policies and accounting records can be the target of
   forgery of information.  Accounting policies contain configuration
   information.  Modifying this information can lead to a mal-configured
   accounting and metering system which either allows data to traverse
   the accounting system undetected (without being accounted for, e.g.
   by changing the classification rules of a meter) or produces bogus
   accounting records.  Accounting records contain data about resource
   consumption and provide the basis for billing.  Modifying accounting
   records may lead to erroneous bills.  Furthermore, it is important
   that policies or accounting records are not redirected or removed and
   that forged policies or records are not inserted.

   - Eavesdropping
   It may be required to keep accounting policies and accounting records
   confidential between the involved parties.

   - Denial of Service (DoS) attacks
   Both the AAA server and the accounting/metering subsystem can be the
   target of denial of service attacks.  A denial of service attack
   against the AAA server may lead to malfunction and even breakdown of
   the server.  This means the server will not be able to provide proper
   authentication, authorization and accounting functionality.  The
   service provided by the AAA server will become unavailable or
   unusable.  An attack to the server can be worse than an attack to the
   service equipment itself, especially if multiple services use one AAA
   server.  An attack against the accounting/metering system will cause
   loss of metering data and/or loss of accounting records.

   This leads to the following security requirements:

   - Secrecy of accounting policies and accounting data
   Unauthorized entities should not be able to read or modify accounting
   policies or accounting records.  This can be achieved with standard
   encryption methods.




Zseby, et. al.                Experimental                     [Page 39]

RFC 3334                Policy-Based Accounting             October 2002


   - Authentication of accounting data and accounting policy sources
   It should be ensured that the data is originated by the original
   source.  Source-authentication can be achieved by using digital
   signatures.

   - Protection of the integrity of accounting policies and records
   It should be ensured that the data was not modified on the way from
   sender to receiver.  Data-authentication can also be achieved with
   digital signatures.

   - Verify correctness of generated accounting data
   It must be ensured that the accounting data generated by the service
   provider is correct.  A provider may generate incorrect accounting
   records either deliberately (i.e. forging) or unintentionally (e.g.
   faulty configuration).  These incorrect accounting records probably
   have the consequence of incorrect bills.  Customers can verify the
   correctness of the accounting data through their measurements and/or
   through data collected by a trusted third party.  A trusted third
   party can be an independent accounting service provider as described
   in section 7.2 or a more general entity providing an auditing
   service.

   - Prevention and protection against Denial of Service attacks
   The AAA protocol and all building blocks should be designed and
   implemented in a way as resistant as possible to denial of service
   attacks.  An additional strategy to defend against DoS attacks is to
   add a component to the meter system that is able to detect suspicious
   traffic patterns.  Upon detection, further actions can be taken
   according to a pre-defined policy.

   The prevention of these hazards has to be considered for the
   protocols used for accounting policy exchange and the transportation
   of accounting records.  Since the security requirements for
   authentication, transmission level security, data object
   confidentiality and integrity are addressed in the criteria for AAA
   protocol evaluation [RFC2989], we assume that the future AAA
   protocol(s) will be suited for secure accounting record transfer and
   probably also for secure accounting policy transport.  Furthermore,
   we assume that existing or upcoming solutions for secure
   transportation and enforcement of policies can be used.  Real
   prevention of DoS attacks is quite difficult.  A selective dropping
   of the attackers packets is impossible if the malicious packets
   cannot be separated from the valid customer traffic.  Dropping of all
   packets of a certain type may prevent authorized customers from using
   the service and therefore help the attacker to achieve her goal.






Zseby, et. al.                Experimental                     [Page 40]

RFC 3334                Policy-Based Accounting             October 2002


11. References

   [I2-BB]     Internet2-QBone Bandwidth Broker,
               http://www.merit.edu/working.groups/i2-qbone-bb

   [NetFlow]   NetFlow Services and Applications, White Paper, Cisco
               Systems, 1999

   [RFC2002]   Perkins, C., "IP Mobility Support", RFC 3220, October
               1996.

   [RFC2123]   Brownlee, N., "Traffic Flow Measurement: Experiences with
               NeTraMet", RFC 2123, March 1997.

   [RFC2475]   Blake, S., Black, D., Carlson, M., Davies, E., Wang Z.
               and W. Weiss, "An Architecture for Differentiated
               Services", RFC 2475, December 1998.

   [RFC2566]   DeBry, R., "Internet Printing Protocol/1.0: Model and
               Semantics", RFC 2911, April 1999.

   [RFC2722]   Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow
               Measurement:  Architecture", RFC 2722, October 1999.

   [RFC2903]   de Laat, C., Gross, G., Gommans, L., Vollbrecht, J. and
               D. Spence, "Generic AAA Architecture", RFC 2903, August
               2000.

   [RFC2904]   Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
               Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and
               D. Spence, "AAA Authorization Framework", RFC 2904,
               August 2000.

   [RFC2905]   Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
               Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and
               D. Spence, "AAA Authorization Application Examples", RFC
               2905, August 2000.

   [RFC2924]   Brownlee, N. and  A. Blount, "Accounting Attributes and
               Record Formats", RFC 2924, September 2000.

   [RFC2975]   Aboba, B., Arkko, J. and D. Harrington, "Introduction to
               Accounting Management", RFC 2975, October 2000.








Zseby, et. al.                Experimental                     [Page 41]

RFC 3334                Policy-Based Accounting             October 2002


   [RFC2989]   Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann,
               P., Shiino, H., Walsh, P., Zorn, G., Dommety, G.,
               Perkins, C., Patil, B., Mitton, D.,  Manning, S.,
               Beadles, M., Chen, X., Sivalingham, S., Hameed, A.,
               Munson, M., Jacobs, S., Lim, B., Hirschman, B., Hsu, R.,
               Koo, H., Lipford, M., Campbell, E., Xu, Y., Baba, S. and
               E. Jaques, "Criteria for Evaluating AAA Protocols for
               Network Access", RFC 2989, November 2000.

   [RFC3198]   Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
               M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
               J. and S. Waldbusser, "Terminology for Policy-Based
               Management", RFC 3198, November 2001.

12. Acknowledgments

   The authors would like to thank the members of the AAAARCH research
   group and in particular, the chairs, John Vollbrecht and Cees de
   Laat, for the fruitful discussions and comments.  Special thanks are
   to Bernard Aboba, Nevil Brownlee and Ed Ellesson for their review and
   valuable input to this document.






























Zseby, et. al.                Experimental                     [Page 42]

RFC 3334                Policy-Based Accounting             October 2002


Author's Addresses

   Tanja Zseby
   Fraunhofer Institute for Open Communication Systems
   Kaiserin-Augusta-Allee 31
   10589 Berlin
   Germany
   Phone: +49-30-34 63 7153
   Fax:   +49-30-34 53 8153
   EMail: zseby@fokus.fhg.de

   Sebastian Zander
   Fraunhofer Institute for Open Communication Systems
   Kaiserin-Augusta-Allee 31
   10589 Berlin
   Germany
   Phone: +49-30-34 63 7287
   Fax:   +49-30-34 63 8287
   EMail: zander@fokus.fhg.de

   Georg Carle
   Fraunhofer Institute for Open Communication Systems
   Kaiserin-Augusta-Allee 31
   10589 Berlin
   Germany
   Phone: +49-30-34 63 7149
   Fax:   +49-30-34 63 8149
   EMail: carle@fokus.fhg.de























Zseby, et. al.                Experimental                     [Page 43]

RFC 3334                Policy-Based Accounting             October 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Zseby, et. al.                Experimental                     [Page 44]