File: rfc3133.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 (1347 lines) | stat: -rw-r--r-- 44,182 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






Network Working Group                                            J. Dunn
Request for Comments: 3133                                     C. Martin
Category: Informational                                        ANC, Inc.
                                                               June 2001


                Terminology for Frame Relay Benchmarking

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 (2001).  All Rights Reserved.

Abstract

   This memo discusses and defines terms associated with performance
   benchmarking tests and the results of these tests in the context of
   frame relay switching devices.

I. Background

1. Introduction

   This document provides terminology for Frame Relay switching devices.
   It extends terminology already defined for benchmarking network
   interconnect devices in RFCs 1242, 1944 and 2285.  Although some of
   the definitions in this memo may be applicable to a broader group of
   network interconnect devices, the primary focus of the terminology in
   this memo is on Frame Relay Signaling.

   This memo contains two major sections: Background and Definitions.
   The background section provides the reader with an overview of the
   technology and IETF formalisms.  The definitions section is split
   into two sub-sections.  The formal definitions sub-section is
   provided as a courtesy to the reader.  The measurement definitions
   sub-section contains performance metrics with inherent units.

   The BMWG produces two major classes of documents: Benchmarking
   Terminology documents and Benchmarking Methodology documents.  The
   Terminology documents present the benchmarks and other related terms.
   The Methodology documents define the procedures required to collect
   the benchmarks cited in the corresponding Terminology documents.




Dunn & Martin                Informational                      [Page 1]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


   For the purposes of computing several of the metrics, certain textual
   conventions are required.  Specifically:

   1) The notation sum {i=1 to N} A_i denotes: the summation of N
   instances of the observable A.  For example, the set of observations
   {1,2,3,4,5} would yield the result 15.

   2) The notation max {I=1 to N} A_i and min {I=1 to N} A_i denotes:
   the maximum or minimum of the observable A over N instances.  For
   example, given the set of observations {1,2,3,4,5}, max {i=1 to 5} =
   5 and min {I=1 to 5} = 1.

   The terms defined in this memo will be used in addition to terms
   defined in RFCs 1242, 1944 and 2285.  This memo is a product of the
   Benchmarking Methodology Working Group (BMWG) of the Internet
   Engineering Task Force(IETF).

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.  RFC 2285, "Benchmarking Terminology for LAN Switching
   Devices", contains a number of terms pertaining to traffic
   distributions and datagram interarrival.  For the sake of clarity and
   continuity this RFC adopts the template for definitions set out in
   Section 2 of RFC 1242.

II. Definitions

   The definitions presented in this section have been divided into two
   groups.  The first group is formal definitions, which are required in
   the definitions of the performance metrics but are not themselves
   strictly metrics.  These definitions are subsumed from other work
   done in other working groups both inside and outside the IETF.  They
   are provided as a courtesy to the reader.













Dunn & Martin                Informational                      [Page 2]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


1. Formal Definitions

1.1. Definition Format (from RFC1242)

   Term to be defined.

   Definition: The specific definition for the term.

   Discussion: A brief discussion of the term, its application and any
   restrictions on measurement procedures.

   Specification:  The working group and document in which the term is
   specified.  Listed in the references.

1.2. Frame Relay Related Definitions

1.2.1. Access Channel

   Definition: Access channel refers to the user access channel across
   which frame relay data travels.  Within a given DS-3, T1 or E1
   physical line, a channel can be one of the following, depending of
   how the line is configured.  Possible line configurations are:

   A. Unchannelized: The entire DS-3/T1/E1 line is considered a channel,
   where:

   The DS-3 line operates at speeds of 45 Mbps and is a single channel.
   The T1 line operates at speeds of 1.536 Mbps and is a single channel
   consisting of 24 T1 time slots.  The E1 line operates at speeds of
   1.984 Mbps and is a single channel consisting of 30 DS0 time slots.

   B. Channelized: The channel is any one of N time slots within a given
   line, where:

   The T1 line consists of any one or more channels.  Each channel is
   any one of 24 time slots.  The T1 line operates at speeds in
   multiples of 56/64 Kbps to 1.536 Mbps, with aggregate speed not
   exceeding 1.536 Mbps.  The E1 line consists of one or more channels.
   Each channel is any one of 31 time slots.  The E1 line operates at
   speeds in multiples of 64 Kbps to 1.984 Mbps, with aggregate speed
   not exceeding 1.984 Mbps.

   C. Fractional: The T1/E1 channel is one of the following groupings of
   consecutively or non-consecutively assigned time slots:

   N DS0 time slots (NX56/64Kbps where N = 1 to 24 DS0 time slots per
   FT1 channel).




