File: rfc2724.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 (1011 lines) | stat: -rw-r--r-- 37,951 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






Network Working Group                                       S. Handelman
Request for Comments: 2724                                    S. Stibler
Category: Experimental                                               IBM
                                                             N. Brownlee
                                              The University of Auckland
                                                                 G. Ruth
                                                     GTE Internetworking
                                                            October 1999


           RTFM: New Attributes for Traffic Flow Measurement

Status of this Memo

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

Copyright Notice

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

Abstract

   The RTFM Traffic Measurement Architecture provides a general
   framework for describing and measuring network traffic flows.  Flows
   are defined in terms of their Address Attribute values and measured
   by a 'Traffic Meter'.  This document discusses RTFM flows and the
   attributes which they can have, so as to provide a logical framework
   for extending the architecture by adding new attributes.

   Extensions described include Address Attributes such as DSCodePoint,
   SourceASN and DestASN, and Group Attributes such as short-term bit
   rates and turnaround times.  Quality of Service parameters for
   Integrated Services are also discussed.

Table of Contents

   1  Introduction .  . . . . . . . . . . . . . . . . . . . . . . . . 2
      1.1 RTFM's Definition of Flows  . . . . . . . . . . . . . . . . 3
      1.2 RTFM's Current Definition of Flows and their Attributes . . 3
      1.3 RTFM Flows, Integrated Services, IPPM and Research in Flows 4
   2  Flow Abstractions . . . . . . . . . . . . . . . . . . . . . . . 5
      2.1 Meter Readers and Meters  . . . . . . . . . . . . . . . . . 5
      2.2 Attribute Types . . . . . . . . . . . . . . . . . . . . . . 6
      2.3 Packet Traces . . . . . . . . . . . . . . . . . . . . . . . 7
      2.4 Aggregate Attributes  . . . . . . . . . . . . . . . . . . . 8



Handelman, et al.             Experimental                      [Page 1]

RFC 2724                  RTFM: New Attributes              October 1999


      2.5 Group Attributes  . . . . . . . . . . . . . . . . . . . . . 8
      2.6 Actions on Exceptions . . . . . . . . . . . . . . . . . . .10
   3  Extensions to the 'Basic' RTFM Meter  . . . . . . . . . . . . .10
      3.1 Flow table extensions . . . . . . . . . . . . . . . . . . .10
      3.2 Specifying Distributions in RuleSets  . . . . . . . . . . .11
      3.3 Reading Distributions . . . . . . . . . . . . . . . . . . .13
   4  Extensions to the Rules Table, Attribute Numbers  . . . . . . .13
   5  Security Considerations . . . . . . . . . . . . . . . . . . . .15
   6  References  . . . . . . . . . . . . . . . . . . . . . . . . . .16
   7  Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . .17
   8  Full Copyright Statement  . . . . . . . . . . . . . . . . . . .18

1  Introduction

   The Real-Time Flow Measurement (RTFM) Working Group (WG) has
   developed a system for measuring and reporting information about
   traffic flows in the Internet.  This document explores the definition
   of extensions to the flow measurements as currently defined in
   [RTFM-ARC]. The new attributes described in this document will be
   useful for monitoring network performance and will expand the scope
   of RTFM beyond simple measurement of traffic volumes.  A companion
   document to this memo will be written to define MIB structures for
   the new attributes.

   This memo was started in 1996 to advance the work of the RTFM group.
   The goal of this work is to produce a simple set of abstractions,
   which can be easily implemented and at the same time enhance the
   value of RTFM Meters.  This document also defines a method for
   organizing the flow abstractions to augment the existing RTFM flow
   table.

   Implementations of the RTFM Meter have been done by Nevil Brownlee in
   the University of Auckland, NZ, and Stephen Stibler and Sig Handelman
   at IBM in Hawthorne, NY, USA. The RTFM WG has also defined the role
   of the Meter Reader whose role is to retrieve flow data from the
   Meter.

   Note on flows and positioning of meters:

      A flow as it traverses the Internet may have some of its
      characteristics altered as it travels through Routers, Switches,
      and other network units.  It is important to note the spatial
      location of the Meter when referring to attributes of a flow.  An
      example, a server may send a sequence of packets with a definite
      order, and inter packet timing with a leaky bucket algorithm.  A
      meter reading downstream of the leaky bucket would record a set
      with minimal inter packet timing due to the leaky bucket.  At the
      client's location, the packets may arrive out of sequence, with



