File: rfc2285.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 (1403 lines) | stat: -rw-r--r-- 43,130 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






Network Working Group                                      R. Mandeville
Request for Comments: 2285                 European Network Laboratories
Category: Informational                                    February 1998


           Benchmarking Terminology for LAN Switching Devices

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2. Existing definitions . . . . . . . . . . . . . . . . . . . . . . 2
   3. Term definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
      3.1 Devices. . . . . . . . . . . . . . . . . . . . . . . . . . . 3
         3.1.1 Device under test (DUT) . . . . . . . . . . . . . . . . 3
         3.1.2 System under test (SUT) . . . . . . . . . . . . . . . . 3
      3.2 Traffic orientation. . . . . . . . . . . . . . . . . . . . . 4
         3.2.1 Unidirectional traffic. . . . . . . . . . . . . . . . . 4
         3.2.2 Bidirectional traffic . . . . . . . . . . . . . . . . . 5
      3.3 Traffic distribution . . . . . . . . . . . . . . . . . . . . 6
         3.3.1 Non-meshed traffic. . . . . . . . . . . . . . . . . . . 6
         3.3.2 Partially meshed traffic. . . . . . . . . . . . . . . . 7
         3.3.3 Fully meshed traffic. . . . . . . . . . . . . . . . . . 8
      3.4 Bursts . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
         3.4.1 Burst . . . . . . . . . . . . . . . . . . . . . . . . . 9
         3.4.2 Burst size . . . . . . . . . . . . . . . . . . . . . . 10
         3.4.3 Inter-burst gap (IBG). . . . . . . . . . . . . . . . . 10
      3.5 Loads . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
         3.5.1 Intended load (Iload)  . . . . . . . . . . . . . . . . 11
         3.5.2 Offered load (Oload) . . . . . . . . . . . . . . . . . 12
         3.5.3 Maximum offered load (MOL) . . . . . . . . . . . . . . 13
         3.5.4 Overloading  . . . . . . . . . . . . . . . . . . . . . 14
      3.6 Forwarding rates  . . . . . . . . . . . . . . . . . . . . . 15
         3.6.1 Forwarding rate (FR) . . . . . . . . . . . . . . . . . 15
         3.6.2 Forwarding rate at maximum offered load (FRMOL). . . . 16
         3.6.3 Maximum forwarding rate (MFR). . . . . . . . . . . . . 16
      3.7 Congestion control  . . . . . . . . . . . . . . . . . . . . 17
         3.7.1 Backpressure . . . . . . . . . . . . . . . . . . . . . 17
         3.7.2 Forward pressure . . . . . . . . . . . . . . . . . . . 18



Mandeville                   Informational                      [Page 1]

RFC 2285                Benchmarking Terminology           February 1998


         3.7.3 Head of line blocking  . . . . . . . . . . . . . . . . 19
      3.8 Address handling  . . . . . . . . . . . . . . . . . . . . . 20
         3.8.1 Address caching capacity . . . . . . . . . . . . . . . 20
         3.8.2 Address learning rate  . . . . . . . . . . . . . . . . 20
         3.8.3 Flood count  . . . . . . . . . . . . . . . . . . . . . 21
      3.9 Errored frame filtering . . . . . . . . . . . . . . . . . . 21
         3.9.1 Errored frames . . . . . . . . . . . . . . . . . . . . 22
      3.10 Broadcasts . . . . . . . . . . . . . . . . . . . . . . . . 22
         3.10.1 Broadcast forwarding rate at maximum load . . . . . . 22
         3.10.2 Broadcast latency . . . . . . . . . . . . . . . . . . 23
   4. Security Considerations . . . . . . . . . . . . . . . . . . . . 24
   5. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 24
   6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . 24
   7. Author's Address. . . . . . . . . . . . . . . . . . . . . . . . 24
   8. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 25

1. Introduction

   This document is intended to provide terminology for the benchmarking
   of local area network (LAN) switching devices.  It extends the
   terminology already defined for benchmarking network interconnect
   devices in RFCs 1242 and 1944 to switching devices.

   Although it might be found useful to apply some of the terms defined
   here to a broader range of network interconnect devices, this RFC
   primarily deals with devices which switch frames at the Medium Access
   Control (MAC) layer.  It defines terms in relation to the traffic put
   to use when benchmarking switching devices, forwarding performance,
   congestion control, latency, address handling and filtering.

