RFC 3133

Terminology for Frame Relay Benchmarking

📅 published June 2001, from ietf

RFC 3133: Terminology for Frame Relay Benchmarking 🦋

Okay bestie, this one is RFC 3133 💖. It's titled "Terminology for Frame Relay Benchmarking," written by J. Dunn and C. Martin of ANC, Inc., and dated June 2001. It's in the Network Working Group, and its category is Informational. The title block doesn't list anything it obsoletes or updates 🙈.

Status of this Memo ✨

This memo is giving "for your info" energy 💅. It provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌈.

Copyright Notice 🎀

Abstract 💜

This memo talks about and defines terms for performance benchmarking tests and the results of those tests, specifically in the context of frame relay switching devices 🧚.

I. Background 🌸

1. Introduction 💅

Okay so this doc gives you terminology for Frame Relay switching devices 💖. It extends the terms already defined for benchmarking network interconnect devices in RFCs 1242, 1944 and 2285. Some definitions here might also apply to a broader group of network interconnect devices, but the main focus is Frame Relay Signaling 🔥.

This memo has two major sections: Background and Definitions 🦋. The Background section gives you an overview of the technology and IETF formalisms. The Definitions section has two sub-sections. The formal definitions sub-section is a courtesy for you 🫶. The measurement definitions sub-section has performance metrics with inherent units 📏.

The BMWG makes 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 matching Terminology documents 💜.

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

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.
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 are used in addition to the 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 📚

Before you touch this doc, you should check out RFC 1242 🧐. It's titled "Benchmarking Terminology for Network Interconnect Devices," and it should be consulted before attempting to make use of this document. RFC 1944, "Benchmarking Methodology for Network Interconnect Devices," has discussions of a number of terms relevant to benchmarking switching devices, and it should also be consulted. RFC 2285, "Benchmarking Terminology for LAN Switching Devices," has a number of terms about 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 in this section are split into two groups. The first group is formal definitions. They're required in the definitions of the performance metrics, but they aren't strictly metrics themselves. These definitions are taken from other work done in other working groups, both inside and outside the IETF. They're provided as a courtesy to you 🫶.

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.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).

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

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, 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

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: Okay bestie, the discard eligible field in the frame relay header is the correct way to flag droppable frames, and by FAR the most common one 💅 But DE isn't the only way to mark which frames can get dropped. There are at least three other cases that apply 👀

Case one: network devices can prioritize frame relay traffic without using DE. Like, lots of service providers prioritize traffic on a per-PVC basis 🎀 So in that setup, any traffic from a given DLCI (data link channel identifier) may get dropped during congestion, no matter whether DE is set.

Case two: some implementations look at upper-layer criteria, like IP addresses or TCP or UDP port numbers, to prioritize traffic inside a single PVC ✨ Here the network device may decide discard eligibility based on those upper-layer criteria instead of whether the DE bit is there or not.

Case three: the frame gets discarded because it has an error in it 💀 Specifically, the bad ones are:

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
frames that fail FCS

Specification: FRMIB

1.2.14. Discarded frames 🗑️

Definition: Those frames dropped by a network device.

Discussion: Discardable and discarded frames are NOT the same thing 🙈 Some implementations may ignore DE bits or other criteria, even though they supposedly use those criteria to decide which frames to drop in the event of congestion. Mood.

In other cases, a frame with its DE bit set may not be dropped at all. One example is when congestion clears before the frame can be evaluated. Lucky frame 🍀

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. It's giving "send the warning up the stack" energy 🫶

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. Not my problem, bestie 💅

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.

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. Bursty queens only 👑

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.

Here's the layout, exactly as it's supposed to look 🌸

   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. Two-octet headers are the main character here 👑

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 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. Health checks, but make it cute 🩺

Specification: FRF.13

1.2.26. Service Outages ⚡

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

Fault outages: Outages resulting from faults in the network and thus tracked by the service availability parameters, and
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.

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) 💖

okay so DDR is the stat that tells you how well the network actually delivers your data 🚚✨ It measures the network's effectiveness in transporting offered data (payload only, no address field or FCS) in one direction of a single virtual connection. DDR is basically successful payload octets received divided by attempted payload octets transmitted. The attempted ones are called DataOffered and the successfully delivered ones are called DataDelivered. Both get split into traffic inside the committed information rate and burst excess, so you can see exactly where things went right or wrong 🎀

