File: rfc2063.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 (2075 lines) | stat: -rw-r--r-- 89,092 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






Network Working Group                                        N. Brownlee
Request for Comments: 2063                    The University of Auckland
Category: Experimental                                          C. Mills
                                            BBN Systems and Technologies
                                                                 G. Ruth
                                                  GTE Laboratories, Inc.
                                                            January 1997


                Traffic Flow Measurement:  Architecture

Status of this Memo

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

Abstract

   This document describes an architecture for the measurement and
   reporting of network traffic flows, discusses how this relates to an
   overall network traffic flow architecture, and describes how it can
   be used within the Internet.  It is intended to provide a starting
   point for the Realtime Traffic Flow Measurement Working Group.

Table of Contents

 1 Statement of Purpose and Scope                                     2
 2 Traffic Flow Measurement Architecture                              4
   2.1 Meters and Traffic Flows . . . . . . . . . . . . . . . . . .   4
   2.2 Interaction Between METER and METER READER . . . . . . . . .   6
   2.3 Interaction Between MANAGER and METER  . . . . . . . . . . .   6
   2.4 Interaction Between MANAGER and METER READER . . . . . . . .   7
   2.5 Multiple METERs or METER READERs . . . . . . . . . . . . . .   7
   2.6 Interaction Between MANAGERs (MANAGER - MANAGER) . . . . . .   8
   2.7 METER READERs and APPLICATIONs . . . . . . . . . . . . . . .   8
 3 Traffic Flows and Reporting Granularity                            9
   3.1 Flows and their Attributes . . . . . . . . . . . . . . . . .   9
   3.2 Granularity of Flow Measurements . . . . . . . . . . . . . .  11
   3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only  . .  13
 4 Meters                                                            15
   4.1 Meter Structure  . . . . . . . . . . . . . . . . . . . . . .  15
   4.2 Flow Table . . . . . . . . . . . . . . . . . . . . . . . . .  17
   4.3 Packet Handling, Packet Matching . . . . . . . . . . . . . .  17
   4.4 Rules and Rule Sets  . . . . . . . . . . . . . . . . . . . .  21
   4.5 Maintaining the Flow Table . . . . . . . . . . . . . . . . .  24
   4.6 Handling Increasing Traffic Levels . . . . . . . . . . . . .  25



Brownlee, et. al.             Experimental                      [Page 1]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


 5 Meter Readers                                                     26
   5.1 Identifying Flows in Flow Records  . . . . . . . . . . . . .  26
   5.2 Usage Records, Flow Data Files . . . . . . . . . . . . . . .  27
   5.3 Meter to Meter Reader:  Usage Record Transmission. . . . . .  27
 6 Managers                                                          28
   6.1 Between Manager and Meter:  Control Functions  . . . . . . .  28
   6.2 Between Manager and Meter Reader:  Control Functions   . . .  29
   6.3 Exception Conditions . . . . . . . . . . . . . . . . . . . .  31
   6.4 Standard Rule Sets   . . . . . . . . . . . . . . . . . . . .  32
 7 APPENDICES                                                        33
   7.1 Appendix A: Network Characterisation . . . . . . . . . . . .  33
   7.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 34
   7.3 Appendix C: List of Defined Flow Attributes  . . . . . . . .  35
   7.4 Appendix D: List of Meter Control Variables  . . . . . . . .  36
 8 Acknowledgments                                                   36
 9 References                                                        37
10 Security Considerations                                           37
11 Authors' Addresses                                                37

1 Statement of Purpose and Scope

   This document describes an architecture for traffic flow measurement
   and reporting for data networks which has the following
   characteristics:

     - The traffic flow model can be consistently applied to any
       protocol/application at any network layer (e.g.  network,
       transport, application layers).

     - Traffic flow attributes are defined in such a way that they are
       valid for multiple networking protocol stacks, and that traffic
       flow measurement implementations are useful in MULTI-PROTOCOL
       environments.

     - Users may specify their traffic flow measurement requirements
       in a simple manner, allowing them to collect the flow data they
       need while ignoring other traffic.

     - The data reduction effort to produce requested traffic flow
       information is placed as near as possible to the network
       measurement point.  This reduces the volume of data to be
       obtained (and transmitted across the network for storage),
       and minimises the amount of processing required in traffic
       flow analysis applications.







Brownlee, et. al.             Experimental                      [Page 2]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   The architecture specifies common metrics for measuring traffic
   flows.  By using the same metrics, traffic flow data can be exchanged
   and compared across multiple platforms.  Such data is useful for:

     - Understanding the behaviour of existing networks,

     - Planning for network development and expansion,

     - Quantification of network performance,

     - Verifying the quality of network service, and

     - Attribution of network usage to users.

   The traffic flow measurement architecture is deliberately structured
   so that specific protocol implementations may extend coverage to
   multi-protocol environments and to other protocol layers, such as
   usage measurement for application-level services.  Use of the same
   model for both network- and application-level measurement may
   simplify the development of generic analysis applications which
   process and/or correlate any or all levels of traffic and usage
   information.  Within this docuemt the term 'usage data' is used as a
   generic term for the data obtained using the traffic flow measurement
   architecture.

   This document is not a protocol specification.  It specifies and
   structures the information that a traffic flow measurement system
   needs to collect, describes requirements that such a system must
   meet, and outlines tradeoffs which may be made by an implementor.

   For performance reasons, it may be desirable to use traffic
   information gathered through traffic flow measurement in lieu of
   network statistics obtained in other ways.  Although the
   quantification of network performance is not the primary purpose of
   this architecture, the measured traffic flow data may be used as an
   indication of network performance.

   A cost recovery structure decides "who pays for what." The major
   issue here is how to construct a tariff (who gets billed, how much,
   for which things, based on what information, etc).  Tariff issues
   include fairness, predictability (how well can subscribers forecast
   their network charges), practicality (of gathering the data and
   administering the tariff), incentives (e.g.  encouraging off-peak
   use), and cost recovery goals (100% recovery, subsidisation, profit
   making).  Issues such as these are not covered here.

   Background information explaining why this approach was selected is
   provided by 'Traffic Flow Measurement:  Background' RFC [1].



Brownlee, et. al.             Experimental                      [Page 3]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


2 Traffic Flow Measurement Architecture

   A traffic flow measurement system is used by network Operations
   personnel for managing and developing a network.  It provides a tool
   for measuring and understanding the network's traffic flows.  This
   information is useful for many purposes, as mentioned in section 1
   (above).

   The following sections outline a model for traffic flow measurement,
   which draws from working drafts of the OSI accounting model [2].
   Future extensions are anticipated as the model is refined to address
   additional protocol layers.

2.1 Meters and Traffic Flows

   At the heart of the traffic measurement model are network entities
   called traffic METERS. Meters count certain attributes (such as
   numbers of packets and bytes) and classify them as belonging to
   ACCOUNTABLE ENTITIES using other attributes (such as source and
   destination addresses).  An accountable entity is someone who (or
   something which) is responsible for some activitiy on the network.
   It may be a user, a host system, a network, a group of networks, etc,
   depending on the granularity specified by the meter's configuration.

   We assume that routers or traffic monitors throughout a network are
   instrumented with meters to measure traffic.  Issues surrounding the
   choice of meter placement are discussed in the 'Traffic Flow
   Measurement:  Background' RFC [1].  An important aspect of meters is
   that they provide a way of succinctly aggregating entity usage
   information.

   For the purpose of traffic flow measurement we define the concept of
   a TRAFFIC FLOW, which is an artificial logical equivalent to a call
   or connection.  A flow is a portion of traffic, delimited by a start
   and stop time, that was generated by a particular accountable entity.
   Attribute values (source/destination addresses, packet counts, byte
   counts, etc.)  associated with a flow are aggregate quantities
   reflecting events which take place in the DURATION between the start
   and stop times.  The start time of a flow is fixed for a given flow;
   the end time may increase with the age of the flow.

   For connectionless network protocols such as IP there is by
   definition no way to tell whether a packet with a particular
   source/destination combination is part of a stream of packets or not
   - each packet is completely independent.  A traffic meter has, as
   part of its configuration, a set of 'rules' which specify the flows
   of interest, in terms of the values of their attributes.  It derives
   attribute values from each observed packet, and uses these to decide