2.  Existing definitions

   RFC 1242 "Benchmarking Terminology for Network Interconnect Devices"
   should be consulted before attempting to make use of this document.
   RFC 1944 "Benchmarking Methodology for Network Interconnect Devices"
   contains discussions of a number of terms relevant to the
   benchmarking of switching devices and should also be consulted.

   For the sake of clarity and continuity this RFC adopts the template
   for definitions set out in Section 2 of RFC 1242.  Definitions are
   indexed and grouped together in sections for ease of reference.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.






Mandeville                   Informational                      [Page 2]

RFC 2285                Benchmarking Terminology           February 1998


3. Term definitions

3.1 Devices

   This group of definitions applies to all types of networking devices.

3.1.1 Device under test (DUT)

   Definition:

      The network forwarding device to which stimulus is offered and
      response measured.

   Discussion:

      A single stand-alone or modular unit which receives frames on one
      or more of its interfaces and then forwards them to one or more
      interfaces according to the addressing information contained in
      the frame.

   Measurement units:

      n/a

   Issues:

   See Also:

      system under test (SUT) (3.1.2)

3.1.2 System Under Test (SUT)

   Definition:

      The collective set of network devices to which stimulus is offered
      as a single entity and response measured.

   Discussion:

      A system under test may be comprised of a variety of networking
      devices.  Some devices may be active in the forwarding decision-
      making process, such as routers or switches; other devices may be
      passive such as a CSU/DSU.  Regardless of constituent components,
      the system is treated as a singular entity to which stimulus is
      offered and response measured.






Mandeville                   Informational                      [Page 3]

RFC 2285                Benchmarking Terminology           February 1998


   Measurement units:

      n/a

   Issues:

   See Also:

      device under test (DUT) (3.1.1)

3.2 Traffic orientation

   This group of definitions applies to the traffic presented to the
   interfaces of a DUT/SUT and indicates whether the interfaces are
   receiving only, transmitting only, or both receiving and
   transmitting.

3.2.1 Unidirectional traffic

   Definition:

      When all frames presented to the input interfaces of a DUT/SUT are
      addressed to output interfaces which do not themselves receive any
      frames.

   Discussion:

      This definition conforms to the discussion in section 16 of RFC
      1944 which describes how unidirectional traffic can be offered to
      a DUT/SUT to measure throughput.  Unidirectional traffic is also
      appropriate for:

      -the measurement of the minimum inter-frame gap -the creation of
      many-to-one or one-to-many interface overload -the detection of
      head of line blocking -the measurement of forwarding rates and
      throughput when congestion control mechanisms are active.

      When a tester offers unidirectional traffic to a DUT/SUT reception
      and transmission are handled by different interfaces or sets of
      interfaces of the DUT/SUT.  All frames received from the tester by
      the DUT/SUT are transmitted back to the tester from interfaces
      which do not themselves receive any frames.

      It is useful to distinguish traffic orientation and traffic
      distribution when considering traffic patterns used in device
      testing.  Unidirectional traffic, for example, is traffic
      orientated in a single direction between mutually exclusive sets
      of source and destination interfaces of a DUT/SUT.  Such traffic,



Mandeville                   Informational                      [Page 4]

RFC 2285                Benchmarking Terminology           February 1998


      however, can be distributed between interfaces in different ways.
      When traffic is sent to two or more interfaces from an external
      source and then forwarded by the DUT/SUT to a single output
      interface the traffic orientation is unidirectional and the
      traffic distribution between interfaces is many-to-one.  Traffic
      can also be sent to a single input interface and forwarded by the
      DUT/SUT to two or more output interfaces to achieve a one-to-many
      distribution of traffic.

      Such traffic distributions can also be combined to test for head
      of line blocking or to measure forwarding rates and throughput
      when congestion control mechanisms are active.

      When a DUT/SUT is equipped with interfaces running at different
      media rates the number of input interfaces required to load or
      overload an output interface or interfaces will vary.

      It should be noted that measurement of the minimum inter-frame gap
      serves to detect violations of the IEEE 802.3 standard.

   Issues:

      half duplex / full duplex

   Measurement units:

      n/a

   See Also:

      bidirectional traffic (3.2.2)
      non-meshed traffic (3.3.1)
      partially meshed traffic (3.3.2)
      fully meshed traffic (3.3.3)
      congestion control (3.7)
      head of line blocking (3.7.3)