There are three data relay ratios you can report:

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

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 gets its own discrete set of data delivery ratios 🦋

Discussion: ngl, this is where it gets a little tricky. Data delivery ratio numbers may not reflect how well delivery actually works for a given application 😭 For example, if a tiny frame carrying an acknowledgement message gets discarded, the sender may have to retransmit a huge pile of data frames. In that situation the reported data delivery ratio could look great while the user is genuinely having a terrible time 💀

Measurement units: dimensionless.

2.2.2.2. Frame Delivery Ratio (FDR) 🌸

FDR is the stat for how effectively the network moves an offered frame relay load in one direction of a single virtual connection. It's the ratio of successful frame receptions to attempted frame transmissions. The attempts are called Frames Offered, and the successful ones are called Frames Delivered. These loads can also be split into traffic within the committed information rate and burst excess 🧚

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

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.

Every direction of a full duplex connection has its own independent set of frame delivery ratios ✨

Discussion: same vibe as DDR, bestie. Frame delivery ratio measurements may not show how well frame delivery works for a given application 🙈 For example, if a small frame carrying an acknowledgement message gets discarded, the sender might retransmit a large number of data frames. In that case a good data delivery ratio would be reported while the user

Measurement units: dimensionless.

2.2.2.3. Frame Discard Ratio (FDR) 🍓

This one counts the received frames that get thrown away because of a frame error, divided by the total number of transmitted frames, in one direction of a single virtual connection. Frame errors are any of the following:

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,
frames that fail FCS.

The formal definition of frame discard ratio is:

        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 seriously affect applications running on IP over FR 😭 In general, frame discards will hurt TCP throughput. But when the discard is caused by a frame error, dropping those errored frames actually improves performance 🔥 Because of that, these frames will not adversely effect the forwarding of retransmitted frames

Measurement units: dimensionless.

2.2.2.4. Frame Error Ratio (FER) 💅

FER counts the 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:

        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 frames that have an error in the Frame Check Sequence (FCS). Frame errors that show up without any FCS errors can be detected by sending frames with a known pattern. But honestly, that points to an equipment defect 🛠️

Discussion: delivering frames with errors will adversely effect applications running on IP over FR 💀 Usually these errors come from transmission errors and get flagged as failed FCS frames. However, when Frame Relay to ATM Network interworking is used, an error may be injected into the frame payload, and that payload then gets 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) 🦋

FXR counts the frames the network receives and treats as excess traffic, divided by the total number of transmitted frames, in one direction of a single virtual connection. Frames 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 sent to the network with DE set to one are also treated as excess traffic 👑

The formal definition of frame excess ratio is:

            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.

2.2.2.6. Frame Loss Ratio (FLR) 🎀

FLR is the ratio of successful frame receptions to attempted frame transmissions at the committed information rate, in one direction of a single virtual connection. The attempts are called Frames Offered, and the successful ones are called Frames Delivered.

The formal definition of frame loss ratio is:

           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.

Each direction of a full duplex connection has an independent set of frame delivery ratios 🫶

Discussion: frame delivery loss measurements may not be representative of frame delivery effectiveness for a given application 🙈 For example, losing 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) 🔥

FPR counts the frames the network receives and treats as excess traffic and drops, divided by the total number of received frames, in one direction of a single virtual connection. Frames sent to the network with DE set to zero are treated as excess when more than Bc bits are submitted 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 during Tc. Traffic discarded at the ingress is recorded in this measurement, unlike FXR. Frames sent to the network with DE set to one are also treated as excess traffic 🌸

The formal definition of frame excess ratio is:

           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: Okay bestie, FTD is how long frame relay data takes to get from measurement point 1 to measurement point 2 ✨ It's the difference in seconds between when a frame exits measurement point 1 and when that same frame enters measurement point 2, measured in one direction of a single virtual connection. The formal version looks like this:

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. 💅

Discussion: Since FTD is usually computed as an average, it can't really affect IP or TCP performance on its own, but voice over IP can be hurt by excessive FTD 🎧 Not fun for calls, bestie 😭

