Network Working Group J. H. Dunn
INTERNET-DRAFT C. E. Martin
Expires: February, 2001 ANC, Inc.
October, 2000
Terminology for Frame Relay Benchmarking
<draft-ietf-bmwg-fr-term-05.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (1999). 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. 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).
I. Background
Dunn & Martin [Page 1]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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.
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.
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
Dunn & Martin [Page 2]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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.
3. Requirements
In this document, the words that are used to define the significance of
each particular requirement are capitalized. These words are:
* "MUST" This word, or the words "REQUIRED" and "SHALL" mean that the
item is an absolute requirement of the specification.
* "SHOULD" This word or the adjective "RECOMMENDED" means that there may
exist valid reasons in particular circumstances to ignore this item, but
the full implications should be understood and the case carefully
weighed before choosing a different course.
* "MAY" This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because it enhances the product,
for example; another vendor may omit the same item.
An implementation is not compliant if it fails to satisfy one or more of
the MUST requirements for the protocols it implements. An
implementation that satisfies all the MUST and all the SHOULD
requirements for its protocols is said to be "unconditionally
compliant"; one that satisfies all the MUST requirements but not all the
SHOULD requirements for its protocols is said to be "conditionally
compliant".
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.
1. Formal Definitions
1.1. Definition Format (from RFC1242)
Dunn & Martin [Page 3]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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 nonconsecutively assigned time slots:
N DS0 time slots (NX56/64Kbps where N = 1 to 24 DS0 time slots per FT1
channel).
Dunn & Martin [Page 4]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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
Dunn & Martin [Page 5]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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).
Dunn & Martin [Page 6]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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
Dunn & Martin [Page 7]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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: 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
Dunn & Martin [Page 8]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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.
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
Dunn & Martin [Page 9]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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.
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
Dunn & Martin [Page 10]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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.
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
Dunn & Martin [Page 11]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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
Dunn & Martin [Page 12]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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
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.
Dunn & Martin [Page 13]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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.
Dunn & Martin [Page 14]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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 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:
Dunn & Martin [Page 15]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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 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
Dunn & Martin [Page 16]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
as 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.
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
Dunn & Martin [Page 17]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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.
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.
Dunn & Martin [Page 18]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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 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:
Dunn & Martin [Page 19]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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)
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
Dunn & Martin [Page 20]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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.
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)
Dunn & Martin [Page 21]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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.
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.
Dunn & Martin [Page 22]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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 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
Dunn & Martin [Page 23]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
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. Disclaimer
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS IS"
basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
6. 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.
Dunn & Martin [Page 24]
INTERNET-DRAFT Terminology for Frame Relay Benchmarking October, 2000
[FRF.13] Frame Relay Forum, Service Level Definitions Implementation
Agreement, August 1998.
[FRMIB] Definitions of Managed Objects for Frame Relay Service, draft-
ietf-frnetmib-frs-mib-09.txt, November, 1999.
7. Editors Addresses
Jeffrey Dunn
Advanced Network Consultants, Inc.
4214 Crest Place, Ellicott City, MD 21043 USA
Phone: +1 (410) 750-1700, E-mail: Jeffrey.Dunn@worldnet.att.net
Cynthia Martin
Advanced Network Consultants, Inc.
4214 Crest Place, Ellicott City, MD 21043 USA
Phone: +1 (410) 750-1700, E-mail: Cynthia.E.Martin@worldnet.att.net
Dunn & Martin [Page 25]