3.2.2 Bidirectional traffic

   Definition:

      Frames presented to a DUT/SUT such that every receiving interface
      also transmits.

   Discussion:

      This definition conforms to the discussion in section 14 of RFC
      1944.



Mandeville                   Informational                      [Page 5]

RFC 2285                Benchmarking Terminology           February 1998


      When a tester offers bidirectional traffic to a DUT/SUT all the
      interfaces which receive frames from the tester also transmit
      frames back to the tester.

      Bidirectional traffic MUST be offered when measuring the
      throughput or forwarding rate of full duplex interfaces of a
      switching device.

   Issues:

      truncated binary exponential back-off algorithm

   Measurement units:

      n/a

   See Also:

      unidirectional traffic (3.2.1)
      non-meshed traffic (3.3.1)
      partially meshed traffic (3.3.2)
      fully meshed traffic (3.3.3)

3.3 Traffic distribution

   This group of definitions applies to the distribution of frames
   forwarded by a DUT/SUT.

3.3.1 Non-meshed traffic

   Definition:

      Frames offered to a single input interface and addressed to a
      single output interface of a DUT/SUT where input and output
      interfaces are grouped in mutually exclusive pairs.

   Discussion:

      In the simplest instance of non-meshed traffic all frames are
      offered to a single input interface and addressed to a single
      output interface.  The one-to-one mapping of input to output
      interfaces required by non-meshed traffic can be extended to
      multiple mutually exclusive pairs of input and output interfaces.

   Measurement units:

      n/a




Mandeville                   Informational                      [Page 6]

RFC 2285                Benchmarking Terminology           February 1998


   Issues:

      half duplex / full duplex

   See Also:

      unidirectional traffic (3.2.1)
      bidirectional traffic (3.2.2)
      partially meshed traffic (3.3.2.)
      fully meshed traffic (3.3.3)
      burst (3.4.1)

3.3.2 Partially meshed traffic

   Definition:

      Frames offered to one or more input interfaces of a DUT/SUT and
      addressed to one or more output interfaces where input and output
      interfaces are mutually exclusive and mapped one-to-many, many-
      to-one or many-to-many.

   Discussion:

      This definition follows from the discussion in section 16 of RFC
      1944 on multi-port testing.  Partially meshed traffic allows for
      one-to-many, many-to-one or many-to-many mappings of input to
      output interfaces and readily extends to configurations with
      multiple switching devices linked together over backbone
      connections.

      It should be noted that partially meshed traffic can load backbone
      connections linking together two switching devices or systems more
      than fully meshed traffic.  When offered partially meshed traffic
      devices or systems can be set up to forward all of the frames they
      receive to the opposite side of the backbone connection whereas
      fully meshed traffic requires at least some of the offered frames
      to be forwarded locally, that is to the interfaces of the DUT/SUT
      receiving them.  Such frames will not traverse the backbone
      connection.

   Measurement units:

      n/a

   Issues:

      half duplex / full duplex




Mandeville                   Informational                      [Page 7]

RFC 2285                Benchmarking Terminology           February 1998


   See Also:

      unidirectional traffic (3.2.1)
      bidirectional traffic (3.2.2)
      non-meshed traffic (3.3.1)
      fully meshed traffic (3.3.3)
      burst (3.4.1)

3.3.3 Fully meshed traffic

   Definition:

      Frames offered to a designated number of interfaces of a DUT/SUT
      such that each one of the interfaces under test receives frames
      addressed to all of the other interfaces under test.

   Discussion:

      As with bidirectional partially meshed traffic, fully meshed
      traffic requires each one the interfaces of a DUT/SUT to both
      receive and transmit frames.  But since the interfaces are not
      divided into groups as with partially meshed traffic every
      interface forwards frames to and receives frames from every other
      interface.  The total number of individual input/output interface
      pairs when traffic is fully meshed over n switched interfaces
      equals n x (n - 1).  This compares with n x (n / 2) such interface
      pairs when traffic is partially meshed.

      Fully meshed traffic on half duplex interfaces is inherently
      bursty since interfaces must interrupt transmission whenever they
      receive frames.  This kind of bursty meshed traffic is
      characteristic of real network traffic and can be advantageously
      used to diagnose a DUT/SUT by exercising many of its component
      parts simultaneously.  Additional inspection may be warranted to
      correlate the frame forwarding capacity of a DUT/SUT when offered
      meshed traffic and the behavior of individual elements such as
      input or output buffers, buffer allocation mechanisms, aggregate
      switching capacity, processing speed or medium access control.

      The analysis of forwarding rate measurements presents a challenge
      when offering bidirectional or fully meshed traffic since the rate
      at which the tester can be observed to transmit frames to the
      DUT/SUT may be smaller than the rate at which it intends to
      transmit due to collisions on half duplex media or the action of
      congestion control mechanisms.  This makes it important to take
      account of both the intended and offered loads defined in sections
      3.5.1.and 3.5.2 below when reporting the results of such
      forwarding rate measurements.