Dunn & Martin                Informational                      [Page 3]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


   N E1 time slots (NX64Kbps, where N = 1 to 30 DS0 time slots per E1
   channel).

   Discussion: Access channels specify the physical layer interface
   speed of a DTE or DCE.  In the case of a DTE, this may not correspond
   to either the CIR or EIR.  Specifically, based on the service level
   agreement in place, the user may not be able to access the entire
   bandwidth of the access channel.

   Specification: FRF

1.2.2. Access Rate (AR)

   Definition: The data rate of the user access channel.  The speed of
   the access channel determines how rapidly (maximum rate) the end user
   can inject data into a frame relay network.

   Discussion: See Access Channel.

   Specification: FRF

1.2.3. Backward Explicit Congestion Notification (BECN)

   Definition: BECN is a bit in the frame relay header.  The bit is set
   by a congested network node in any frame that is traveling in the
   reverse direction of the congestion.

   Discussion: When a DTE receives frames with the BECN bit asserted, it
   should begin congestion avoidance procedures.  Since the BECN frames
   are traveling in the opposite direction as the congested traffic, the
   DTE will be the sender.  The frame relay layer may communicate the
   possibility of congestion to higher layers, which have inherent
   congestion avoidance procedures, such as TCP.  See Frame Relay Frame.

   Specification: FRF

1.2.4. Burst Excess(Be)

   Definition: The maximum amount of uncommitted data (in bits) in
   excess of Committed Burst Size (Bc) that a frame relay network can
   attempt to deliver during a Committed Rate Measurement Interval (Tc).
   This data (Be) generally is delivered with a lower probability than
   Bc.  The network treats Be data as discard eligible.

   Discussion: See also Committed burst Size (Bc), Committed Rate
   Measurement Interval (Tc) and Discard Eligible (De).

   Specification: FRF



Dunn & Martin                Informational                      [Page 4]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


1.2.5. Committed Burst Size (Bc)

   Definition: The maximum amount of data (in bits) that the network
   agrees to transfer, under normal conditions, during a time interval
   Tc.

   Discussion: See also Excess Burst Size (Be) and Committed Rate
   Measurement Interval (Tc).

   Specification: FRF

1.2.6. Committed Information Rate (CIR)

   Definition: CIR is the transport speed the frame relay network will
   maintain between service locations when data is presented.

   Discussion: CIR specifies the guaranteed data rate between two frame
   relay terminal connected by a frame relay network.  Data presented to
   the network in excess of this data rate and below the Excess
   Information Rate (EIR) will be marked as Discard Eligible and may be
   dropped.

   Specification: FRF

1.2.7. Committed Rate Measurement Interval (Tc)

   Definition: The time interval during which the user can send only
   Bc-committed amount of data and Be excess amount of data.  In
   general, the duration of Tc is proportional to the "burstiness" of
   the traffic.  Tc is computed (from the subscription parameters of CIR
   and Bc) as Tc = Bc/CIR.  Tc is not a periodic time interval.
   Instead, it is used only to measure incoming data, during which it
   acts like a sliding window.  Incoming data triggers the Tc interval,
   which continues until it completes its computed duration.

   Discussion: See also Committed Information Rate (CIR) and committed
   Burst Size (Bc).

   Specification: FRF

1.2.8. Cyclic Redundancy Check (CRC)

   Definition: A computational means to ensure the accuracy of frames
   transmitted between devices in a frame relay network.  The
   mathematical function is computed, before the frame is transmitted,






Dunn & Martin                Informational                      [Page 5]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


   at the originating device.  Its numerical value is computed based on
   the content of the frame.  This value is compared with a recomputed
   value of the function at the destination device.  See also Frame
   Check Sequence (FCS).

   Discussion: CRC is not a measurement, but it is possible to measure
   the amount of time to perform a CRC on a string of bits.  This
   measurement will not be addressed in this document.

   Specification: FRF

1.2.9. Data Communications Equipment (DCE)

   Definition: Term defined by both frame relay and X.25 committees,
   that applies to switching equipment and is distinguished from the
   devices that attach to the network (DTE).

   Discussion: Also see DTE.

   Specification: FRF