Brownlee, et. al.             Experimental                      [Page 4]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   which flow they belong to.  Classifying packets into 'flows' in this
   way provides an economical and practical way to measure network
   traffic and ascribe it to accountable entities.

   Usage information which is not deriveable from traffic flows may also
   be of interest.  For example, an application may wish to record
   accesses to various different information resources or a host may
   wish to record the username (subscriber id) for a particular network
   session.  Provision is made in the traffic flow architecture to do
   this.  In the future the measurement model will be extended to gather
   such information from applications and hosts so as to provide values
   for higher-layer flow attributes.

   As well as FLOWS and METERS, the traffic flow measurement model
   includes MANAGERS, METER READERS and ANALYSIS APPLICAIONS, which are
   explained in following sections.  The relationships between them are
   shown by the diagram below.  Numbers on the diagram refer to sections
   in this document.

                    MANAGER
                   /       \
              2.3 /         \ 2.4
                 /           \
                /             \                       ANALYSIS
           METER   <----->   METER READER  <----->   APPLICATION
                     2.2                     2.7



  - MANAGER: A traffic measurement manager is an application which
    configures 'meter' entities and controls 'meter reader' entities.
    It uses the data requirements of analysis applications to determine
    the appropriate configurations for each meter, and the proper
    operation of each meter reader.  It may well be convenient to
    combine the functions of meter reader and manager within a single
    network entity.

  - METER: Meters are placed at measurement points determined by
    network Operations personnel.  Each meter selectively records
    network activity as directed by its configuration settings.  It can
    also aggregate, transform and further process the recorded activity
    before the data is stored.  The processed and stored results are
    called the 'usage data.'

  - METER READER: A meter reader reliably transports usage data from
    meters so that it is available to analysis applications.





Brownlee, et. al.             Experimental                      [Page 5]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


  - ANALYSIS APPLICATION: An analysis application processes the usage
    data so as to provide information and reports which are useful for
    network engineering and management purposes.  Examples include:

      -  TRAFFIC FLOW MATRICES, showing the total flow rates for
         many of the possible paths within an internet.

      -  FLOW RATE FREQUENCY DISTRIBUTIONS, indicating how flow
         rates vary with time.

      -  USAGE DATA showing the total traffic volumes sent and
         received by particular hosts.

   The operation of the traffic measurement system as a whole is best
   understood by considering the interactions between its components.
   These are described in the following sections.

2.2 Interaction Between METER and METER READER

   The information which travels along this path is the usage data
   itself.  A meter holds usage data in an array of flow data records
   known as the FLOW TABLE. A meter reader may collect the data in any
   suitable manner.  For example it might upload a copy of the whole
   flow table using a file transfer protocol, or read the records in the
   current flow set one at a time using a suitable data transfer
   protocol.  Note that the meter reader need not read complete flow
   data records, a subset of their attribute values may well be
   sufficient.

   A meter reader may collect usage data from one or more meters.  Data
   may be collected from the meters at any time.  There is no
   requirement for collections to be synchronized in any way.

2.3 Interaction Between MANAGER and METER

   A manager is responsible for configuring and controlling one or more
   meters.  At the time of writing a meter can only be controlled by a
   single manager; in the future this restriction may be relaxed.  Each
   meter's configuration includes information such as:

  - Flow specifications, e.g.  which traffic flows are to be measured,
    how they are to be aggregated, and any data the meter is required
    to compute for each flow being measured.

  - Meter control parameters, e.g.  the maximum size of its flow table,
    the 'inactivity' time for flows (if no packets belonging to a flow
    are seen for this time the flow is considered to have ended, i.e.
    to have become idle).



Brownlee, et. al.             Experimental                      [Page 6]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


  - Sampling rate.  Normally every packet will be observed.  It may
    sometimes be necessary to use sampling techniques to observe only
    some of the packets.  (Sampling algorithms are not prescribed by
    the architecture; it should be noted that before using sampling one
    should verify the statistical validity of the algorithm used).
    Current experience with the measurement architecture shows that a
    carefully-designed and implemented meter compresses the data such
    that in normal LANs and WANs of today sampling is really not
    needed.

2.4 Interaction Between MANAGER and METER READER

   A manager is responsible for configuring and controlling one or more
   meter readers.  A meter reader may only be controlled by a single
   manager.  A meter reader needs to know at least the following for
   every meter is is collecting usage data from:

  - The meter's unique identity, i.e.  its network name or address.

  - How often usage data is to be collected from the meter.

  - Which flow records are to be collected (e.g.  all active flows, the
    whole flow table, flows seen since a given time, etc.).

  - Which attribute values are to be collected for the required flow
    records (e.g.  all attributes, or a small subset of them)

   Since redundant reporting may be used in order to increase the
   reliability of usage data, exchanges among multiple entities must be
   considered as well.  These are discussed below.

2.5 Multiple METERs or METER READERs


                 -- METER READER A --
                /         |          \
               /          |           \
       =====METER 1     METER 2=====METER 3    METER 4=====
                           \           |          /
                            \          |         /
                             -- METER READER B --


   Several uniquely identified meters may report to one or more meter
   readers.  The diagram above gives an example of how multiple meters
   and meter readers could be used.





Brownlee, et. al.             Experimental                      [Page 7]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   In the diagram above meter 1 is read by meter reader A, and meter 4
   is read by meter reader B. Meters 1 and 4 have no redundancy; if
   either fails, usage data for their network segments will be lost.

   Meters 2 and 3, however, measure traffic on the same network segment.
   One of them may fail leaving the other collecting the segment's usage
   data.  Meters 2 and 3 are read by meter reader A and by meter reader
   B.  If one meter reader fails, the other will continue collecting
   usage data.

   The architecture does not require multiple meter readers to be
   synchronized.  In the situation above meter readers A and B could
   both collect usage data at the same intervals, but not neccesarily at
   the same times.  Note that because collections are asynchronous it is
   unlikely that usage records from two different meter readers will
   agree exactly.

   If precisely synchronized collections are required this can be
   achieved by having one manager request each meter to begin collecting
   a new set of flows, then allowing all meter readers to collect the
   usage data from the old sets of flows.

   If there is only one meter reader and it fails, the meters continue
   to run.  When the meter reader is restarted it can collect all of the
   accumulated flow data.  Should this happen, time resolution will be
   lost (because of the missed collections) but overall traffic flow
   information will not.  The only exception to this would occur if the
   traffic volume was sufficient to 'roll over' counters for some flows
   during the failure; this is addressed in the section on 'Rolling
   Counters.'

2.6 Interaction Between MANAGERs (MANAGER - MANAGER)

   Synchronization between multiple management systems is the province
   of network management protocols.  This traffic flow measurement
   architecture specifies only the network management controls necessary
   to perform the traffic flow measurement function and does not address
   the more global issues of simultaneous or interleaved (possibly
   conflicting) commands from multiple network management stations or
   the process of transferring control from one network management
   station to another.

2.7 METER READERs and APPLICATIONs

   Once a collection of usage data has been assembled by a meter reader
   it can be processed by an analysis application.  Details of analysis
   applications - such as the reports they produce and the data they
   require - are outside the scope of this architecture.



Brownlee, et. al.             Experimental                      [Page 8]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   It should be noted, however, that analysis applications will often
   require considerable amounts of input data.  An important part of
   running a traffic flow measurement system is the storage and regular
   reduction of flow data so as to produce daily, weekly or monthly
   summary files for further analysis.  Again, details of such data
   handling are outside the scope of this architecture.

3 Traffic Flows and Reporting Granularity

   A flow was defined in section 2.1 above in abstract terms as follows:

    "A TRAFFIC FLOW is an artifical logical equivalent to a call or
    connection, belonging to an ACCOUNTABLE ENTITY."

   In practical terms, a flow is a stream of packets passing across a
   network between two end points (or being sent from a single end
   point), which have been summarized by a traffic meter for analysis
   purposes.

3.1 Flows and their Attributes

   Every traffic meter maintains a table of 'flow records' for flows
   seen by the meter.  A flow record holds the values of the ATTRIBUTES
   of interest for its flow.  These attributes might include:

  - ADDRESSES for the flow's source and destination.  These comprise
    the protocol type, the source and destination addresses at various
    network layers (extracted from the packet), and the number of the
    interface on which the packet was observed.

  - First and last TIMES when packets were seen for this flow, i.e.
    the 'creation' and 'last activity' times for the flow.

  - COUNTS for 'forward' (source to destination) and 'backward'
    (destination to source) components (e.g.  packets and bytes) of the
    flow's traffic.  The specifying of 'source' and 'destination' for
    flows is discussed in the section on packet matching below.

  - OTHER attributes, e.g.  information computed by the meter.

   A flow's ACCOUNTABLE ENTITY is specified by the values of its ADDRESS
   attributes.  For example, if a flow's address attributes specified
   only that "source address = IP address 10.1.0.1," then all IP packets
   from and to that address would be counted in that flow.  If a flow's
   address list were specified as "source address = IP address 10.1.0.1,
   destination address = IP address 26.1.0.1" then only IP packets
   between 10.1.0.1 and 26.1.0.1 would be counted in that flow.