Mandeville                   Informational                      [Page 8]

RFC 2285                Benchmarking Terminology           February 1998


      When offering bursty meshed traffic to a DUT/SUT a number of
      variables have to be considered.  These include frame size, the
      number of frames within bursts, the interval between bursts as
      well as the distribution of load between incoming and outgoing
      traffic.  Terms related to bursts are defined in section 3.4
      below.

   Measurement units:

      n/a

   Issues:

      half duplex / full duplex

   See Also:

      unidirectional traffic (3.2.1)
      bidirectional traffic (3.2.2)
      non-meshed traffic (3.3.1)
      partially meshed traffic (3.3.2)
      burst (3.4.1)
      intended load (3.5.1)
      offered load (3.5.2)

3.4 Bursts

   This group of definitions applies to the intervals between frames or
   groups of frames offered to the DUT/SUT.

3.4.1 Burst

   Definition:

      A sequence of frames transmitted with the minimum legal inter-
      frame gap.

   Discussion:

      This definition follows from discussions in section 3.16 of RFC
      1242 and section 21 of RFC 1944 which describes cases where it is
      useful to consider isolated frames as single frame bursts.

   Measurement units:

      n/a

   Issues:



Mandeville                   Informational                      [Page 9]

RFC 2285                Benchmarking Terminology           February 1998


   See Also:

      burst size (3.4.2)
      inter-burst gap (IBG) (3.4.3)

3.4.2 Burst size

   Definition:

      The number of frames in a burst.

   Discussion:

      Burst size can range from one to infinity.  In unidirectional
      traffic as well as in bidirectional or meshed traffic on full
      duplex interfaces there is no theoretical limit to burst length.
      When traffic is bidirectional or meshed bursts on half duplex
      media are finite since interfaces interrupt transmission
      intermittently to receive frames.

      On real networks burst size will normally increase with window
      size.  This makes it desirable to test devices with small as well
      as large burst sizes.

   Measurement units:

      number of N-octet frames

   Issues:

   See Also:

      burst (3.4.1)
      inter-burst gap (IBG) (3.4.3)

3.4.3 Inter-burst gap (IBG)

   Definition:

      The interval between two bursts.

   Discussion:

      This definition conforms to the discussion in section 20 of RFC
      1944 on bursty traffic.






Mandeville                   Informational                     [Page 10]

RFC 2285                Benchmarking Terminology           February 1998


      Bidirectional and meshed traffic are inherently bursty since
      interfaces share their time between receiving and transmitting
      frames.  External sources offering bursty traffic for a given
      frame size and burst size must adjust the inter-burst gap to
      achieve a specified average rate of frame transmission.

   Measurement units:

      nanoseconds
      microseconds
      milliseconds
      seconds

   Issues:

   See Also:

      burst (3.4.1)
      burst size (3.4.2)

3.5 Loads

   This group of definitions applies to the rates at which traffic is
   offered to any DUT/SUT.

3.5.1 Intended load (Iload)

   Definition:

      The number of frames per second that an external source attempts
      to transmit to a DUT/SUT for forwarding to a specified output
      interface or interfaces.

   Discussion:

      Collisions on CSMA/CD links or the action of congestion control
      mechanisms can effect the rate at which an external source of
      traffic transmits frames to a DUT/SUT.  This makes it useful to
      distinguish the load that an external source attempts to apply to
      a DUT/SUT and the load it is observed or measured to apply.

      In the case of Ethernet an external source of traffic MUST
      implement the truncated binary exponential back-off algorithm to
      ensure that it is accessing the medium legally







Mandeville                   Informational                     [Page 11]

RFC 2285                Benchmarking Terminology           February 1998


   Measurement units:

      bits per second
      N-octets per second
      (N-octets per second / media_maximum-octets per second) x 100

   Issues:

   See Also:

      burst (3.4.1)
      inter-burst gap (3.4.3)
      offered load (3.5.2)