1.2.10. Data Link Connection Identifier (DLCI)

   Definition: A unique number assigned to a PVC end point in a frame
   relay network.  Identifies a particular PVC endpoint within a user's
   access channel in a frame relay network and has local significance
   only to that channel.

   Discussion: None.

   Specification: FRF

1.2.11. Data Terminal Equipment (DTE)

   Definition: Any network equipment terminating a network connection
   and is attached to the network.  This is distinguished from Data
   Communications Equipment (DCE), which provides switching and
   connectivity within the network.

   Discussion: See also DCE.

   Specification: FRF









Dunn & Martin                Informational                      [Page 6]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


1.2.12. Discard Eligible (DE)

   Definition: This is a bit in the frame relay header that provides a
   two level priority indicator, used to bias discard frames in the
   event of congestion toward lower priority frames.  Similar to the CLP
   bit in ATM.

   Discussion: See Frame Relay Frame.

   Specification: FRF

1.2.13. Discardable frames

   Definition: Frames identified as being eligible to be dropped in the
   event of congestion.

   Discussion: The discard eligible field in the frame relay header is
   the correct -- and by far the most common -- means of indicating
   which frames may be dropped in the event of congestion.  However, DE
   is not the only means of identifying which frames may be dropped.
   There are at least three other cases that apply.

   In the first case, network devices may prioritize frame relay traffic
   by non-DE means.  For example, many service providers prioritize
   traffic on a per-PVC basis.  In this instance, any traffic from a
   given DLCI (data link channel identifier) may be dropped during
   congestion, regardless of whether DE is set.

   In the second case, some implementations use upper-layer criteria,
   such as IP addresses or TCP or UDP port numbers, to prioritize
   traffic within a single PVC.  In this instance, the network device
   may evaluate discard eligibility based on upper-layer criteria rather
   than the presence or absence of a DE bit.

   In the third case, the frame is discarded because of an error in the
   frame.  Specifically, frames that are too long or too short, frames
   that are not a multiple of 8 bits in length, frames with an invalid
   or unrecognized DLCI, frames with an abort sequence, frames with
   improper flag delimitation, and frames that fail FCS.

   Specification: FRMIB

1.2.14. Discarded frames

   Definition: Those frames dropped by a network device.






Dunn & Martin                Informational                      [Page 7]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


   Discussion: Discardable and discarded frames are not synonymous.
   Some implementations may ignore DE bits or other criteria, even
   though they supposedly use such criteria to determine which frames to
   drop in the event of congestion.

   In other cases, a frame with its DE bit set may not be dropped.  One
   example of this is in cases where congestion clears before the frame
   can be evaluated.

   Specification: DN

1.2.15. Forward Explicit Congestion Notification (FECN)

   Definition:  FECN is a bit in the frame relay header.  The bit is set
   by a congested network node in any frame that is traveling in the
   same direction of the congestion.

   Discussion: When a DTE receives frames with the FECN bit asserted, it
   should begin congestion avoidance procedures.  Since the FECN frames
   are traveling in the same direction as the congested traffic, the DTE
   will be the receiver.  The frame relay layer may communicate the
   possibility of congestion to higher layers, which have inherent
   congestion avoidance procedures, such as TCP.  See Frame Relay Frame.

   Specification: FRF

1.2.16. Frame Check Sequence (FCS)

   Definition: The standard 16-bit cyclic redundancy check used for HDLC
   and frame relay frames.  The FCS detects bit errors occurring in the
   bits of the frame between the opening flag and the FCS, and is only
   effective in detecting errors in frames no larger than 4096 octets.
   See also Cyclic Redundancy Check (CRC).

   Discussion: FCS is not a measurement, but it is possible to measure
   the amount of time to perform a FCS on a string of bits.  This
   measurement will not be addressed in this document.

   Specification: FRF

1.2.17. Frame Entry Event

   Definition: Frame enters a network section or end system.  The event
   occurs when the last bit of the closing flag of the frame crosses the
   boundary.

   Discussion: None.




Dunn & Martin                Informational                      [Page 8]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


   Specification: FRF.13

1.2.18. Frame Exit Event

   Definition: Frame exits a network section or end system.  The event
   occurs when the first bit of the address field of the frame crosses
   the boundary.

   Discussion: None.

   Specification: FRF.13