Brownlee, et. al.             Experimental                      [Page 9]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   The addresses specifying a flow's address attributes may include one
   or more of the following types:

  - The INTERFACE NUMBER for the flow, i.e.  the interface on which the
    meter measured the traffic.  Together with a unique address for the
    meter this uniquely identifies a particular physical-level port.

  - The ADJACENT ADDRESS, i.e.  the [n-1] layer address of the
    immediate source or destination on the path of the packet.  For
    example, if flow measurement is being performed at the IP layer on
    an Ethernet LAN [3], an adjacent address is a six-octet Media
    Access Control (MAC) address.  For a host connected to the same LAN
    segment as the meter the adjacent address will be the MAC address
    of that host.  For hosts on other LAN segments it will be the MAC
    address of the adjacent (upstream or downstream) router carrying
    the traffic flow.

  - The PEER ADDRESS, which identifies the source or destination of the
    PEER-LEVEL packet.  The form of a peer address will depend on the
    network-layer protocol in use, and the network layer [n] at which
    traffic measurement is being performed.

  - The TRANSPORT ADDRESS, which identifies the source or destination
    port for the packet, i.e.  its [n+1] layer address.  For example,
    if flow measurement is being performed at the IP layer a transport
    address is a two-octet UDP or TCP port number.

   The four definitions above specify addresses for each of the four
   lowest layers of the OSI reference model, i.e.  Physical layer, Link
   layer, Network layer and Transport layer.  A FLOW RECORD stores both
   the VALUE for each of its addresses (as described above) and a MASK
   specifying which bits of the address value are being used and which
   are ignored.  Note that if address bits are being ignored the meter
   will set them to zero, however their actual values are undefined.

   One of the key features of the traffic measurement architecture is
   that attributes have essentially the same meaning for different
   protocols, so that analysis applications can use the same reporting
   formats for all protocols.  This is straightforward for peer
   addresses; although the form of addresses differs for the various
   protocols, the meaning of a 'peer address' remains the same.  It
   becomes harder to maintain this correspondence at higher layers - for
   example, at the Network layer IP, Novell IPX and AppleTalk all use
   port numbers as a 'transport address,' but CLNP and DECnet have no
   notion of ports.  Further work is needed here, particularly in
   selecting attributes which will be suitable for the higher layers of
   the OSI reference model.




Brownlee, et. al.             Experimental                     [Page 10]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   Reporting by adjacent intermediate sources and destinations or simply
   by meter interface (most useful when the meter is embedded in a
   router) supports hierarchical Internet reporting schemes as described
   in the 'Traffic Flow Measurement:  Background' RFC [1].  That is, it
   allows backbone and regional networks to measure usage to just the
   next lower level of granularity (i.e.  to the regional and
   stub/enterprise levels, respectively), with the final breakdown
   according to end user (e.g.  to source IP address) performed by the
   stub/enterprise networks.

   In cases where network addresses are dynamically allocated (e.g.
   mobile subscribers), further subscriber identification will be
   necessary if flows are to ascribed to individual users.  Provision is
   made to further specify the accountable entity through the use of an
   optional SUBSCRIBER ID as part of the flow id.  A subscriber ID may
   be associated with a particular flow either through the current rule
   set or by proprietary means within a meter, for example via protocol
   exchanges with one or more (multi-user) hosts.  At this time a
   subscriber ID is an arbitrary text string; later versions of the
   architecture may specify its contents on more detail.

3.2 Granularity of Flow Measurements

   GRANULARITY is the 'control knob' by which an application and/or the
   meter can trade off the overhead associated with performing usage
   reporting against the level of detail supplied.  A coarser
   granularity means a greater level of aggregation; finer granularity
   means a greater level of detail.  Thus, the number of flows measured
   (and stored) at a meter can be regulated by changing the granularity
   of the accountable entity, the attributes, or the time intervals.
   Flows are like an adjustable pipe - many fine-granularity streams can
   carry the data with each stream measured individually, or data can be
   bundled in one coarse-granularity pipe.

   Flow granularity is controlled by adjusting the level of detail at
   which the following are reported:

  - The accountable entity (address attributes, discussed above).

  - The categorisation of packets (other attributes, discussed below).

  - The lifetime/duration of flows (the reporting interval needs to be
    short enough to measure them with sufficient precision).








Brownlee, et. al.             Experimental                     [Page 11]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   The set of rules controlling the determination of each packet's
   accountable entity is known as the meter's CURRENT RULE SET. As will
   be shown, the meter's current rule set forms an integral part of the
   reported information, i.e.  the recorded usage information cannot be
   properly interpreted without a definition of the rules used to
   collect that information.

   Settings for these granularity factors may vary from meter to meter.
   They are determined by the meter's current rule set, so they will
   change if network Operations personnel reconfigure the meter to use a
   new rule set.  It is expected that the collection rules will change
   rather infrequently; nonetheless, the rule set in effect at any time
   must be identifiable via a RULE SET ID. Granularity of accountable
   entities is further specified by additional ATTRIBUTES. These
   attributes include:

     - Meter variables such as the index of the flow's record in the flow
       table and the rule set id for the rules which the meter was running
       while the flow was observed.  The values of these attributes
       provide a way of distinguishing flows observed by a meter at
       different times.

     - Attributes which record information derived from other attribute
       values.  Six of these are defined (SourceClass, DestClass,
       FlowClass, SourceKind, DestKind, FlowKind), and their meaning is
       determined by the meter's rule set.  For example, one could have a
       subroutine in the rule set which determined whether a source or
       destination peer address was a member of an arbitrary list of
       networks, and set SourceClass/DestClass to one if the source/dest
       peer address was in the list or to zero otherwise.

     - Administratively specified attributes such as Quality Of Service
       and Priority, etc.  These are not defined at this time.

     - Higher-layer (especially application-level) attributes.  These are
       not defined at this time.

   Settings for these granularity factors may vary from meter to meter.
   They are determined by the meter's current rule set, so they will
   change if network Operations personnel reconfigure the meter to use a
   new rule set.

   The LIFETIME of a flow is the time interval which began when the
   meter observed the first packet belonging to the flow and ended when
   it saw the last packet.  Flow lifetimes are very variable, but many -
   if not most - are rather short.  A meter cannot measure lifetimes
   directly; instead a meter reader collects usage data for flows which
   have been active since the last collection, and an analysis



Brownlee, et. al.             Experimental                     [Page 12]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   application may compare the data from each collection so as to
   determine when each flow actually stopped.

   The meter does, however, need to reclaim memory (i.e.  records in the
   flow table) being held by idle flows.  The meter configuration
   includes a variable called InactivityTimeout, which specifies the
   minimum time a meter must wait before recovering the flow's record.
   In addition, before recovering a flow record the meter must be sure
   that the flow's data has been collected by at least one meter reader.

   These 'lifetime' issues are considered further in the section on
   meter readers (below).  A complete list of the attributes currently
   defined is given in Appendix C later in this document.

3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only

   Once an usage record is sent, the decision needs to be made whether
   to clear any existing flow records or to maintain them and add to
   their counts when recording subsequent traffic on the same flow.  The
   second method, called rolling counters, is recommended and has
   several advantages.  Its primary advantage is that it provides
   greater reliability - the system can now often survive the loss of
   some usage records, such as might occur if a meter reader failed and
   later restarted.  The next usage record will very often contain yet
   another reading of many of the same flow buckets which were in the
   lost usage record.  The 'continuity' of data provided by rolling
   counters can also supply information used for "sanity" checks on the
   data itself, to guard against errors in calculations.

   The use of rolling counters does introduce a new problem:  how to
   distinguish a follow-on flow record from a new flow record.  Consider
   the following example.


                         CONTINUING FLOW        OLD FLOW, then NEW FLOW

                         start time = 1            start time = 1
   Usage record N:       flow count = 2000      flow count = 2000 (done)

                         start time = 1            start time = 5
   Usage record N+1:     flow count = 3000      new flow count = 1000

   Total count:                 3000                    3000


   In the continuing flow case, the same flow was reported when its
   count was 2000, and again at 3000:  the total count to date is 3000.
   In the OLD/NEW case, the old flow had a count of 2000.  Its record