3.5.2 Offered load (Oload)

   Definition:

      The number of frames per second that an external source can be
      observed or measured to transmit to a DUT/SUT for forwarding to a
      specified output interface or interfaces.

   Discussion:

      The load which an external device can be observed to apply to a
      DUT/SUT may be less than the intended load due to collisions on
      half duplex media or the action of congestion control mechanisms.
      This makes it important to distinguish intended and offered load
      when analyzing the results of forwarding rate measurements using
      bidirectional or fully meshed traffic.

      Frames which are not successfully transmitted by an external
      source of traffic to a DUT/SUT MUST NOT be counted as transmitted
      frames when measuring forwarding rates.

      The frame count on an interface of a DUT/SUT may exceed the rate
      at which an external device offers frames due to the presence of
      spanning tree BPDUs (Bridge Protocol Data Units) on 802.1D-
      compliant switches or SNMP frames.  Such frames should be treated
      as modifiers as described in section 11 of RFC 1944.

      Offered load MUST be indicated when reporting the results of
      forwarding rate measurements.








Mandeville                   Informational                     [Page 12]

RFC 2285                Benchmarking Terminology           February 1998


   Measurement units:

      bits per second
      N-octets per second
      (N-octets per second / media_maximum-octets per second) x 100

   Issues:

      token ring

   See Also:

      bidirectional traffic (3.2.2)
      fully meshed traffic (3.3.3)
      intended load (3.5.1)
      forwarding rate (3.6.1)

3.5.3 Maximum offered load (MOL)

   Definition:

      The highest number of frames per second that an external source
      can transmit to a DUT/SUT for forwarding to a specified output
      interface or interfaces.

   Discussion:

      The maximum load that an external device can apply to a DUT/SUT
      may not equal the maximum load allowed by the medium.  This
      will be the case  when an external source lacks the resources
      to transmit frames at the minimum legal inter-frame gap or when
      it has sufficient resources to transmit frames below the
      minimum legal inter-frame gap.  Moreover, maximum load may vary
      with respect to parameters other than a medium's maximum
      theoretical utilization.  For example, on those media employing
      tokens, maximum load may vary as a function of Token Rotation
      Time, Token Holding Time, or the ability to chain multiple
      frames to a single token.  The maximum load that an external
      device applies to a DUT/SUT MUST be specified when measuring
      forwarding rates.

   Measurement units:

      bits per second
      N-octets per second
      (N-octets per second / media_maximum-octets per second) x 100

   Issues:



Mandeville                   Informational                     [Page 13]

RFC 2285                Benchmarking Terminology           February 1998


   See Also:

      offered load (3.5.2)

3.5.4 Overloading

   Definition:

      Attempting to load a DUT/SUT in excess of the maximum rate of
      transmission allowed by the medium.

   Discussion:

      Overloading can serve to exercise buffers and buffer allocation
      algorithms as well as congestion control mechanisms.  The number
      of input interfaces required to overload one or more output
      interfaces of a DUT/SUT will vary according to the media rates of
      the interfaces involved.

      An external source can also overload an interface by transmitting
      frames below the minimum inter-frame gap.  A DUT/SUT MUST forward
      such frames at intervals equal to or above the minimum gap
      specified in standards.

      A DUT/SUT using congestion control techniques such as backpressure
      or forward pressure may exhibit no frame loss when a tester
      attempts to overload one or more of its interfaces.  This should
      not be exploited to suggest that the DUT/SUT supports rates of
      transmission in excess of the maximum rate allowed by the medium
      since both techniques reduce the rate at which the tester offers
      frames to prevent overloading.  Backpressure achieves this purpose
      by jamming the transmission interfaces of the tester and forward
      pressure by hindering the tester from gaining fair access to the
      medium.  Analysis of both cases should take the distinction
      between intended load (3.5.1) and offered load (3.5.2) into
      account.

   Measurement units:

      bits per second
      N-octets per second
      (N-octets per second / media_maximum-octets per second) x 100

   Issues:







Mandeville                   Informational                     [Page 14]

RFC 2285                Benchmarking Terminology           February 1998


   See Also:

      unidirectional traffic (3.2.1)
      intended load (3.5.1)
      offered load (3.5.2)
      forwarding rate (3.6.1)
      backpressure (3.7.1)
      forward pressure (3.7.2)

3.6 Forwarding rates

   This group of definitions applies to the rates at which traffic is
   forwarded by any DUT/SUT in response to a stimulus.