Handelman, et al.             Experimental                      [Page 2]

RFC 2724                  RTFM: New Attributes              October 1999


      the timings altered.  A meter at the client's location would
      record different attributes for the same flow.

1.1  RTFM's Definition of Flows

   The RTFM Meter architecture views a flow as a set of packets between
   two endpoints (as defined by their source and destination attribute
   values and start and end times), and as BI-DIRECTIONAL (i.e. the
   meter effectively monitors two sub-flows, one in each direction).

   Reasons why RTFM flows are bi-directional:

      -  The WG is interested in understanding the behavior of sessions
         between endpoints.

      -  The endpoint attribute values (the "Address" and "Type" ones)
         are the same for both directions; storing them in bi-
         directional flows reduces the meter's memory demands.

      -  'One-way' (uni-directional) flows are a degenerate case.
         Existing RTFM meters can handle this by using one of the
         computed attributes (e.g. FlowKind) to indicate direction.

1.2  RTFM's Current Definition of Flows and their Attributes

   Flows, as described in the "Architecture" document [RTFM-ARC] have
   the following properties:

   a. They occur between two endpoints, specified as sets of attribute
      values in the meter's current rule set.  A flow is completely
      identified by its set of endpoint attribute values.

   b. Each flow may also have values for "computed" attributes (Class
      and Kind).  These are directly derived from the endpoint attribute
      values.

   c. A new flow is created when a packet is to be counted that does not
      match the attributes of an existing flow. The meter records the
      time when this new flow is created.

   d. Attribute values in (a), (b) and (c) are set when the meter sees
      the first packet for the flow, and are never changed.

   e. Each flow has a "LastTime" attribute, which indicates the time the
      meter last saw a packet for the flow.






Handelman, et al.             Experimental                      [Page 3]

RFC 2724                  RTFM: New Attributes              October 1999


   f. Each flow has two packet and two byte counters, one for each flow
      direction (Forward and Backward).  These are updated as packets
      for the flow are observed by the meter.

   g. ALL the attributes have (more or less) the same meaning for a
      variety of protocols; IPX, AppleTalk, DECnet and CLNS as well as
      TCP/IP.

   Current flow attributes - as described above - fit very well into the
   SNMP data model.  They are either static, or are continuously updated
   counters.  They are NEVER reset.  In this document they will be
   referred to as "old-style" attributes.

   It is easy to add further "old-style" attributes, since they don't
   require any new features in the architecture.  For example:

      -  Count of the number of "lost" packets (determined by watching
         sequence number fields for packets in each direction; only
         available for protocols which have such sequence numbers).

      -  In the future, RTFM could coordinate directly with the Flow
         Label from the IPv6 header.