Brownlee, et. al.             Experimental                     [Page 13]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   was then stopped (perhaps because of temporary idleness, or MAX
   LIFETIME policy), but then more traffic with the same characteristics
   arrived so a new flow record was started and it quickly reached a
   count of 1000.  The total flow count from both the old and new
   records is 3000.

   The flow START TIMESTAMP attribute is sufficient to resolve this.  In
   the example above, the CONTINUING FLOW flow record in the second
   usage record has an old FLOW START timestamp, while the NEW FLOW
   contains a recent FLOW START timestamp.

   Each packet is counted in one and only one flow, so as to avoid
   multiple counting of a single packet.  The record of a single flow is
   informally called a "bucket." If multiple, sometimes overlapping,
   records of usage information are required (aggregate, individual,
   etc), the network manager should collect the counts in sufficiently
   detailed granularity so that aggregate and combination counts can be
   reconstructed in post-processing of the raw usage data.

   For example, consider a meter from which it is required to record
   both 'total packets coming in interface #1' and 'total packets
   arriving from any interface sourced by IP address = a.b.c.d.'
   Although a bucket can be declared for each case, it is not clear how
   to handle a packet which satisfies both criteria.  It must only be
   counted once.  By default it will be counted in the first bucket for
   which it qualifies, and not in the other bucket.  Further, it is not
   possible to reconstruct this information by post-processing.  The
   solution in this case is to define not two, but THREE buckets, each
   one collecting a unique combination of the two criteria:

        Bucket 1:  Packets which came in interface 1,
                   AND were sourced by IP address a.b.c.d

        Bucket 2:  Packets which came in interface 1,
                   AND were NOT sourced by IP address a.b.c.d

        Bucket 3:  Packets which did NOT come in interface 1,
                   AND were sourced by IP address a.b.c.d

       (Bucket 4:  Packets which did NOT come in interface 1,
                   AND NOT sourced by IP address a.b.c.d)

   The desired information can now be reconstructed by post-processing.
   "Total packets coming in interface 1" can be found by adding buckets
   1 & 2, and "Total packets sourced by IP address a.b.c.d" can be found
   by adding buckets 1 & 3.  Note that in this case bucket 4 is not
   explicitly required since its information is not of interest, but it
   is supplied here in parentheses for completeness.



Brownlee, et. al.             Experimental                     [Page 14]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


4 Meters

   A traffic flow meter is a device for collecting data about traffic
   flows at a given point within a network; we will call this the
   METERING POINT.  The header of every packet passing the network
   metering point is offered to the traffic meter program.

   A meter could be implemented in various ways, including:

  - A dedicated small host, connected to a LAN (so that it can see all
    packets as they pass by) and running a 'traffic meter' program.
    The metering point is the LAN segment to which the meter is
    attached.

  - A multiprocessing system with one or more network interfaces, with
    drivers enabling a traffic meter program to see packets.  In this
    case the system provides multiple metering points - traffic flows
    on any subset of its network interfaces can be measured.

  - A packet-forwarding device such as a router or switch.  This is
    similar to (b) except that every received packet should also be
    forwarded, usually on a different interface.

   The discussion in the following sections assumes that a meter may
   only run a single rule set.  It is, however, possible for a meter to
   run several rule sets concurrently, matching each packet against
   every active rule set and producing a single flow table with flows
   from all the active rule sets.  The overall effect of doing this
   would be similar to running several independent meters, one for each
   rule set.

4.1 Meter Structure

   An outline of the meter's structure is given in the following
   diagram.

   Briefly, the meter works as follows:

  - Incoming packet headers arrive at the top left of the diagram and
    are passed to the PACKET PROCESSOR.

  - The packet processor passes them to the Packet Matching Engine
    (PME) where they are classified.

  - The PME is a Virtual Machine running a pattern matching program
    contained in the CURRENT RULE SET. It is invoked by the Packet
    Processor, and returns instructions on what to do with the packet.




Brownlee, et. al.             Experimental                     [Page 15]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


  - Some packets are classified as 'to be ignored.'  They are discarded
    by the Packet Processor.

  - Other packets are matched by the PME, which returns a FLOW KEY
    describing the flow to which the packet belongs.

  - The flow key is used to locate the flow's entry in the FLOW TABLE;
    a new entry is created when a flow is first seen.  The entry's
    packet and byte counters are updated.

  - A meter reader may collect data from the flow table at any time.
    It may use the 'collect' index to locate the flows to be collected
    within the flow table.



                  packet                +------------------+
                  header                | Current Rule Set |
                    |                   +--------+---------+
                    |                            |
           +--------*---------+       +----------*-------------+
           | Packet Processor |<----->| Packet Matching Engine |
           +--+------------+--+       +------------------------+
              |            |
       Ignore *            | Count via flow key
                           |
                        +--*--------------+
                        | 'Search' index  |
                        +--------+--------+
                                 |
                        +--------*--------+
                        |                 |
                        |   Flow Table    |
                        |                 |
                        +--------+--------+
                                 |
                        +--------*--------+
                        | 'Collect' index |
                        +--------+--------+
                                 |
                                 *
                            Meter Reader









Brownlee, et. al.             Experimental                     [Page 16]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


4.2 Flow Table

   Every traffic meter maintains a table of TRAFFIC FLOW RECORDS for
   flows seen by the meter.  A flow record contains attribute values for
   its flow, including:

  - Addresses for the flow's source and destination.  These include
    addresses and masks for various network layers (extracted from the
    packet), and the number of the interface on which the packet was
    observed.

  - First and last times when packets were seen for this flow.

  - Counts for 'forward' (source to destination) and 'backward'
    (destination to source) components of the flow's traffic.

  - Other attributes, e.g.  state of the flow record (discussed below).

   The state of a flow record may be:

  - INACTIVE: The flow record is not being used by the meter.

  - CURRENT: The record is in use and describes a flow which belongs to
    the 'current flow set,' i.e.  the set of flows recently seen by the
    meter.

  - IDLE: The record is in use and the flow which it describes is part
    of the current flow set.  In addition, no packets belonging to this
    flow have been seen for a period specified by the meter's
    InactivityTime variable.

4.3 Packet Handling, Packet Matching

   Each packet header received by the traffic meter program is processed
   as follows:

  - Extract attribute values from the packet header and use them to
    create a MATCH KEY for the packet.

  - Match the packet's key against the current rule set, as explained
    in detail below.

   The rule set specifies whether the packet is to be counted or
   ignored.  If it is to be counted the matching process produces a FLOW
   KEY for the flow to which the packet belongs.  This flow key is used
   to find the flow's record in the flow table; if a record does not yet
   exist for this flow, a new flow record may be created.  The counts
   for the matching flow record can then be incremented.



Brownlee, et. al.             Experimental                     [Page 17]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   For example, the rule set could specify that packets to or from any
   host in IP network 130.216 are to be counted.  It could also specify
   that flow records are to be created for every pair of 24-bit (Class
   C) subnets within network 130.216.

   Each packet's match key is passed to the meter's PATTERN MATCHING
   ENGINE (PME) for matching.  The PME is a Virtual Machine which uses a
   set of instructions called RULES, i.e.  a RULE SET is a program for
   the PME. A packet's match key contains an interface number, source
   address (S) and destination address (D) values.  It does not,
   however, contain any attribute masks for its attributes, only their
   values.

   If measured flows were unidirectional, i.e.  only counted packets
   travelling in one direction, the matching process would be simple.
   The PME would be called once to match the packet.  Any flow key
   produced by a successful match would be used to find the flow's
   record in the flow table, and that flow's counters would be updated.

   Flows are, however, bidirectional, reflecting the forward and reverse
   packets of a protocol interchange or 'session.'  Maintaining two sets
   of counters in the meter's flow record makes the resulting flow data
   much simpler to handle, since analysis programs do not have to gather
   together the 'forward' and 'reverse' components of sessions.
   Implementing bi-directional flows is, of course, more difficult for
   the meter, since it must decide whether a packet is a 'forward'
   packet or a 'reverse' one.  To make this decision the meter will
   often need to invoke the PME twice, once for each possible packet
   direction.

   The diagram below describes the algorithm used by the traffic meter
   to process each packet.  Flow through the diagram is from left to
   right and top to bottom, i.e.  from the top left corner to the bottom
   right corner.  S indicates the flow's source address (i.e.  its set
   of source address attribute values) from the packet, and D indicates
   its destination address.

   There are several cases to consider.  These are:

  - The packet is recognised as one which is TO BE IGNORED.

  - The packet MATCHES IN BOTH DIRECTIONS. One situation in which this
    could happen would be a rule set which matches flows within network
    X (Source = X, Dest = X) but specifies that flows are to be created
    for each subnet within network X, say subnets y and z.  If, for
    example a packet is seen for y->z, the meter must check that flow
    z->y is not already current before creating y->z.