3.6.1 Forwarding rate (FR)

   Definition:

      The number of frames per second that a device can be observed to
      successfully transmit to the correct destination interface in
      response to a specified offered load.

   Discussion:

      Unlike throughput defined in section 3.17 of RFC 1242, forwarding
      rate makes no explicit reference to frame loss.  Forwarding rate
      refers to the number of frames per second observed on the output
      side of the interface under test and MUST be reported in relation
      to the offered load.  Forwarding rate can be measured with
      different traffic orientations and distributions.

      It should be noted that the forwarding rate of a DUT/SUT may be
      sensitive to the action of congestion control mechanisms.

   Measurement units:

      N-octet frames per second

   Issues:

   See Also:

      offered load (3.5.2)
      forwarding rate at maximum offered load (3.6.2)
      maximum forwarding rate (3.6.3)






Mandeville                   Informational                     [Page 15]

RFC 2285                Benchmarking Terminology           February 1998


3.6.2 Forwarding rate at maximum offered load (FRMOL)

   Definition:

      The number of frames per second that a device can be observed to
      successfully transmit to the correct destination interface in
      response to the maximum offered load.

   Discussion:

      Forwarding rate at maximum offered load may be less than the
      maximum rate at which a device can be observed to successfully
      forward traffic.  This will be the case when the ability of a
      device to forward frames degenerates when offered traffic at
      maximum load.

      Maximum offered load MUST be cited when reporting forwarding rate
      at maximum offered load.

   Measurement units:

      N-octet frames per second

   Issues:

   See Also:

      maximum offered load (3.5.3)
      forwarding rate (3.6.1)
      maximum forwarding rate (3.6.3)

3.6.3 Maximum forwarding rate (MFR)

   Definition:

      The highest forwarding rate of a DUT/SUT taken from an iterative
      set of forwarding rate measurements.

   Discussion:

      The forwarding rate of a device may degenerate before maximum load
      is reached.  The load applied to a device must be cited when
      reporting maximum forwarding rate.








Mandeville                   Informational                     [Page 16]

RFC 2285                Benchmarking Terminology           February 1998


      The following example illustrates how the terms relative to
      loading and forwarding rates are meant to be used.  In particular
      it shows how the distinction between forwarding rate at maximum
      offered load (FRMOL) and maximum forwarding rate (MFR) can be used
      to characterize a DUT/SUT.

                    (A)                          (B)
                Test Device                     DUT/SUT
                Offered Load                Forwarding Rate
                ------------                ---------------
        (1)       14,880 fps - MOL              7,400 fps - FRMOL
        (2)       13,880 fps                    8,472 fps
        (3)       12,880 fps                   12,880 fps  - MFR

   Measurement units:

      N-octet frames per second

   Issues:

   See Also:

      offered load (3.5.2)
      forwarding rates (3.6.1)
      forwarding rate at maximum load (3.6.2)

3.7 Congestion control

   This group of definitions applies to the behavior of a DUT/SUT when
   congestion or contention is present.

3.7.1 Backpressure

   Definition:

      Any technique used by a DUT/SUT to attempt to avoid frame loss by
      impeding external sources of traffic from transmitting frames to
      congested interfaces.

   Discussion:

      Some switches send jam signals, for example preamble bits, back to
      traffic sources when their transmit and/or receive buffers start
      to overfill.  Switches implementing full duplex Ethernet links may
      use IEEE 802.3x Flow Control for the same purpose.  Such devices
      may incur no frame loss when external sources attempt to offer
      traffic to congested or overloaded interfaces.




Mandeville                   Informational                     [Page 17]

RFC 2285                Benchmarking Terminology           February 1998


      It should be noted that jamming and other flow control methods may
      slow all traffic transmitted to congested input interfaces
      including traffic intended for uncongested output interfaces.

      A DUT/SUT applying backpressure may exhibit no frame loss when a
      tester attempts to overload one or more of its interfaces.  This
      should not be interpreted to suggest that the interfaces of the
      DUT/SUT support forwarding rates above the maximum rate allowed by
      the medium.  In these cases overloading is only apparent since
      through the application of backpressure the DUT/SUT avoids
      overloading by reducing the rate at which the tester can offer
      frames.

   Measurement units:

      frame loss on congested interface or interfaces N-octet frames per
      second between the interface applying backpressure and an
      uncongested destination interface

   Issues:

      jamming not explicitly described in standards

   See Also:

      intended load (3.5.1)
      offered load (3.5.2)
      overloading (3.5.4)
      forwarding rate (3.6.1)
      forward pressure (3.7.2)