1.3  RTFM Flows, Integrated Services, IPPM and Research in Flows

   The concept of flows has been studied in various different contexts.
   For the purpose of extending RTFM, a starting point is the work of
   the Integrated Services WG. We will measure quantities that are often
   set by Integrated Services configuration programs.  We will look at
   the work of the Benchmarking/IP Performance Metrics Working Group,
   and also look at the work of Claffy, Braun and Polyzos [C-B-P]. We
   will demonstrate how RTFM can compute throughput, packet loss, and
   delays from flows.

   An example of the use of capacity and performance information is
   found in "The Use of RSVP with IETF Integrated Services" [IIS-RSVP].
   RSVP's use of Integrated Services revolves around Token Bucket Rate,
   Token Bucket Size, Peak Data Rate, Minimum Policed Unit, Maximum
   Packet Size, and the Slack term.  These are set by TSpec, ADspec and
   FLowspec (Integrated Services Keywords), and are used in
   configuration and operation of Integrated Services.  RTFM could
   monitor explicitly Peak Data Rate, Minimum Policed Unit, Maximum
   Packet Size, and the Slack term.  RTFM could infer details of the
   Token Bucket.  The WG will develop measures to work with these
   service metrics.  An initial implementation of IIS Monitoring has
   been developd at CEFRIEL in Italy [IIS-ACCT].





Handelman, et al.             Experimental                      [Page 4]

RFC 2724                  RTFM: New Attributes              October 1999


   RTFM will work with several traffic measurements identified by IPPM
   [IPPM-FRM]. There are three broad areas in which RTFM is useful for
   IPPM.

      -  An RTFM Meter could act as a passive device, gathering traffic
         and performance statistics at appropriate places in networks
         (server or client locations).

      -  RTFM could give detailed analyses of IPPM test flows that pass
         through the Network segment that RTFM is monitoring.

      -  RTFM could be used to identify the most-used paths in a network
         mesh, so that detailed IPPM work could be applied to these most
         used paths.

2  Flow Abstractions

   Performance attributes include throughput, packet loss, delays,
   jitter, and congestion measures.  RTFM will calculate these
   attributes in the form of extensions to the RTFM flow attributes
   according to three general classes:

      -  'Trace', attributes of individual packets in a flow or a
         segment of a flow (e.g. last packet size, last packet arrival
         time).

      -  'Aggregate', attributes derived from the flow taken as a whole
         (e.g. mean rate, max packet size, packet size distribution).

      -  'Group', attributes that depend on groups of packet values
         within the flow (e.g. inter-arrival times, short-term traffic
         rates).

   Note that attributes within each of these classes may have various
   types of values - numbers, distributions, time series, and so on.

2.1  Meter Readers and Meters

   A note on the relation between Meter Readers and Meters.

   Several of the measurements enumerated below can be implemented by a
   Meter Reader that is tied to a meter with very short response time
   and very high bandwidth.  If the Meter Reader and Meter can be
   arranged in such a way, RTFM could collect Packet Traces with time
   stamps and provide them directly to the Meter Reader for further
   processing.





Handelman, et al.             Experimental                      [Page 5]

RFC 2724                  RTFM: New Attributes              October 1999


   A more useful alternative is to have the Meter calculate some flow
   statistics locally.  This allows a looser coupling between the Meter
   and Meter Reader.  RTFM will monitor an 'extended attribute'
   depending upon settings in its Rule table.  RTFM will not create any
   "extended attribute" data without explicit instructions in the Rule
   table.

2.2  Attribute Types

   Section 2 described three different classes of attributes; this
   section considers the "data types" of these attributes.

   Packet Traces (as described below) are a special case in that they
   are tables with each row containing a sequence of values, each of
   varying type.  They are essentially 'compound objects' i.e. lists of
   attribute values for a string of packets.

   Aggregate attributes are like the 'old-style' attributes.  Their
   types are:

      -  Addresses, represented as byte strings (1 to 20 bytes long)

      -  Counters, represented as 64-bit unsigned integers

      -  Times, represented as 32-bit unsigned integers

   Addresses are saved when the first packet of a flow is observed.
   They do not change with time, and they are used as a key to find the
   flow's entry in the meter's flow table.

   Counters are incremented for each packet, and are never reset.  An
   analysis application can compute differences between readings of the
   counters, so as to determine rates for these attributes.  For
   example, if we read flow data at five-minute intervals, we can
   calculate five-minute packet and byte rates for the flow's two
   directions.

   Times are derived from the FirstTime for a flow, which is set when
   its first packet is observed.  LastTime is updated as each packet in
   the flow is observed.

   All the above types have the common feature that they are expressed
   as single values.  At least some of the new attributes will require
   multiple values.  If, for example, we are interested in inter-packet
   time intervals, we can compute an interval for every packet after the
   first.  If we are interested in packet sizes, a new value is obtained
   as each packet arrives.  When it comes to storing this data we have
   two options:



Handelman, et al.             Experimental                      [Page 6]

RFC 2724                  RTFM: New Attributes              October 1999


      -  As a distribution, i.e. in an array of 'buckets'.  This method
         is a compact representation of the data, with the values being
         stored as counters between a minimum and maximum, with defined
         steps in each bucket.  This fits the RTFM goal of compact data
         storage.

      -  As a sequence of single values.  This saves all the
         information, but does not fit well with the RTFM goal of doing
         as much data reduction as possible within the meter.

   Studies which would be limited by the use of distributions might well
   use packet traces instead.

   A method for specifying the distribution parameters, and for encoding
   the distribution so that it can be easily read, is described in
   section 3.2.

2.3  Packet Traces

   The simplest way of collecting a trace in the meter would be to have
   a new attribute called, say, "PacketTrace". This could be a table,
   with a column for each property of interest.  For example, one could
   trace:

      -  Packet Arrival time (TimeTicks from sysUpTime, or microseconds
         from FirstTime for the flow).

      -  Packet Direction (Forward or Backward)

      -  Packet Sequence number (for protocols with sequence numbers)

      -  Packet Flags (for TCP at least)

   Note:  The following implementation proposal is for the user who is
   familiar with the writing of rule sets for the RTFM Meter.

      To add a row to the table, we only need a rule which PushPkts the
      PacketTrace attribute.  To use this, one would write a rule set
      which selected out a small number of flows of interest, with a
      'PushPkt PacketTrace' rule for each of them.  A MaxTraceRows
      default value of 2000 would be enough to allow a Meter Reader to
      read one-second ping traces every 10 minutes or so.  More
      realistically, a MaxTraceRows of 500 would be enough for one-
      minute pings, read once each hour.

   Packet traces are already implemented by the RMON MIB [RMON-MIB,
   RMON2-MIB], in the Packet Capture Group.  They are therefore a low
   priority for RTFM.



Handelman, et al.             Experimental                      [Page 7]

RFC 2724                  RTFM: New Attributes              October 1999


2.4  Aggregate Attributes

   RTFM's "old-style" flow attributes count the bytes and packets for
   packets which match the rule set for an individual flow.  In addition
   to these totals, for example, RTFM could calculate Packet Size
   statistics.  This data can be stored as distributions, though it may
   sometimes be sufficient to simply keep a maximum value.

   As an example, consider Packet Size.  RTFM's packet flows can be
   examined to determine the maximum packet size found in a flow.  This
   will give the Network Operator an indication of the MTU being used in
   a flow.  It will also give an indication of the sensitivity to loss
   of a flow, for losing large packets causes more data to be
   retransmitted.

   Note that aggregate attributes are a simple extension of the 'old-
   style' attributes; their values are never reset.  For example, an
   array of counters could hold a 'packet size' distribution.  The
   counters continue to increase, a meter reader will collect their
   values at regular intervals, and an analysis application will compute
   and display distributions of the packet size for each collection
   interval.

2.5  Group Attributes

   The notion of group attributes is to keep simple statistics for
   measures that involve more than one packet.  This section describes
   some group attributes which it is feasible to implement in a traffic
   meter, and which seem interesting and useful.

   Short-term bit rate - The data could also be recorded as the maximum
   and minimum data rate of the flow, found over specific time periods
   during the lifetime of a flow; this is a special kind of
   'distribution'.  Bit rate could be used to define the throughput of a
   flow, and if the RTFM flow is defined to be the sum of all traffic in
   a network, one can find the throughput of the network.

   If we are interested in '10-second' forward data rates, the meter
   might compute this for each flow of interest as follows:

      -  maintain an array of counters to hold the flow's 10-second data
         rate distribution.

      -  every 10 seconds, compute and save 10-second octet count, and
         save a copy of the flow's forward octet counter.