Brownlee, et. al.             Experimental                     [Page 18]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


  - The packet MATCHES IN ONE DIRECTION ONLY. If its flow is already
    current, its forward or reverse counters are incremented.
    Otherwise it is added to the flow table and then counted.

   The algorithm uses four functions, as follows:

match(A->B) implements the PME.  It uses the meter's current rule set
   to match the attribute values in the packet's match key.  A->B means
   that the assumed source address is A and destination address B, i.e.
   that the packet was travelling from A to B.  match() returns one of
   three results:

   'Ignore' means that the packet was matched but this flow is not
            to be counted.

   'Fail' means that the packet did not match.  It might, however
            match with its direction reversed, i.e. from B to A.

   'Suc'  means that the packet did match, i.e. it belongs to a flow
            which is to be counted.

current(A->B) succeeds if the flow A-to-B is current - i.e. has
   a record in the flow table whose state is Current - and fails
   otherwise.

create(A->B) adds the flow A-to-B to the flow table, setting the
   value for attributes - such as addresses - which remain constant,
   and zeroing the flow's counters.

count(A->B,f) increments the 'forward' counters for flow A-to-B.
count(A->B,r) increments the 'reverse' counters for flow A-to-B.
   'Forward' here means the counters for packets travelling from
   A to B.  Note that count(A->B,f) is identical to count(B->A,r).


















Brownlee, et. al.             Experimental                     [Page 19]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


                    Ignore
    --- match(S->D) -------------------------------------------------+
         | Suc   | Fail                                              |
         |       |          Ignore                                   |
         |      match(D->S) -----------------------------------------+
         |       | Suc   | Fail                                      |
         |       |       |                                           |
         |       |       +-------------------------------------------+
         |       |                                                   |
         |       |             Suc                                   |
         |      current(D->S) ---------- count(D->S,r) --------------+
         |       | Fail                                              |
         |       |                                                   |
         |      create(D->S) ----------- count(D->S,r) --------------+
         |                                                           |
         |             Suc                                           |
        current(S->D) ------------------ count(S->D,f) --------------+
         | Fail                                                      |
         |             Suc                                           |
        current(D->S) ------------------ count(D->S,r) --------------+
         | Fail                                                      |
         |                                                           |
        create(S->D) ------------------- count(S->D,f) --------------+
                                                                     |
                                                                     *

   When writing rule sets one must remember that the meter will normally
   try to match each packet in both directions.  It is particularly
   important that the rule set does not contain inconsistencies which
   will upset this process.

   Consider, for example, a rule set which counts packets from source
   network A to destination network B, but which ignores packets from
   source network B. This is an obvious example of an inconsistent rule
   set, since packets from network B should be counted as reverse
   packets for the A-to-B flow.

   This problem could be avoided by devising a language for specifying
   rule files and writing a compiler for it, thus making it much easier
   to produce correct rule sets.  Another approach would be to write a
   'rule set consistency checker' program, which could detect problems
   in hand-written rule sets.

   In the short term the best way to avoid these problems is to write
   rule sets which only clasify flows in the forward direction, and rely
   on the meter to handle reverse-travelling packets.





Brownlee, et. al.             Experimental                     [Page 20]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


4.4 Rules and Rule Sets

   A rule set is an array of rules.  Rule sets are held within a meter
   as entries in an array of rule sets.  One member of this array is the
   CURRENT RULE SET, in that it is the one which is currently being used
   by the meter to classify incoming packets.

   Rule set 1 is built in to the meter and cannot be changed.  It is run
   when the meter is started up, and provides a very coarse reporting
   granularity; it is mainly useful for verifying that the meter is
   running, before a 'useful' rule set is downloaded to it.

   If the meter is instructed to use rule set 0, it will cease
   measuring; all packets will be ignored until another (non-zero) rule
   set is made current.

   Each rule in a rule set is structured as follows:


   +-------- test ---------+    +---- action -----+
   attribute & mask = value:    opcode,  parameter;


   Opcodes contain two flags:  'goto' and 'test.'  The PME maintains a
   Boolean indicator called the 'test indicator,' which is initially set
   (on).  Execution begins with rule 1, the first in the rule set.  It
   proceeds as follows:

   If the test indicator is on:
      Perform the test, i.e. AND the attribute value with the
         mask and compare it with the value.
      If these are equal the test has succeeded; perform the
         rule's action (below).
      If the test fails execute the next rule in the rule set.
      If there are no more rules in the rule set, return from the
         match() function indicating failure.

   If the test indicator is off, or the test (above) succeeded:
      Set the test indicator to this rule's test flag value.
      Determine the next rule to execute.
         If the opcode has its goto flag set, its parameter value
            specifies the number of the next rule.
         Opcodes which don't have their goto flags set either
            determine the next rule in special ways (Return),
            or they terminate execution (Ignore, Fail, Count,
            CountPkt).
      Perform the action.




Brownlee, et. al.             Experimental                     [Page 21]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   The PME maintains two 'history' data structures.  The first, the
   'return' stack, simply records the index (i.e.  1-origin rule number)
   of each Gosub rule as it is executed; Return rules pop their Gosub
   rule index.  The second, the 'pattern' queue, is used to save
   information for later use in building a flow key.  A flow key is
   built by zeroing all its attribute values, then copying attribute and
   mask information from the pattern stack in the order it was enqueued.

   The opcodes are:

         opcode         goto    test

      1  Ignore           0       -
      2  Fail             0       -
      3  Count            0       -
      4  CountPkt         0       -
      5  Return           0       0
      6  Gosub            1       1
      7  GosubAct         1       0
      8  Assign           1       1
      9  AssignAct        1       0
     10  Goto             1       1
     11  GotoAct          1       0
     12  PushRuleTo       1       1
     13  PushRuleToAct    1       0
     14  PushPktTo        1       1
     15  PushPktToAct     1       0

   The actions they perform are:

   Ignore:         Stop matching, return from the match() function
                   indicating that the packet is to be ignored.

   Fail:           Stop matching, return from the match() function
                   indicating failure.

   Count:          Stop matching.  Save this rule's attribute name,
                   mask and value in the PME's pattern queue, then
                   construct a flow key for the flow to which this
                   this packet belongs.  Return from the match()
                   function indicating success.  The meter will use
                   the flow key to locate the flow record for this
                   packet's flow.

   CountPkt:       As for Count, except that the masked value from
                   the packet is saved in the PME's pattern queue
                   instead of the rule's value.