1.2.19. Frame Relay

   Definition:  A high-performance interface for packet-switching
   networks; considered more efficient that X.25.  Frame relay
   technology can handle "bursty" communications that have rapidly
   changing bandwidth requirements.

   Discussion: None.

   Specification: FRF

1.2.20. Frame Relay Frame

   Definition: A logical grouping of information sent as a link-layer
   unit over a transmission medium.  Frame relay frames consist of a
   pair of flags, a header, a user data payload and a Frame Check
   Sequence (FCS).  Bit stuffing differentiates user data bytes from
   flags.  By default, the header is two octets, of which 10 bits are
   the Data Link Connection Identifier (DLCI), 1 bit in each octet is
   used for address extension (AE), and 1 bit each for Forward Explicit
   Congestion Notification (FECN), Backward Explicit Congestion
   Notification (BECN) Command/Response (C/R) and Discard Eligible (DE).
   The EA bit is set to one in the final octet containing the DLCI.  A
   header may span 2, 3 or 4 octets.















Dunn & Martin                Informational                      [Page 9]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


   Bit  7   6   5   4   3   2   1   0
      |---|---|---|---|---|---|---|---|
      |              FLAG             |
      |-------------------------------|
      | Upper 6 bits of DLCI  |C/R|AE |
      |-------------------------------|
      |   DLCI        |FE |BE |DE |AE |
      |               |CN |CN |   |   |
      |-------------------------------|
      |        User Data up to        |
      |          1600 Octets          |
      |-------------------------------|
      |      First Octet of FCS       |
      |-------------------------------|
      |      Second Octet of FCS      |
      |-------------------------------|
      |              FLAG             |
      |-------------------------------|

   Discussion: Frame Relay headers spanning 3 or 4 octets will not be
   discussed in this document.  Note, the measurements described later
   in this document are based on 2 octet headers.  If longer headers are
   used, the metric values must take into account the associated
   overhead.  See BECN, DE, DLCI and FECN.

   Specification: FRF

1.2.21. Excess Information Rate (EIR)

   Definition: See Burst Excess.

   Discussion: None.

   Specification: FRF

1.2.22. Network Interworking (FRF.5)

   Definition: FRF.5 defines a protocol mapping called Network
   Interworking between

   Frame Relay and Asynchronous Transfer Mode (ATM).  Protocol mapping
   occurs when the network performs conversions in such a way that
   within a common layer service, the protocol information of one
   protocol is extracted and mapped on protocol information of another
   protocol.  This means that each communication terminal supports
   different protocols.  The common layer service provided in this





Dunn & Martin                Informational                     [Page 10]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


   interworking scenario is defined by the functions, which are common
   to the two protocols.  Specifically, the ATM terminal must be
   configured to interoperate with the Frame Relay network and vice
   versa.

   Discussion: None.

   Specification: FRF.5

1.2.23. Port speed

   Definition: See Access Rate

   Discussion: None.

   Specification: FRF

1.2.24. Service Interworking (FRF.8)

   Definition: FRF.8 defines a protocol encapsulation called Service
   Interworking.  Protocol encapsulation occurs when the conversions in
   the network or in the terminals are such that the protocols used to
   provide one service make use of the layer service provided by another
   protocol.  This means that at the interworking point, the two
   protocols are stacked.  When encapsulation is performed by the
   terminal, this scenario is also called interworking by port access.
   Specifically, the ATM service user performs no Frame Relaying
   specific functions, and Frame Relaying service user performs no ATM
   service specific functions.

   Discussion: None.

   Specification: FRF.8

1.2.25. Service Availability Parameters

   Definition: The service availability parameters report the
   operational readiness of individual frame relay virtual connections.
   Service availability is affected by service outages.

   Discussion: Service availability parameters provide metrics for
   assessment of frame relay network health and are used to monitor
   compliance with service level agreements.  See Services Outages.

   Specification: FRF.13






Dunn & Martin                Informational                     [Page 11]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


1.2.26. Service Outages

   Definition: Any event that interrupts the transport of frame relay
   traffic.  Two types of outages are differentiated:

   1) Fault outages: Outages resulting from faults in the network and
   thus tracked by the service availability parameters, and

   2) Excluded outages: Outages resulting from faults beyond the control
   of the network as well as scheduled maintenance.

   Discussion: Service availability can be defined on a per-VC basis
   and/or on a per-port basis.  Frame relay port-based service
   availability parameters are not addressed in this document.  See
   Service Availability Parameters.

   Specification: FRF.13