Handelman, et al.             Experimental                      [Page 8]

RFC 2724                  RTFM: New Attributes              October 1999


   To achieve this, the meter will have to keep a list of aggregate
   flows and the intervals at which they require processing.  Careful
   programming is needed to achieve this, but provided the meter is not
   asked to do it for very large numbers of flows, it has been
   successfully implemented.

   Inter-arrival times.  The Meter knows the time that it encounters
   each individual packet.  Statistics can be kept to record the inter-
   arrival times of the packets, which would give an indication of the
   jitter found in the Flow.

   Turn-around statistics.  Sine the Meter knows the time that it
   encounters each individual packet, it can produce statistics of the
   time intervals between packets in opposite directions are observed on
   the network.  For protocols such as SNMP (where every packet elicits
   an answering packet) this gives a good indication of turn-around
   times.

   Subflow analysis.  Since the choice of flow endpoints is controlled
   by the meter's rule set, it is easy to define an aggregate flow, e.g.
   "all the TCP streams between hosts A and B."  Preliminary
   implementation work suggests that - at least for this case - it
   should be possible for the meter to maintain a table of information
   about all the active streams.  This could be used to produce at least
   the following attributes:

      -  Number of streams, e.g. streams active for n-second intervals.
         Determined for TCP and UDP using source-dest port number pairs.

      -  Number of TCP bytes, determined by taking difference of TCP
         sequence numbers for each direction of the aggreagate flow.

   IIS attributes.  Work at CEFRIEL [IIS-ACCT] has produced a traffic
   meter with a rule set modified 'on the fly' so as to maintain a list
   of RSVP-reserved flows.  For such flows the following attributes have
   been implemented (these quantities are defined in [GUAR-QOS]):















Handelman, et al.             Experimental                      [Page 9]

RFC 2724                  RTFM: New Attributes              October 1999


      - QoSService:          Service class for the flow
                               (guaranteed, controlled load)
      - QoSStyle:            Reservation setup style
                               (wildcard filter, fixed filter,
                               shared explicit)
      - QoSRate:             [byte/s] rate for flows with
                               guaranteed service
      - QoSSlackTerm:        [microseconds] Slack Term QoS parameter
                               for flows with guaranteed service
      - QoSTokenBucketRate:  [byte/s] Token Bucket Rate QoS parameter
                               for flows with guaranteed or
                               controlled load service

      The following are also being considered:

      - QoSTokenBucketSize:  [byte] Size of Token Bucket

      - QoSPeakDataRate:     [byte/s] Maximum rate for incoming data

      - QoSMinPolicedUnit:   [byte] IP datagrams less than this are
                               counted as being this size
      - QoSMaxDatagramSize:  [byte] Size of biggest datagram which
                               conforms to the traffic specification
2.6  Actions on Exceptions

   Some users of RTFM have requested the ability to mark flows as having
   High Watermarks.  The existence of abnormal service conditions, such
   as non-ending flow, a flow that exceeds a given limit in traffic
   (e.g. a flow that is exhausting the capacity of the line that carries
   it) would cause an ALERT to be sent to the Meter Reader for
   forwarding to the Manager.  Operations Support could define service
   situations in many different environments.  This is an area for
   further discussion on Alert and Trap handling.

3  Extensions to the 'Basic' RTFM Meter

   The Working Group has agreed that the basic RTFM Meter will not be
   altered by the addition of the new attributes of this document.  This
   section describes the extensions needed to implement the new
   attributes.

3.1  Flow table extensions

   The architecture of RTFM has defined the structure of flows, and this
   memo does not change that structure.  The flow table could have
   ancillary tables called "Distribution Tables" and "Trace Tables,"