Brownlee, et. al.             Experimental                     [Page 22]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   Gosub:          Call a rule-matching subroutine.  Push the current
                   rule number on the PME's return stack, set the
                   test indicator then goto the specified rule.

   GosubAct:       Same as Gosub, except that the test indicator is
                   cleared before going to the specified rule.

   Return:         Return from a rule-matching subroutine.  Pop the
                   number of the calling gosub rule from the PME's
                   'return' stack and add this rule's parameter value
                   to it to determine the 'target' rule.  Clear the
                   test indicator then goto the target rule.

                   A subroutine call appears in a rule set as a Gosub
                   rule followed by a small group of following rules.
                   Since a Return action clears the test flag, the
                   action of one of these 'following' rules will be
                   executed; this allows the subroutine to return a
                   result (in addition to any information it may save
                   in the PME's pattern queue).

   Assign:         Set the attribute specified in this rule to the
                   value specified in this rule.  Set the test
                   indicator then goto the specified rule.

   AssignAct:      Same as Assign, except that the test indicator
                   is cleared before going to the specified rule.

   Goto:           Set the test indicator then goto the
                   specified rule.

   GotoAct:        Clear the test indicator then goto the specified
                   rule.

   PushRuleTo:     Save this rule's attribute name, mask and value
                   in the PME's pattern queue. Set the test
                   indicator then goto the specified rule.

   PushRuleToAct:  Same as PushRuleTo, except that the test indicator
                   is cleared before going to the specified rule.

                   PushRuleTo actions may be used to save the value
                   and mask used in a test, or (if the test is not
                   performed) to save an arbitrary value and mask.







Brownlee, et. al.             Experimental                     [Page 23]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   PushPktTo:      Save this rule's attribute name, mask, together
                   with the masked value from the packet, in the
                   PME's pattern queue.  SET the test indicator then
                   goto the specified rule.

   PushPktToAct:   Same as PushPktTo, except that the test indicator
                   is cleared before going to the specified rule.

                   PushPktTo actions may be used to save a value from
                   the packet using a specified mask.  The test in
                   PushPktTo rules will almost never be executed.

   As well as the attributes applying directly to packets (such as
   SourcePeerAddress, DestTransAddress, etc.)  the PME implements
   several further attribtes.  These are:

   Null:       Tests performed on the Null attribute always succeed.

   v1 .. v5:   v1, v2, v3, v4 and v5 are 'meter variables.'  They
               provide a way to pass parameters into rule-matching
               subroutines.  Each may hold the name of a normal
               attribute; its value is set by an Assign action.
               When a meter variable appears as the attribute of a
               rule, its value specifies the actual attribute to be
               tested.  For example, if v1 had been assigned
               SourcePeerAddress as its value, a rule with v1 as its
               attribute would actually test SourcePeerAddress.

   SourceClass, DestClass, FlowClass,
   SourceKind, DestKind, FlowKind:
               These six attributes may be set by executing PushRuleto
               actions.  They allow the PME to save (in flow records)
               information which has been built up during matching.
               Since their values are only defined when matching is
               complete (and the flow key is built) their values may
               not be tested in rules.

4.5 Maintaining the Flow Table

   The flow table may be thought of as a 1-origin array of flow records.
   (A particular implementation may, of course, use whatever data
   structure is most suitable).  When the meter starts up there are no
   known flows; all the flow records are in the 'inactive' state.

   Each time a packet is seen for a flow which is not in the current
   flow set a flow record is set up for it; the state of such a record
   is 'current.'  When selecting a record for the new flow the meter
   searches the flow table for a 'inactive' record - there is no



Brownlee, et. al.             Experimental                     [Page 24]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   particular significance in the ordering of records within the table.

   Flow data may be collected by a 'meter reader' at any time.  There is
   no requirement for collections to be synchronized.  The reader may
   collect the data in any suitable manner, for example it could upload
   a copy of the whole flow table using a file transfer protocol, or it
   could read the records in the current flow set row by row using a
   suitable data transfer protocol.

   The meter keeps information about collections, in particular it
   maintains a LastCollectTime variable which remembers the time the
   last collection was made.  A second variable, InactivityTime,
   specifies the minimum time the meter will wait before considering
   that a flow is idle.

   The meter must recover records used for idle flows, if only to
   prevent it running out of flow records.  Recovered flow records are
   returned to the 'inactive' state.  A variety of recovery strategies
   are possible, including the following:

   One possible recovery strategy is to recover idle flow records as
   soon as possible after their data has been collected.  To implement
   this the meter could run a background process which scans the flow
   table looking for 'current' flows whose 'last packet' time is earlier
   than the meter's LastCollectTime.  This would be suitable for use
   when one was interested in measuring flow lifetimes.

   Another recovery strategy is to leave idle flows alone as long as
   possible, which would be suitable if one was only interested in
   measuring total traffic volumes.  It could be implemented by having
   the meter search for collected idle flows only when it ran out of
   'inactive' flow records.

   One further factor a meter should consider before recovering a flow
   is the number of meter readers which have collected the flow's data.
   If there are multiple meter readers operating, network Operations
   personnel should be able to specify the minimum number of meters - or
   perhaps a specific list of meters - which should collect a flow's
   data before its memory can be recovered.  This issue will be further
   developed in the future.

4.6 Handling Increasing Traffic Levels

   Under normal conditions the meter reader specifies which set of usage
   records it wants to collect, and the meter provides them.

   If memory usage rises above the high-water mark the meter should
   switch to a STANDBY RULE SET so as to increase the granularity of



Brownlee, et. al.             Experimental                     [Page 25]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   flow collection and decrease the rate at which new flows are created.
   When the manager, usually as part of a regular poll, becomes aware
   that the meter is using its standby rule set, it could decrease the
   interval between collections.  The meter should also increase its
   efforts to recover flow memory so as to reduce the number of idle
   flows in memory.  When the situation returns to normal, the manager
   may request the meter to switch back to its normal rule set.

5 Meter Readers

   Usage data is accumulated by a meter (e.g.  in a router) as memory
   permits.  It is collected at regular reporting intervals by meter
   readers, as specified by a manager.  The collected data is recorded
   in a disk file called a FLOW DATA FILE, as a sequence of USAGE
   RECORDS.

   The following sections describe the contents of usage records and
   flow data files.  Note, however, that at this stage the details of
   such records and files is not specified in the architecture.
   Specifying a common format for them would be a worthwhile future
   development.

5.1 Identifying Flows in Flow Records

   Once a packet has been classified and is ready to be counted, an
   appropriate flow data record must already exist in the flow table;
   otherwise one must be created.  The flow record has a flexible format
   where unnecessary identification attributes may be omitted.  The
   determination of which attributes of the flow record to use, and of
   what values to put in them, is specified by the current rule set.

   Note that the combination of start time, rule set id and subscript
   (row number in the flow table) provide a unique flow identifier,
   regardless of the values of its other attributes.

   The current rule set may specify additional information, e.g.  a
   computed attribute value such as FlowKind, which is to be placed in
   the attribute section of the usage record.  That is, if a particular
   flow is matched by the rule set, then the corresponding flow record
   should be marked not only with the qualifying identification
   attributes, but also with the additional information.  Using this
   feature, several flows may each carry the same FlowKind value, so
   that the resulting usage records can be used in post-processing or
   between meter reader and meter as a criterion for collection.







Brownlee, et. al.             Experimental                     [Page 26]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


5.2 Usage Records, Flow Data Files

   The collected usage data will be stored in flow data files on the
   meter reader, one file for each meter.  As well as containing the
   measured usage data, flow data files must contain information
   uniquely identifiying the meter from which it was collected.

   A USAGE RECORD contains the descriptions of and values for one or
   more flows.  Quantities are counted in terms of number of packets and
   number of bytes per flow.  Each usage record contains the entity
   identifier of the meter (a network address), a time stamp and a list
   of reported flows (FLOW DATA RECORDS). A meter reader will build up a
   file of usage records by regularly collecting flow data from a meter,
   using this data to build usage records and concatenating them to the
   tail of a file.  Such a file is called a FLOW DATA FILE.

   A usage record contains the following information in some form:

   +-------------------------------------------------------------------+
   |    RECORD IDENTIFIERS:                                            |
   |      Meter Id (& digital signature if required)                   |
   |      Timestamp                                                    |
   |      Collection Rules ID                                          |
   +-------------------------------------------------------------------+
   |    FLOW IDENTIFIERS:            |    COUNTERS                     |
   |      Address List               |       Packet Count              |
   |      Subscriber ID (Optional)   |       Byte Count                |
   |      Attributes (Optional)      |    Flow Start/Stop Time         |
   +-------------------------------------------------------------------+

5.3 Meter to Meter Reader:  Usage Record Transmission

   The usage record contents are the raison d'etre of the system.  The
   accuracy, reliability, and security of transmission are the primary
   concerns of the meter/meter reader exchange.  Since errors may occur
   on networks, and Internet packets may be dropped, some mechanism for
   ensuring that the usage information is transmitted intact is needed.

   Flow data is moved from meter to meter reader via a series of
   protocol exchanges between them.  This may be carried out in various
   ways, moving individual attribute values, complete flows, or the
   entire flow table (i.e.  all the active flows).  One possible method
   of achieving this transfer is to use SNMP; the 'Traffic Flow
   Measurement:  Meter MIB' document [4] gives details.  Note that this
   is simply one example; the transfer of flow data from meter to meter
   reader is not specified in this document.





Brownlee, et. al.             Experimental                     [Page 27]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   The reliability of the data transfer method under light, normal, and
   extreme network loads should be understood before selecting among
   collection methods.

   In normal operation the meter will be running a rule file which
   provides the required degree of flow reporting granularity, and the
   meter reader(s) will collect the flow data often enough to allow the
   meter's garbage collection mechanism to maintain a stable level of
   memory usage.

   In the worst case traffic may increase to the point where the meter
   is in danger of running completely out of flow memory.  The meter
   implementor must decide how to handle this, for example by switching
   to a default (extremely coarse granularity) rule set, by sending a
   trap to the manager, or by attempting to dump flow data to the meter
   reader.

   Users of the Traffic Flow Measurement system should analyse their
   requirements carefully and assess for themselves whether it is more
   important to attempt to collect flow data at normal granularity
   (increasing the collection frequency as needed to keep up with
   traffic volumes), or to accept flow data with a coarser granularity.
   Similarly, it may be acceptable to lose flow data for a short time in
   return for being sure that the meter keeps running properly, i.e.  is
   not overwhelmed by rising traffic levels.

6 Managers

   A manager configures meters and controls meter readers.  It does this
   via the interactions described below.

6.1 Between Manager and Meter:  Control Functions

  - DOWNLOAD RULE SET: A meter may hold an array of rule sets.  One of
    these, the 'default' rule set, is built in to the meter and cannot
    be changed; the others must be downloaded by the manager.  A
    manager may use any suitable protocol exchange to achieve this, for
    example an FTP file transfer or a series of SNMP SETs, one for each
    row of the rule set.

  - SWITCH TO SPECIFIED RULE SET: Once the rule sets have been
    downloaded, the manager must instruct the meter which rule set it
    is to actually run (i.e.  which is to be the current rule set), and
    which is to be the standby rule set.

  - SET HIGH WATER MARK: A percentage value interpreted by the meter
    which tells the meter when to switch to its standby rule set, so as
    to increase the granularity of the flows and conserve the meter's



Brownlee, et. al.             Experimental                     [Page 28]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


    flow memory.  Once this has happened, the manager may also change
    the polling frequency or the meter's control parameters (so as to
    increase the rate at which the meter can recover memory from idle
    flows).

    If the high traffic levels persist, the meter's normal rule set may
    have to be rewritten to permanently reduce the reporting
    granularity.

  - SET FLOW TERMINATION PARAMETERS: The meter should have the good
    sense in situations where lack of resources may cause data loss to
    purge flow records from its tables.  Such records may include:

      -  Flows that have already been reported to at least one meter
         reader, and show no activity since the last report,

      -  Oldest flows, or

      -  Flows with the smallest number of unreported packets.


  - SET INACTIVITY TIMEOUT: This is a time in seconds since the last
    packet was seen for a flow.  Flow records may be reclaimed if they
    have been idle for at least this amount of time, and have been
    collected in accordance with the current collection criteria.