3.7.2 Forward pressure

   Definition:

      Methods which depart from or otherwise violate a defined
      standardized protocol in an attempt to increase the forwarding
      performance of a DUT/SUT.

   Discussion:

      A DUT/SUT may be found to inhibit or abort back-off algorithms in
      order to force access to the medium when contention occurs.  It
      should be noted that the back-off algorithm should be fair whether
      the DUT/SUT is in a congested or an uncongested state.
      Transmission below the minimum inter-frame gap or the disregard of
      flow control primitives fall into this category.




Mandeville                   Informational                     [Page 18]

RFC 2285                Benchmarking Terminology           February 1998


      A DUT/SUT applying forward pressure may eliminate all or most
      frame loss when a tester attempts to overload one or more of its
      interfaces.  This should not be interpreted to suggest that the
      interfaces of the DUT/SUT can sustain forwarding rates above the
      maximum rate allowed by the medium.  Overloading in such cases is
      only apparent since the application of forward pressure by the
      DUT/SUT enables interfaces to relieve saturated output queues by
      forcing access to the medium and concomitantly inhibiting the
      tester from transmitting frames.

   Measurement units:

      intervals between frames in microseconds
      intervals in microseconds between transmission retries during
      16 successive collisions.

   Issues:

      truncated binary exponential back-off algorithm

   See Also:

      intended load (3.5.1)
      offered load (3.5.2)
      overloading (3.5.4)
      forwarding rate (3.6.1)
      backpressure (3.7.1)

3.7.3 Head of line blocking

   Definition:

      Frame loss or added delay observed on an uncongested output
      interface whenever frames are received from an input interface
      which is also attempting to forward frames to a congested output
      interface.

   Discussion:

      It is important to verify that a switch does not slow transmission
      or drop frames on interfaces which are not congested whenever
      overloading on one of its other interfaces occurs.

   Measurement units:

      forwarding rate and frame loss recorded on an uncongested
      interface when receiving frames from an interface which is also
      forwarding frames to a congested interface.



Mandeville                   Informational                     [Page 19]

RFC 2285                Benchmarking Terminology           February 1998


   Issues:

      input buffers

   See Also:

      unidirectional traffic (3.2.1)

3.8 Address handling

   This group of definitions applies to the address resolution process
   enabling a DUT/SUT to forward frames to their correct destinations.

3.8.1 Address caching capacity

   Definition:

      The number of MAC addresses per n interfaces, per module or per
      device that a DUT/SUT can cache and successfully forward frames to
      without flooding or dropping frames.

   Discussion:

      Users building networks will want to know how many nodes they can
      connect to a switch.  This makes it necessary to verify the number
      of MAC addresses that can be assigned per n interfaces, per module
      and per chassis before a DUT/SUT begins flooding frames.

   Measurement units:

      number of MAC addresses per n interfaces, modules, or chassis

   Issues:

   See Also:

      address learning rate (3.8.2)

3.8.2 Address learning rate

   Definition:

      The maximum rate at which a switch can learn new MAC addresses
      without flooding or dropping frames.







Mandeville                   Informational                     [Page 20]

RFC 2285                Benchmarking Terminology           February 1998


   Discussion:

      Users may want to know how long it takes a switch to build its
      address tables.  This information is useful to have when
      considering how long it takes a network to come up when many users
      log on in the morning or after a network crash.

   Measurement units:

      frames with different source addresses per second

   Issues:

   See Also:

      address caching capacity (3.8.1)

3.8.3 Flood count

   Definition:

      Frames forwarded to interfaces which do not correspond to the
      destination MAC address information when traffic is offered to a
      DUT/SUT for forwarding.

   Discussion:

      When recording throughput statistics it is important to check that
      frames have been forwarded to their proper destinations.  Flooded
      frames MUST NOT be counted as received frames.  Both known and
      unknown unicast frames can be flooded.

   Measurement units:

      N-octet valid frames

   Issues:

      spanning tree BPDUs.

   See Also:

      address caching capacity (3.8.1)

3.9 Errored frame filtering

   This group of definitions applies to frames with errors which a
   DUT/SUT may filter.



Mandeville                   Informational                     [Page 21]

RFC 2285                Benchmarking Terminology           February 1998