Handelman, et al.             Experimental                     [Page 10]

RFC 2724                  RTFM: New Attributes              October 1999


   these would contain rows of values and or actions as defined above.
   Each entry in these tables would be marked with the number of its
   corresponding flow in the RTFM flow table.

   Note:  The following section is for the user who is familiar with the
   writing of rule sets for the RTFM Meter.

      In order to identify the data in a Packet Flow Table, the
      attribute name could be pushed into a string at the head of each
      row.  For example, if a table entry has "To Bit Rate" for a
      particular flow, the "ToBitRate" string would be found at the head
      of the row.  (An alternative method would be to code an
      identification value for each extended attribute and push that
      value into the head of the row.)  See section 4.  for an inital
      set of ten extended flow attributes.

3.2  Specifying Distributions in RuleSets

   At first sight it would seem neccessary to add extra features to the
   RTFM Meter architecture to support distributions.  This, however, is
   not neccessarily the case.

   What is actually needed is a way to specify, in a ruleset, the
   distribution parameters.  These include the number of counters, the
   lower and upper bounds of the distribution, whether it is linear or
   logarithmic, and any other details (e.g. the time interval for
   short-term rate attributes).

   Any attribute which is distribution-valued needs to be allocated a
   RuleAttributeNumber value.  These will be chosen so as to extend the
   list already in the RTFM Meter MIB document [RTFM-MIB].

   Since distribution attributes are multi-valued it does not make sense
   to test them.  This means that a PushPkt (or PushPkttoAct) action
   must be executed to add a new value to the distribution.  The old-
   style attributes use the 'mask' field to specify which bits of the
   value are required, but again, this is not the case for
   distributions.  Lastly, the MatchedValue ('value') field of a PushPkt
   rule is never used.  Overall, therefore, the 'mask' and 'value'
   fields in the PushPkt rule are available to specify distribution
   parameters.

   Both these fields are at least six bytes long, the size of a MAC
   address.  All we have to do is specify how these bytes should be
   used!  As a starting point, the following is proposed (bytes are
   numbered left-to-right.





Handelman, et al.             Experimental                     [Page 11]

RFC 2724                  RTFM: New Attributes              October 1999


   Mask bytes:
        1    Transform        1 = linear, 2 = logarithmic
        2    Scale Factor     Power of 10 multiplier for Limits
                                  and Counts
      3-4    Lower Limit      Highest value for first bucket
      5-6    Upper Limit      Highest value for last bucket

   Value bytes:
        1    Buckets          Number of buckets.  Does not include
                                  the 'overflow' bucket
        2    Parameter-1      } Parameter use depends
      3-4    Parameter-2      } on distribution-valued
      5-6    Parameter-3      } attribute

   For example, experiments with NeTraMet have used the following rules:

     FromPacketSize     & 1.0.25!1500 = 60.0!0:   PushPkttoAct, Next;

     ToInterArrivalTime &  2.3.1!1800 = 60.0.0!0: PushPkttoAct, Next;

     FromBitRate        & 2.3.1!10000 = 60.5.0!0: PushPkttoAct, Next;

   In these mask and value fields a dot indicates that the preceding
   number is a one-byte integer, the exclamation marks indicate that the
   preceding number is a two-byte integer, and the last number is two
   bytes wide since this was the width of the preceding field.  (Note
   that this convention follows that for IP addresses - 130.216 means
   130.216.0.0).

   The first rule specifies that a distribution of packet sizes is to be
   built.  It uses an array of 60 buckets, storing values from 1 to 1500
   bytes (i.e. linear steps of 25 bytes each bucket).  Any packets with
   size greater than 1500 will be counted in the 'overflow' bucket,
   hence there are 61 counters for the distribution.

   The second rule specifies an interarrival-time distribution, using a
   logarithmic scale for an array of 60 counters (and an overflow
   bucket) for rates from 1 ms to 1.8 s.  Arrival times are measured in
   microseconds, hence the scale factor of 3 indicates that the limits
   are given in milliseconds.

   The third rule specifies a bit-rate distribution, with the rate being
   calculated every 5 seconds (parameter 1).  A logarithmic array of 60
   counters (and an overflow bucket) are used for rates from 1 kbps to
   10 Mbps.  The scale factor of 3 indicates that the limits are given
   in thousands of bits per second (rates are measured in bps).