Measurement units: seconds.

2.2.2.9. Frame Transfer Delay Variation (FTDV) 🌈

Definition: Okay, so FTDV is about how much the transfer time wiggles around 🫠 It's the difference in seconds between the maximum frame transfer delay and the minimum frame transfer delay, in one direction of a single virtual connection. The formal definition is written as:

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

where

FTD and N are defined as above.

Discussion: Big FTDV values can mess with TCP round trip time calculation and, in turn, TCP throughput. Literally the drama of the network world 🙈

Measurement units: seconds.

3. Security Considerations 💀

Okay, this section is short and sweet 🍓 This document only gives terminology. It doesn't describe a protocol or an implementation, so there are no security considerations associated with this document. Zero risks here, periodt ✨

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 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.

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

Full Copyright Statement 🔒

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. 💖

📦 where this page comes from

ietf: rfc3133 2001-06
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms

RFC 3133

RFC 3133: Terminology for Frame Relay Benchmarking 🦋

Status of this Memo ✨

Copyright Notice 🎀

Abstract 💜

I. Background 🌸

1. Introduction 💅

2. Existing Definitions 📚

II. Definitions 🎀

1. Formal Definitions 💖

1.1. Definition Format (from RFC1242) 📝

1.2. Frame Relay Related Definitions 🦋

1.2.1. Access Channel 🛣️

1.2.2. Access Rate (AR) 🚀

1.2.3. Backward Explicit Congestion Notification (BECN) 🔙

1.2.4. Burst Excess(Be) 💥

1.2.5. Committed Burst Size (Bc) 🧱

1.2.6. Committed Information Rate (CIR) 🏁

1.2.7. Committed Rate Measurement Interval (Tc) ⏱️

1.2.8. Cyclic Redundancy Check (CRC) 🔁

1.2.9. Data Communications Equipment (DCE) 🗼

1.2.10. Data Link Connection Identifier (DLCI) 🔢

1.2.11. Data Terminal Equipment (DTE) 🖥️

1.2.12. Discard Eligible (DE) 🗑️

1.2.13. Discardable frames 🫧

1.2.14. Discarded frames 🗑️

1.2.15. Forward Explicit Congestion Notification (FECN) 📣

1.2.16. Frame Check Sequence (FCS) 🧮

1.2.17. Frame Entry Event 🚪

1.2.18. Frame Exit Event 🚪

1.2.19. Frame Relay 🦋

1.2.20. Frame Relay Frame 🎁

1.2.21. Excess Information Rate (EIR) 💸

1.2.22. Network Interworking (FRF.5) 🌉

1.2.23. Port speed 🔌

1.2.24. Service Interworking (FRF.8) 🧩

1.2.25. Service Availability Parameters 📊

1.2.26. Service Outages ⚡

2. Performance Metrics 📏

2.1. Definition Format (from RFC1242) 🧾

2.2. Definitions 💜

2.2.1. Physical Layer-Plesiochronous Data Hierarchy (PDH) 🛰️

2.2.1.1. Alarm Indication Signal (AIS) 🚨

2.2.1.2. Loss of Frame (LOF) 🫥

2.2.1.3. Loss of Signal (LOS) 📉

2.2.1.4. Out of Frame (OOF) 🧱

2.2.1.5. Remote Alarm Indication (RAI) 💛

2.2.2. Frame Relay Layer 🌈

2.2.2.1. Data Delivery Ratio (DDR) 💖

2.2.2.2. Frame Delivery Ratio (FDR) 🌸

2.2.2.3. Frame Discard Ratio (FDR) 🍓

2.2.2.4. Frame Error Ratio (FER) 💅

2.2.2.5. Frame Excess Ratio (FXR) 🦋

2.2.2.6. Frame Loss Ratio (FLR) 🎀

2.2.2.7. Frame Policing Ratio (FPR) 🔥

2.2.2.8. Frame Transfer Delay (FTD) 🦋

2.2.2.9. Frame Transfer Delay Variation (FTDV) 🌈

3. Security Considerations 💀

4. Notices 📜

Internet Engineering Task Force

Frame Relay Forum

5. References 📚

6. Editors' Addresses 🎀

Full Copyright Statement 🔒

Acknowledgement 🫶