6.2 Between Manager and Meter Reader:  Control Functions

   Because there are a number of parameters that must be set for traffic
   flow measurement to function properly, and viable settings may change
   as a result of network traffic characteristics, it is desirable to
   have dynamic network management as opposed to static meter
   configurations.  Many of these operations have to do with space
   tradeoffs - if memory at the meter is exhausted, either the reporting
   interval must be decreased or a coarser granularity of aggregation
   must be used so that more data fits into less space.

   Increasing the reporting interval effectively stores data in the
   meter; usage data in transit is limited by the effective bandwidth of
   the virtual link between the meter and the meter reader, and since
   these limited network resources are usually also used to carry user
   data (the purpose of the network), the level of traffic flow
   measurement traffic should be kept to an affordable fraction of the
   bandwidth.  ("Affordable" is a policy decision made by the network
   Operations personnel).  At any rate, it must be understood that the
   operations below do not represent the setting of independent
   variables; on the contrary, each of the values set has a direct and
   measurable effect on the behaviour of the other variables.



Brownlee, et. al.             Experimental                     [Page 29]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   Network management operations follow:

  - MANAGER and METER READER IDENTIFICATION: The manager should ensure
    that meters report to the correct set of collection stations, and
    take steps to prevent unauthorised access to usage information.
    The collection stations so identified should be prepared to poll if
    necessary and accept data from the appropriate meters.  Alternate
    collection stations may be identified in case both the primary
    manager and the primary collection station are unavailable.
    Similarly, alternate managers may be identified.

  - REPORTING INTERVAL CONTROL: The usual reporting interval should be
    selected to cope with normal traffic patterns.  However, it may be
    possible for a meter to exhaust its memory during traffic spikes
    even with a correctly set reporting interval.  Some mechanism must
    be available for the meter to tell the manager that it is in danger
    of exhausting its memory (by declaring a 'high water' condition),
    and for the manager to arbitrate (by decreasing the polling
    interval, letting nature take its course, or by telling the meter
    to ask for help sooner next time).

  - GRANULARITY CONTROL: Granularity control is a catch-all for all the
    parameters that can be tuned and traded to optimise the system's
    ability to reliably measure and store information on all the
    traffic (or as close to all the traffic as an administration
    requires).  Granularity

      -  Controls flow-id granularities for each interface, and

      -  Determines the number of buckets into which user traffic will
         be lumped together.

    Since granularity is controlled by the meter's current rule set,
    the manager can only change it by requesting the meter to switch to
    a different rule set.  The new rule set could be downloaded when
    required, or it could have been downloaded as part of the meter's
    initial configuration.

  - FLOW LIFETIME CONTROL: Flow termination parameters include timeout
    parameters for obsoleting inactive flows and removing them from
    tables and maximum flow lifetimes.  This is intertwined with
    reporting interval and granularity, and must be set in accordance
    with the other parameters.








Brownlee, et. al.             Experimental                     [Page 30]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