2. Performance Metrics

2.1. Definition Format (from RFC1242)

   Metric to be defined.

   Definition: The specific definition for the metric.

   Discussion:  A brief discussion of the metric, its application and
   any restrictions on measurement procedures.

   Measurement units: Intrinsic units used to quantify this metric.
   This includes  subsidiary units, e.g., microseconds are acceptable if
   the intrinsic unit is seconds.

2.2. Definitions

2.2.1. Physical Layer-Plesiochronous Data Hierarchy (PDH)

2.2.1.1. Alarm Indication Signal (AIS)

   Definition: An all 1's frame transmitted after the DTE or DCE detects
   a defect for 2.5 s +/- 0.5 s.

   Discussion: An AIS will cause loss of information in the PDH frame,
   which contains a frame relay frame which may contain IP datagrams.

   Measurement units: Dimensionless.





Dunn & Martin                Informational                     [Page 12]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


2.2.1.2. Loss of Frame (LOF)

   Definition: An NE transmits an LOF when an OOF condition persists.

   Discussion: A LOF will cause loss of information in the PDH frame,
   which contains a frame relay frame which may contain IP datagrams.

   Measurement units: Dimensionless.

2.2.1.3. Loss of Signal (LOS)

   Definition: Indicates that there are no transitions occurring in the
   received signal.

   Discussion: A LOS will cause loss of information in the PDH frame
   which contains a frame relay frame which may contain IP datagrams.

   Measurement units: Dimensionless.

2.2.1.4. Out of Frame (OOF)

   Definition: An NE transmits an OOF downstream when it receives
   framing errors in a specified number of consecutive frame bit
   positions.

   Discussion: An OOF will cause loss of information in the PDH frame
   which contains a frame relay frame which may contain IP datagrams.

   Measurement units: Dimensionless.

2.2.1.5. Remote Alarm Indication (RAI)

   Definition: Previously called Yellow Alarm.  Transmitted upstream by
   an NE to indicate that it detected an LOS, LOF, or AIS.

   Discussion: An RAI will cause loss of information in the transmitted
   PDH frame, which may contain a frame relay frame, which, in turn, may
   contain IP datagrams.

   Measurement units: Dimensionless.

2.2.2. Frame Relay Layer

2.2.2.1. Data Delivery Ratio (DDR)

   Definition: The DDR service level parameter  reports  the  networks
   effectiveness in transporting offered data (payload without address
   field or FCS) in one direction of a single virtual connection.  The