Handelman, et al.             Experimental                     [Page 12]

RFC 2724                  RTFM: New Attributes              October 1999


   These distribution parameters will need to be stored in the meter so
   that they are available for building the distribution.  They will
   also need to be read from the meter and saved together with the other
   flow data.

3.3  Reading Distributions

   Since RTFM flows are bi-directional, each distribution-valued
   quantity (e.g. packet size, bit rate, etc.)  will actually need two
   sets of counters, one for packets travelling in each direction.  It
   is tempting to regard these as components of a single 'distribution',
   but in many cases only one of the two directions will be of interest;
   it seems better to keep them in separate distributions.  This is
   similar to the old-style counter-valued attributes such as toOctets
   and fromOctets.

   A distribution should be read by a meter reader as a single,
   structured object.  The components of a distribution object are:

      -  'mask' and 'value' fields from the rule which created the
         distribution

      -  sequence of counters ('buckets' + overflow)

   These can be easily collected into a BER-encoded octet string, and
   would be read and referred to as a 'distribution'.

4  Extensions to the Rules Table, Attribute Numbers

   The Rules Table of "old-style" attributes will be extended for the
   new flow types.  A list of actions, and keywords, such as
   "ToBitRate", "ToPacketSize", etc.  will be developed and used to
   inform an RTFM meter to collect a set of extended values for a
   particular flow (or set of flows).

   Note:  An implementation suggestion.

      Value 65 is used for 'Distributions', which has one bit set for
      each distribution-valued attribute present for the flow, using bit
      0 for attribute 66, bit 1 for attribute 67, etc.

   Here are ten possible distribution-valued attributes numbered
   according to RTFM WG consensus at the 1997 meeting in Munich:

      ToPacketSize(66)         size of PDUs in bytes (i.e. number
      FromPacketSize(67)         of bytes actually transmitted)





Handelman, et al.             Experimental                     [Page 13]

RFC 2724                  RTFM: New Attributes              October 1999


      ToInterarrivalTime(68)   microseconds between successive packets
      FromInterarrivalTime(69)   travelling in the same direction

      ToTurnaroundTime(70)     microseconds between successive packets
      FromTurnaroundTime(71)     travelling in opposite directions

      ToBitRate(72)            short-term flow rate in bits per second
      FromBitRate(73)            Parameter 1 = rate interval in seconds

      ToPDURate(74)            short-term flow rate in PDUs per second
      FromPDURate(75)            Parameter 1 = rate interval in seconds

      (76 .. 97)               other distributions

   It seems reasonable to allocate a further group of numbers for the
   IIS attributes described above:

      QoSService(98)
      QoSStyle(99)
      QoSRate(100)
      QoSSlackTerm(101)
      QoSTokenBucketRate(102)
      QoSTokenBucketSize(103)
      QoSPeakDataRate(104)
      QoSMinPolicedUnit(105)
      QoSMaxPolicedUnit(106)

   The following attributes have also been implemented in NetFlowMet, a
   version of the RTFM traffic meter:

      MeterID(112)      Integer identifying the router producing
                           NetFlow data (needed when NetFlowMet takes
                           data from several routers)
      SourceASN(113)    Autonomous System Number for flow's source
      SourcePrefix(114) CIDR width used by router for determining
                           flow's source network
      DestASN(115)      Autonomous System Number for flow's destination
      DestPrefix(116)   CIDR width used by router for determining
                           flow's destination network

   Some of the above, e.g. SourceASN and DestASN, might sensibly be
   allocated attribute numbers below 64, making them part of the 'base'
   RTFM meter attributes.