6.3 Exception Conditions

   Exception conditions must be handled, particularly occasions when the
   meter runs out of buffer space.  Since, to prevent counting any
   packet twice, packets can only be counted in a single flow at any
   given time, discarding records will result in the loss of
   information.  The mechanisms to deal with this are as follows:

  - METER OUTAGES: In case of impending meter outages (controlled
    crashes, etc.)  the meter could send a trap to the manager.  The
    manager could then request one or more meter readers to pick up the
    usage record from the meter.

    Following an uncontrolled meter outage such as a power failure, the
    meter could send a trap to the manager indicating that it has
    restarted.  The manager could then download the meter's correct
    rule set and advise the meter reader(s) that the meter is running
    again.  Alternatively, the meter reader may discover from its
    regular poll that a meter has failed and restarted.  It could then
    advise the manager of this, instead of relying on a trap from the
    meter.

  - METER READER OUTAGES: If the collection system is down or isolated,
    the meter should try to inform the manager of its failure to
    communicate with the collection system.  Usage data is maintained
    in the flows' rolling counters, and can be recovered when the meter
    reader is restarted.

  - MANAGER OUTAGES: If the manager fails for any reason, the meter
    should continue measuring and the meter reader(s) should keep
    gathering usage records.

  - BUFFER PROBLEMS: The network manager may realise that there is a
    'low memory' condition in the meter.  This can usually be
    attributed to the interaction between the following controls:

      -  The reporting interval is too infrequent,

      -  The reporting granularity is too fine, or

      -  The throughput/bandwidth of circuits carrying the usage
         data is too low.

    The manager may change any of these parameters in response to the
    meter (or meter reader's) plea for help.






Brownlee, et. al.             Experimental                     [Page 31]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


6.4 Standard Rule Sets

   Although the rule table is a flexible tool, it can also become very
   complex.  It may be helpful to develop some rule sets for common
   applications:

  - PROTOCOL TYPE: The meter records packets by protocol type.  This
    will be the default rule table for Traffic Flow Meters.

  - ADJACENT SYSTEMS: The meter records packets by the MAC address of
    the Adjacent Systems (neighbouring originator or next-hop).
    (Variants on this table are "report source" or "report sink" only.)
    This strategy might be used by a regional or backbone network which
    wants to know how much aggregate traffic flows to or from its
    subscriber networks.

  - END SYSTEMS: The meter records packets by the IP address pair
    contained in the packet.  (Variants on this table are "report
    source" or "report sink" only.)  This strategy might be used by an
    End System network to get detailed host traffic matrix usage data.

  - TRANSPORT TYPE: The meter records packets by transport address; for
    IP packets this provides usage information for the various IP
    services.

  - HYBRID SYSTEMS: Combinations of the above, e.g.  for one interface
    report End Systems, for another interface report Adjacent Systems.
    This strategy might be used by an enterprise network to learn
    detail about local usage and use an aggregate count for the shared
    regional network.





















Brownlee, et. al.             Experimental                     [Page 32]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


7 APPENDICES

7.1 Appendix A: Network Characterisation

   Internet users have extraordinarily diverse requirements.  Networks
   differ in size, speed, throughput, and processing power, among other
   factors.  There is a range of traffic flow measurement capabilities
   and requirements.  For traffic flow measurement purposes, the
   Internet may be viewed as a continuum which changes in character as
   traffic passes through the following representative levels:


        International                    |
        Backbones/National        ---------------
                                 /              \
        Regional/MidLevel     ----------   ----------
                             /   \     \  /   /     \
        Stub/Enterprise     ---   ---   ---   ----   ----
                            |||   |||   |||   ||||   ||||
        End-Systems/Hosts   xxx   xxx   xxx   xxxx   xxxx

   Note that mesh architectures can also be built out of these
   components, and that these are merely descriptive terms.  The nature
   of a single network may encompass any or all of the descriptions
   below, although some networks can be clearly identified as a single
   type.

   BACKBONE networks are typically bulk carriers that connect other
   networks.  Individual hosts (with the exception of network management
   devices and backbone service hosts) typically are not directly
   connected to backbones.

   REGIONAL networks are closely related to backbones, and differ only
   in size, the number of networks connected via each port, and
   geographical coverage.  Regionals may have directly connected hosts,
   acting as hybrid backbone/stub networks.  A regional network is a
   SUBSCRIBER to the backbone.

   STUB/ENTERPRISE networks connect hosts and local area networks.
   STUB/ENTERPRISE networks are SUBSCRIBERS to regional and backbone
   networks.

   END SYSTEMS, colloquially HOSTS, are SUBSCRIBERS to any of the above
   networks.

   Providing a uniform identification of the SUBSCRIBER in finer
   granularity than that of end-system, (e.g.  user/account), is beyond
   the scope of the current architecture, although an optional attribute



Brownlee, et. al.             Experimental                     [Page 33]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   in the traffic flow measurement record may carry system-specific
   "accountable (billable) party" labels so that meters can implement
   proprietary or non-standard schemes for the attribution of network
   traffic to responsible parties.

7.2 Appendix B: Recommended Traffic Flow Measurement Capabilities

   Initial recommended traffic flow measurement conventions are outlined
   here according to the following Internet building blocks.  It is
   important to understand what complexity reporting introduces at each
   network level.  Whereas the hierarchy is described top-down in the
   previous section, reporting requirements are more easily addressed
   bottom-up.

        End-Systems
        Stub Networks
        Enterprise Networks
        Regional Networks
        Backbone Networks

   END-SYSTEMS are currently responsible for allocating network usage to
   end-users, if this capability is desired.  From the Internet Protocol
   perspective, end-systems are the finest granularity that can be
   identified without protocol modifications.  Even if a meter violated
   protocol boundaries and tracked higher-level protocols, not all
   packets could be correctly allocated by user, and the definition of
   user itself varies too widely from operating system to operating
   system (e.g.  how to trace network usage back to users from shared
   processes).

   STUB and ENTERPRISE networks will usually collect traffic data either
   by end- system network address or network address pair if detailed
   reporting is required in the local area network.  If no local
   reporting is required, they may record usage information in the exit
   router to track external traffic only.  (These are the only networks
   which routinely use attributes to perform reporting at granularities
   finer than end-system or intermediate-system network address.)

   REGIONAL networks are intermediate networks.  In some cases,
   subscribers will be enterprise networks, in which case the
   intermediate system network address is sufficient to identify the
   regional's immediate subscriber.  In other cases, individual hosts or
   a disjoint group of hosts may constitute a subscriber.  Then end-
   system network address pairs need to be tracked for those
   subscribers.  When the source may be an aggregate entity (such as a
   network, or adjacent router representing traffic from a world of
   hosts beyond) and the destination is a singular entity (or vice
   versa), the meter is said to be operating as a HYBRID system.



Brownlee, et. al.             Experimental                     [Page 34]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   At the regional level, if the overhead is tolerable it may be
   advantageous to report usage both by intermediate system network
   address (e.g.  adjacent router address) and by end-system network
   address or end-system network address pair.

   BACKBONE networks are the highest level networks operating at higher
   link speeds and traffic levels.  The high volume of traffic will in
   most cases preclude detailed traffic flow measurement.  Backbone
   networks will usually account for traffic by adjacent routers'
   network addresses.

7.3 Appendix C: List of Defined Flow Attributes

   This Appendix provides a checklist of the attributes defined to date;
   others will be added later as the Traffic Measurement Architecture is
   further developed.

   0  Null
   1  Flow Subscript                Integer    Flow table info
   2  Flow Status                   Integer

   4  Source Interface              Integer    Source Address
   5  Source Adjacent Type          Integer
   6  Source Adjacent Address       String
   7  Source Adjacent Mask          String
   8  Source Peer Type              Integer
   9  Source Peer Address           String
  10  Source Peer Mask              String
  11  Source Trans Type             Integer
  12  Source Trans Address          String
  13  Source Trans Mask             String

  14  Destination Interface         Integer    Destination Address
  15  Destination Adjacent Type     Integer
  16  Destination Adjacent Address  String
  17  Destination AdjacentMask      String
  18  Destination PeerType          Integer
  19  Destination PeerAddress       String
  20  Destination PeerMask          String
  21  Destination TransType         Integer
  22  Destination TransAddress      String
  23  Destination TransMask         String

  24  Packet Scale Factor           Integer    'Other' attributes
  25  Byte Scale Factor             Integer
  26  Rule Set Number               Integer
  27  Forward Bytes                 Counter    Source-to-Dest counters
  28  Forward Packets               Counter



Brownlee, et. al.             Experimental                     [Page 35]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


  29  Reverse Bytes                 Counter    Dest-to-Source counters
  30  Reverse Packets               Counter
  31  First Time                    TimeTicks  Activity times
  32  Last Active Time              TimeTicks
  33  Source Subscriber ID          String     Session attributes
  34  Destination Subscriber ID     String
  35  Session ID                    String

  36  Source Class                  Integer    'Computed' attributes
  37  Destination Class             Integer
  38  Flow Class                    Integer
  39  Source Kind                   Integer
  40  Destination Kind              Integer
  41  Flow Kind                     Integer

  51  V1                            Integer    Meter variables
  52  V2                            Integer
  53  V3                            Integer
  54  V4                            Integer
  55  V5                            Integer

7.4 Appendix D: List of Meter Control Variables

      Current Rule Set Number       Integer
      Standby Rule Set Number       Integer
      High Water Mark               Percentage
      Flood Mark                    Percentage
      Inactivity Timeout (seconds)  Integer
      Last Collect Time             TimeTicks

8 Acknowledgments

   This document was initially produced under the auspices of the IETF's
   Internet Accounting Working Group with assistance from SNMP, RMON and
   SAAG working groups.  This version documents the implementation work
   done by the Internet Accounting Working Group, and is intended to
   provide a starting point for the Realtime Traffic Flow Measurement
   Working Group.  Particular thanks are due to Stephen Stibler (IBM
   Research) for his patient and careful comments during the preparation
   of this memo.











Brownlee, et. al.             Experimental                     [Page 36]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


9 References

   [1] Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting
   Background", RFC 1272, Bolt Beranek and Newman Inc., Meridian
   Technology Corporation, November 1991.

   [2] International Standards Organisation (ISO), "Management
   Framework," Part 4 of Information Processing Systems Open
   Systems Interconnection Basic Reference Model, ISO 7498-4,
   1994.

   [3] IEEE 802.3/ISO 8802-3 Information Processing Systems -
   Local Area Networks - Part 3:  Carrier sense multiple access
   with collision detection (CSMA/CD) access method and physical
   layer specifications, 2nd edition, September 21, 1990.

   [4] Brownlee, N., "Traffic Flow Measurement:  Meter MIB",
   RFC 2064, The University of Auckland, January 1997.

10 Security Considerations

   Security issues are not discussed in detail in this document.  The
   meter's management and collection protocols are responsible for
   providing sufficient data integrity and confidentiality.

11 Authors' Addresses

   Nevil Brownlee
   Information Technology Systems & Services
   The University of Auckland

   Phone: +64 9 373 7599 x8941
   EMail: n.brownlee @auckland.ac.nz


   Cyndi Mills
   BBN Systems and Technologies

   Phone: +1 617 873 4143
   EMail: cmills@bbn.com


   Greg Ruth
   GTE Laboratories, Inc

   Phone: +1 617 466 2448
   EMail: gruth@gte.com




Brownlee, et. al.             Experimental                     [Page 37]