Dunn & Martin                Informational                     [Page 13]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


   DDR is a ratio of  successful  payload octets received to attempted
   payload octets transmitted.  Attempted payload octets transmitted are
   referred to as DataOffered.  Successfully delivered payload octets
   are referred to as DataDelivered.  These loads are further
   differentiated as being within the committed information rate or as
   burst excess.

   Three data relay ratios may be reported:

   Data Delivery Ratio (DDR):

          (DataDelivered_c + DataDelivered_e   DataDelivered_e+c
     DDR = --------------------------------- = -----------------
          (DataOffered_c + DataOffered_e)    DataOffered_e+c

   Data Delivery Ratio (DDR_c) for load consisting of frames within the
   committed information rate:

             DataDelivered_c
     DDR_c = -------------
             DataOffered_c

   Data Delivery Ratio (DDR_e) for load in excess of the committed
   information rate:

             DataDelivered_e
     DDR_e = ---------------
             DataOffered_e

   where

   DataDelivered_c: Successfully delivered data payload octets within
   committed information rate,

   DataDelivered_e: Successfully delivered data payload octets in excess
   of CIR,

   DataDelivereD_e+c: Successfully delivered total data payload octets,
   including those within committed information rate and those in excess
   of CIR,

   DataOffered_c: Attempted data payload octet transmissions within
   committed information rate,

   DataOffered_e: Attempted data payload octet transmissions in excess
   of CIR

   and



Dunn & Martin                Informational                     [Page 14]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


   DataOffered_e+c: Attempted total data payload octet transmissions,
   including those within committed information rate and those in excess
   of CIR

   Each direction of a full duplex connection has a discrete set of data
   delivery ratios.

   Discussion: Data delivery ratio measurements may not be
   representative of data delivery effectiveness for a given
   application.  For example, the discarding of a small frame containing
   an acknowledgement message may result in the retransmission of a
   large number of data frames.  In such an event, a good data delivery
   ratio would be reported while the user experienced poor performance.

   Measurement units: dimensionless.

2.2.2.2. Frame Delivery Ratio (FDR)

   Definition: The FDR service level parameter reports the networks
   effectiveness in transporting an offered frame relay load in one
   direction of a single virtual connection.  The FDR is a ratio of
   successful frame receptions to attempted frame transmissions.
   Attempted frame transmissions are referred to as Frames Offered.
   Successfully delivered frames are referred to as Frames Delivered.
   These loads may be further differentiated as being within the
   committed information rate or as burst excess.

   Frame Delivery Ratio (FDR):

   Frame Delivery Ratio (FDR):

          (FramesDelivered_c + FramesDelivered_e)  FramesDelivered_e+c
     FDR = ------------------------------------- = -------------------
          (FramesOffered_c + FramesOffered_e)   FramesOffered_e+c

   Frame Delivery Ratio (FDR_c) for load consisting of frames within the
   committed information rate:

             FramesDelivered_c
     FDR_c = -----------------
             FramesOffered_c

   Frame Delivery Ratio (FDR_c) for load in excess of the committed
   information rate:

             FramesDelivered_e
     FDR_e = -----------------
             FramesOffered_e



Dunn & Martin                Informational                     [Page 15]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


   where

   FramesDelivered_c: Successfully delivered frames within committed
   information rate,

   FramesDelivered_e: Successfully delivered frames in excess of CIR,

   FramesDelivered_e+c: Successfully delivered total frames, including
   those within committed information rate and those in excess of CIR,

   FramesOffered_c: Attempted frame transmissions within committed
   information rate,

   FramesOffered_e: Attempted frame transmissions in excess of CIR

   and

   FramesOffered_e+c: Attempted total frame transmissions, including
   those within committed information rate and those in excess of CIR.

   An independent set of frame delivery ratios exists for each direction
   of a full duplex connection.

   Discussion: Frame delivery ratio measurements may not be
   representative of frame delivery effectiveness for a given
   application.  For example, the discarding of a small frame containing
   an acknowledgement message may result in the retransmission of a
   large number of data frames.  In such an event, a good data delivery
   ratio would be reported while the user

   Measurement units: dimensionless.

2.2.2.3. Frame Discard Ratio (FDR)

   Definition: The number of received frames that are discarded because
   of a frame error divided by the total number of transmitted frames in
   one direction of a single virtual connection.  Frame errors are
   defined as follows:

   1) frames that are too long or too short,
   2) frames that are not a multiple of 8 bits in length,
   3) frames with an invalid or unrecognized DLCI,
   4) frames with an abort sequence,
   5) frames with improper flag delimitation,
   6) frames that fail FCS.






Dunn & Martin                Informational                     [Page 16]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


   The formal definition of frame discard ratio is as follows:

           sum {i=1 to N} fr_i
     FDR = -------------------
           sum {i=1 to N} ft_i,

   where

   fr_i is the number of successfully delivered frames for a particular
   DLCI at second i

   and

   ft_i is the total number of attempted frame transmissions within the
   committed plus extended information rate for a particular DLCI at
   second i.

   Discussion: Frame discards can adversely effect applications running
   on IP over FR.  In general, frame discards will negatively impact TCP
   throughput; however, in the case of frame discard due to frame error,
   frame discard will improve performance by dropping errored frames.
   As a result, these frames will not adversely effect the forwarding of
   retransmitted frames

   Measurement units: dimensionless.

2.2.2.4. Frame Error Ratio (FER)

   Definition: The number of received frames that contain an error in
   the frame payload divided by the total number of transmitted frames
   in one direction of a single virtual connection.

   The formal definition of frame error ratio is as follows:

           sum {i=1 to N} fe_i
     FER = -------------------
           sum {i=1 to N} ft_i,

   where

   fe_i is the number of frames containing a payload error for a
   particular DLCI at second i

   and

   ft_i is the total number of attempted frame transmissions within the
   committed plus the extended information rate for a particular DLCI at
   second i.  This statistic includes those frames which have an error