Handelman, et al.             Experimental                     [Page 14]

RFC 2724                  RTFM: New Attributes              October 1999


   To support use of the RTFM meter as an 'Edge Device' for implementing
   Differentiated Services, and/or for metering traffic carried via such
   services, one more attribute will be useful:

      DSCodePoint(118)  DS Code Point (6 bits) for packets in this flow

   Since the DS Code Point is a single field within a packet's IP
   header, it is not possible to have both Source- and Dest-CodePoint
   attributes.  Possible uses of DSCodePoint include aggregating flows
   using the same Code Points, and separating flows having the same
   end-point addresses but using different Code Points.

5  Security Considerations

   The attributes considered in this document represent properties of
   traffic flows; they do not present any security issues in themselves.
   The attributes may, however, be used in measuring the behaviour of
   traffic flows, and the collected traffic flow data could be of
   considerable value.  Suitable precautions should be taken to keep
   such data safe.































Handelman, et al.             Experimental                     [Page 15]

RFC 2724                  RTFM: New Attributes              October 1999


6  References

   [C-B-P]     Claffy, K., Braun, H-W, Polyzos, G., "A Parameterizable
               Methodology for Internet Traffic Flow Profiling," IEEE
               Journal on Selected Areas in Communications, Vol. 13, No.
               8, October 1995.

   [GUAR-QOS]  Shenker, S., Partridge, C. and R. Guerin, "Specification
               of Guaranteed Quality of Service", RFC 2212, September
               1997.

   [IIS-ACCT]  Maiocchi, S: "NeTraMet & NeMaC for IIS Accounting:
               Users' Guide", CEFRIEL, Milan, 5 May 1998.  (See also
               http://www.cefriel.it/ntw)

   [IIS-RSVP]  Wroclawski, J., "The Use of RSVP with IETF Integrated
               Services", RFC 2210, September 1997.

   [IPPM-FRM]  Paxson, V., Almes, G., Mahdavi, J. and  Mathis, M.,
               "Framework for IP Performance Metrics", RFC 2330, May
               1998.

   [RMON-MIB]  Waldbusser, S., "Remote Network Monitoring Management
               Information Base", RFC 1757, February 1995.

   [RMON2-MIB] Waldbusser, S., "Remote Network Monitoring Management
               Information Base Version 2 using SMIv2", RFC 2021,
               January 1997.

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

   [RTFM-MIB]  Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC
               2720, October 1999.

















Handelman, et al.             Experimental                     [Page 16]

RFC 2724                  RTFM: New Attributes              October 1999


7  Authors' Addresses

   Sig Handelman
   IBM Research Division
   T.J. Watson Research Center
   P.O. Box 704
   Yorktown Heights, NY 10598

   Phone: +1 914 784 7626
   EMail: swhandel@us.ibm.com


   Stephen Stibler
   IBM Research Division
   T.J. Watson Research Center
   P.O. Box 704
   Yorktown Heights, NY 10598

   Phone: +1 914 784 7191
   EMail: stibler@us.ibm.com


   Nevil Brownlee
   Information Technology Systems & Services
   The University of Auckland
   Private Bag 92-019
   Auckland, New Zealand

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


   Greg Ruth
   GTE Internteworking
   3 Van de Graaff Drive
   P.O. Box 3073
   Burlington, MA 01803, U.S.A.

   Phone: +1 781 262 4831
   EMail: gruth@bbn.com











Handelman, et al.             Experimental                     [Page 17]

RFC 2724                  RTFM: New Attributes              October 1999


8.  Full Copyright Statement

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

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

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

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

Acknowledgement

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



















Handelman, et al.             Experimental                     [Page 18]