3.9.1 Errored frames

   Definition:

      Frames which are over-sized, under-sized, misaligned or with an
      errored Frame Check Sequence.

   Discussion:

      Switches, unlike IEEE 802.1d compliant bridges, do not necessarily
      filter all types of illegal frames.  Some switches, for example,
      which do not store frames before forwarding them to their
      destination interfaces may not filter over-sized frames (jabbers)
      or verify the validity of the Frame Check Sequence field.  Other
      illegal frames are under-sized frames (runts) and misaligned
      frames.

   Measurement units:

      n/a

   Issues:

   See Also:

3.10 Broadcasts

   This group of definitions applies to MAC layer and network layer
   broadcast frames.

3.10.1 Broadcast forwarding rate

   Definition:

      The number of broadcast frames per second that a DUT/SUT can be
      observed to deliver to all interfaces located within a broadcast
      domain in response to a specified offered load of frames directed
      to the broadcast MAC address.

   Discussion:

      There is no standard forwarding mechanism used by switches to
      forward broadcast frames.  It is useful to determine the broadcast
      forwarding rate for frames switched between interfaces on the same
      card, interfaces on different cards in the same chassis and






Mandeville                   Informational                     [Page 22]

RFC 2285                Benchmarking Terminology           February 1998


      interfaces on different chassis linked together over backbone
      connections.  The terms maximum broadcast forwarding rate and
      broadcast forwarding rate at maximum load follow directly from the
      terms already defined for forwarding rate measurements in section
      3.6 above.

   Measurement units:

      N-octet frames per second

   Issues:

   See Also:

      forwarding rate at maximum load (3.6.2)
      maximum forwarding rate (3.6.3)
      broadcast latency (3.10.2)

3.10.2 Broadcast latency

   Definition:

      The time required by a DUT/SUT to forward a broadcast frame to
      each interface located within a broadcast domain.

   Discussion:

      Since there is no standard way for switches to process
      broadcast frames, broadcast latency may not be the same on all
      receiving interfaces of a switching device.  The latency
      measurements SHOULD be bit oriented as described in section 3.8
      of RFC 1242.  It is useful to determine broadcast latency for
      frames forwarded between interfaces on the same card, on
      different cards in the same chassis and on different chassis
      linked over backbone connections.

   Measurement units:

         nanoseconds
         microseconds
         milliseconds
         seconds

   Issues:

   See Also:

      broadcast forwarding rate (3.10.1)



Mandeville                   Informational                     [Page 23]

RFC 2285                Benchmarking Terminology           February 1998


4. Security Considerations

   Documents of this type do not directly effect the security of the
   Internet or of corporate networks as long as benchmarking is not
   performed on devices or systems connected to operating networks.

   The document points out that switching devices may violate the IEEE
   802.3 standard by transmitting frames below the minimum interframe
   gap or unfairly accessing the medium by inhibiting the backoff
   algorithm.  Although such violations do not directly engender
   breaches in security, they may perturb the normal functioning of
   other interworking devices by obstructing their access to the medium.
   Their use on the Internet or on corporate networks should be
   discouraged.

5. References

   [1] Bradner, S., "Benchmarking Terminology for Network
       Interconnection Devices", RFC 1242, July 1991.

   [2] Bradner, S., and J. McQuaid, "Benchmarking Methodology for
       Network Interconnect Devices", RFC 1944, May 1996.

6. Acknowledgments

   The Benchmarking Methodology Working Group of the IETF and
   particularly Kevin Dubray (Bay Networks) are to be thanked for the
   many suggestions they collectively made to help complete this
   document.  Ajay Shah (WG), Jean-Christophe Bestaux (ENL), Henry Hamon
   (Netcom Systems), Stan Kopek (Digital) and Doug Ruby (Prominet) all
   provided valuable input at various stages of this project.

   Special thanks go to Scott Bradner for his seminal work in the field
   of benchmarking and his many encouraging remarks.

7. Author's Address

   Robert Mandeville
   European Network Laboratories (ENL)
   2, rue Helene Boucher
   78286 Guyancourt Cedex
   France

   Phone: + 33 1 39 44 12 05
   Mobile Phone + 33 6 07 47 67 10
   Fax: + 33 1 39 44 12 06
   EMail: bob.mandeville@eunet.fr




Mandeville                   Informational                     [Page 24]

RFC 2285                Benchmarking Terminology           February 1998


8.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  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.
























Mandeville                   Informational                     [Page 25]