Dunn & Martin                Informational                     [Page 17]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


   in the Frame Check Sequence (FCS).  Frame errors in the absence of
   FCS errors can be detected by sending frames containing a known
   pattern; however, this indicates an equipment defect.

   Discussion: The delivery of frames containing errors will adversely
   effect applications running on IP over FR.  Typically, these errors
   are caused by transmission errors and flagged as failed FCS frames;
   however, when Frame Relay to ATM Network interworking is used, an
   error may be injected in the frame payload which, in turn, is
   encapsulated into an AAL5 PDU (see RFC 2761 for a discussion of AAL5
   related metrics).

   Measurement units: dimensionless.

2.2.2.5. Frame Excess Ratio (FXR)

   Definition: The number of frames received by the network and treated
   as excess traffic divided by the total number of transmitted frames
   in one direction of a single virtual connection.  Frames which are
   sent to the network with DE set to zero are treated as excess when
   more than Bc bits are submitted to the network during the Committed
   Information Rate Measurement Interval (Tc).  Excess traffic may or
   may not be discarded at the ingress if more than Bc + Be bits are
   submitted to the network during Tc.  Traffic discarded at the ingress
   is not recorded in this measurement.  Frames which are sent to the
   network with DE set to one are also treated as excess traffic.

   The formal definition of frame excess ratio is as follows:

               sum {i=1 to N} fc_i
     FXR = 1 - -------------------
               sum {i=1 to N} ft_i,

   where

   fc_i is the total number of frames which were submitted within the
   traffic contract for a particular DLCI at second i

   and

   ft_i is the total number of attempted frame transmissions for a
   particular DLCI at second i.

   Discussion: Frame discards can adversely effect applications running
   on IP over FR.  Specifically, frame discards will negatively impact
   TCP throughput.

   Measurement units: dimensionless.



Dunn & Martin                Informational                     [Page 18]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


2.2.2.6. Frame Loss Ratio (FLR)

   Definition: The FLR is a ratio of successful frame receptions to
   attempted frame transmissions at the committed information rate, in
   one direction of a single virtual connection.  Attempted frame
   transmissions are referred to as Frames Offered.  Successfully
   delivered frames are referred to as Frames Delivered.

   The formal definition of frame loss ratio is as follows:

              FramesDelivered_c
     FLR = 1- -----------------
              FramesOffered_c,

   where

   FramesDelivered_c is the successfully delivered frames within
   committed information rate for a given DLCI

   and

   FramesOffered_c is the attempted frame transmissions within committed
   information rate for a given DLCI

   An independent set of frame delivery ratios exists for each direction
   of a full duplex connection.

   Discussion: Frame delivery loss measurements may not be
   representative of frame delivery effectiveness for a given
   application.  For example, the loss of a small frame containing an
   acknowledgement message may result in the retransmission of a large
   number of data frames.  In such an event, a good data delivery ratio
   would be reported while the user

   Measurement units: dimensionless.

2.2.2.7. Frame Policing Ratio (FPR)

   Definition: The number of frames received by the network and treated
   as excess traffic and dropped divided by the total number of received
   frames, in one direction of a single virtual connection.  Frames
   which are sent to the network with DE set to zero are treated as
   excess when more than Bc bits are submitted to the network during the
   Committed Information Rate Measurement Interval (Tc).  Excess traffic
   may or may not be discarded at the ingress if more than Bc + Be bits
   are submitted to the network during Tc.  Traffic discarded at the
   ingress is recorded in this measurement.  Frames which are sent to
   the network with DE set to one are also treated as excess traffic.



Dunn & Martin                Informational                     [Page 19]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


   The formal definition of frame excess ratio is as follows:

              sum {i=1 to N} fr_i
     FPR = 1- -------------------
              sum {i=1 to N} ft_i,

   where

   fr_i is the successfully delivered frames for a particular DLCI at
   second i

   and

   ft_i is the total number of attempted frame transmissions for a
   particular DLCI

   at second i.

   Discussion: Frame discards can adversely effect applications running
   on IP over FR.  Specifically, frame discards will negatively impact
   TCP throughput.

2.2.2.8. Frame Transfer Delay (FTD)

   Definition: The time required to transport frame relay data from
   measurement point 1 to measurement point 2.  The frame transfer delay
   is the difference in seconds between the time a frame exits
   measurement point 1 and the time the same frame enters measurement
   point 2, in one direction of a single virtual connection.  The formal
   definition of frame transfer delay is as follows:

      FTD = 1/N * sum {i=1 to N} t2_i - t1_i,

   where

   t1_i is the time in seconds when the ith frame leaves measurement
   point 1 (i.e., frame exit event),

   t2 is the time in seconds when the ith frame arrives at measurement
   point 2 (i.e., frame entry event)

   and

   N is the number of frames received during a measurement interval T.

   FTD is computed for a specific DLCI and a specified integration
   period of T seconds.  The computation does not include frames which
   are transmitted during the measurement period but not received.



Dunn & Martin                Informational                     [Page 20]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


   Discussion: While frame transfer delay is usually computed as an
   average and, thus, can effect neither IP nor TCP performance,
   applications such as voice over IP may be adversely effected by
   excessive FTD.

   Measurement units: seconds.

2.2.2.9. Frame Transfer Delay Variation (FTDV)

   Definition: The variation in the time required to transport frame
   relay data from measurement point 1 to measurement point 2.  The
   frame transfer delay variation is the difference in seconds between
   maximum frame transfer delay and the minimum frame transfer delay, in
   one direction of a single virtual connection.  The formal definition
   of frame transfer delay is as follows:

      FTDV = max {i=1 to N} FTD_i - min {i=1 to N} FTD_i.

   where

   FTD and N are defined as above.

   Discussion: Large values of FTDV can adversely effect TCP round trip
   time calculation and, thus, TCP throughput.

   Measurement units: seconds.

3. Security Considerations

   As this document is solely for providing terminology and describes
   neither a protocol nor an implementation, there are no security
   considerations associated with this document.

4. Notices

   Internet Engineering Task Force

      The IETF takes no position regarding the validity or scope of any
      intellectual property or other rights that might be claimed to
      pertain to the implementation or use of the technology described
      in this document or the extent to which any license under such
      rights might or might not be available; neither does it represent
      that it has made any effort to identify any such rights.
      Information on the IETFs procedures with respect to rights in
      standards-track and standards-related documentation can be found
      in BCP-11.  Copies of claims of rights made available for
      publication and any assurances of licenses to be made available,
      or the result of an attempt made to obtain a general license or



Dunn & Martin                Informational                     [Page 21]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


      permission for the use of such proprietary rights by implementors
      or users of this specification can be obtained from the IETF
      Secretariat.

      The IETF invites any interested party to bring to its attention
      any copyrights, patents or patent applications, or other
      proprietary rights, which may cover technology that may be
      required to practice this standard.  Please address the
      information to the IETF Executive Director.

   Frame Relay Forum

      Copyright Frame Relay Forum 1998.  All Rights Reserved.
      References FRF, FRF.5, FRF.8 and FRF.13 and translations of them
      may be copied and furnished to others, and works that comment on
      or otherwise explain it or assist in their 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, these documents themselves may not be
      modified in any way, such as by removing the copyright notice or
      references to the Frame Relay Forum, except as needed for the
      purpose of developing Frame Relay standards (in which case the
      procedures for copyrights defined by the Frame Relay Forum must be
      followed), or as required to translate it into languages other
      than English.

























Dunn & Martin                Informational                     [Page 22]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


5. References

   [DN]     Private communication from David Newman, Network Test, Inc.

   [FRF]    Frame Relay Forum Glossary, http://www.frforum.com, 1999.

   [FRF.5]  Frame Relay Forum, Frame Relay/ATM PVC Network Interworking
            Implementation Agreement, December 1994.

   [FRF.8]  Frame Relay Forum, Frame Relay/ATM PVC Service Interworking
            Implementation Agreement, April 1995.

   [FRF.13] Frame Relay Forum, Service Level Definitions Implementation
            Agreement, August 1998.

   [FRMIB]  Rehbehn, K and D. Fowler, "Definitions of Managed Objects
            for Frame Relay Service", RFC 2954, October 2000.

6. Editors' Addresses

   Jeffrey Dunn
   Advanced Network Consultants, Inc.
   4214 Crest Place
   Ellicott City, MD 21043 USA

   Phone: +1 (410) 750-1700
   EMail: Jeffrey.Dunn@worldnet.att.net


   Cynthia Martin
   Advanced Network Consultants, Inc.
   4214 Crest Place
   Ellicott City, MD 21043 USA

   Phone: +1 (410) 750-1700
   EMail: Cynthia.E.Martin@worldnet.att.net















Dunn & Martin                Informational                     [Page 23]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


Full Copyright Statement

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



















Dunn & Martin                Informational                     [Page 24]