draft-ietf-bmwg-fr-term-06.txt   rfc3133.txt 
Network Working Group J. H. Dunn Network Working Group J. Dunn
INTERNET-DRAFT C. E. Martin Request for Comments: 3133 C. Martin
Expires: August, 2001 ANC, Inc. Category: Informational ANC, Inc.
June 2001
April, 2001
Terminology for Frame Relay Benchmarking Terminology for Frame Relay Benchmarking
<draft-ietf-bmwg-fr-term-06.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This memo provides information for the Internet community. It does
provisions of Section 10 of RFC2026. Internet-Drafts are working not specify an Internet standard of any kind. Distribution of this
documents of the Internet Engineering Task Force (IETF), its areas, and memo is unlimited.
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 Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This memo discusses and defines terms associated with performance This memo discusses and defines terms associated with performance
benchmarking tests and the results of these tests in the context of benchmarking tests and the results of these tests in the context of
frame relay switching devices. The terms defined in this memo will be frame relay switching devices.
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 I. Background
1. Introduction.
This document provides terminology for Frame Relay switching devices. 1. Introduction
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 This document provides terminology for Frame Relay switching devices.
background section provides the reader with an overview of the It extends terminology already defined for benchmarking network
technology and IETF formalisms. The definitions section is split into interconnect devices in RFCs 1242, 1944 and 2285. Although some of
two sub- sections. The formal definitions sub-section is provided as a the definitions in this memo may be applicable to a broader group of
courtesy to the reader. The measurement definitions sub-section network interconnect devices, the primary focus of the terminology in
contains performance metrics with inherent units. this memo is on Frame Relay Signaling.
The BMWG produces two major classes of documents: Benchmarking This memo contains two major sections: Background and Definitions.
Terminology documents and Benchmarking Methodology documents. The The background section provides the reader with an overview of the
Terminology documents present the benchmarks and other related terms. technology and IETF formalisms. The definitions section is split
The Methodology documents define the procedures required to collect the into two sub-sections. The formal definitions sub-section is
benchmarks cited in the corresponding Terminology documents. provided as a courtesy to the reader. The measurement definitions
sub-section contains performance metrics with inherent units.
For the purposes of computing several of the metrics, certain textual The BMWG produces two major classes of documents: Benchmarking
conventions are required. Specifically: 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.
1) The notation sum {i=1 to N} A_i denotes: the summation of N instances For the purposes of computing several of the metrics, certain textual
of the observable A. For example, the set of observations {1,2,3,4,5} conventions are required. Specifically:
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 1) The notation sum {i=1 to N} A_i denotes: the summation of N
maximum or minimum of the observable A over N instances. For example, instances of the observable A. For example, the set of observations
given the set of observations {1,2,3,4,5}, max {i=1 to 5} = 5 and min {1,2,3,4,5} would yield the result 15.
{I=1 to 5} = 1.
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 2. Existing Definitions
RFC 1242 "Benchmarking Terminology for Network Interconnect Devices" RFC 1242, "Benchmarking Terminology for Network Interconnect
should be consulted before attempting to make use of this document. RFC Devices", should be consulted before attempting to make use of this
1944 "Benchmarking Methodology for Network Interconnect Devices" document. RFC 1944, "Benchmarking Methodology for Network
contains discussions of a number of terms relevant to the benchmarking Interconnect Devices", contains discussions of a number of terms
of switching devices and should also be consulted. RFC 2285 relevant to the benchmarking of switching devices and should also be
"Benchmarking Terminology for LAN Switching Devices" contains a number consulted. RFC 2285, "Benchmarking Terminology for LAN Switching
of terms pertaining to traffic distributions and datagram interarrival. Devices", contains a number of terms pertaining to traffic
For the sake of clarity and continuity this RFC adopts the template for distributions and datagram interarrival. For the sake of clarity and
definitions set out in Section 2 of RFC 1242. continuity this RFC adopts the template for definitions set out in
Section 2 of RFC 1242.
II. Definitions II. Definitions
The definitions presented in this section have been divided into two The definitions presented in this section have been divided into two
groups. The first group is formal definitions, which are required in groups. The first group is formal definitions, which are required in
the definitions of the performance metrics but are not themselves the definitions of the performance metrics but are not themselves
strictly metrics. These definitions are subsumed from other work done strictly metrics. These definitions are subsumed from other work
in other working groups both inside and outside the IETF. They are done in other working groups both inside and outside the IETF. They
provided as a courtesy to the reader. are provided as a courtesy to the reader.
1. Formal Definitions 1. Formal Definitions
1.1. Definition Format (from RFC1242) 1.1. Definition Format (from RFC1242)
Term to be defined. Term to be defined.
Definition: The specific definition for the term. Definition: The specific definition for the term.
Discussion: A brief discussion of the term, its application and any Discussion: A brief discussion of the term, its application and any
restrictions on measurement procedures. restrictions on measurement procedures.
Specification: The working group and document in which the term is Specification: The working group and document in which the term is
specified. Listed in the references. specified. Listed in the references.
1.2. Frame Relay Related Definitions 1.2. Frame Relay Related Definitions
1.2.1. Access Channel 1.2.1. Access Channel
Definition: Access channel refers to the user access channel across which Definition: Access channel refers to the user access channel across
frame relay data travels. Within a given DS-3, T1 or E1 physical line, a which frame relay data travels. Within a given DS-3, T1 or E1
channel can be one of the following, depending of how the line is physical line, a channel can be one of the following, depending of
configured. Possible line configurations are: how the line is configured. Possible line configurations are:
A. Unchannelized: The entire DS-3/T1/E1 line is considered a channel, A. Unchannelized: The entire DS-3/T1/E1 line is considered a channel,
where: where:
The DS-3 line operates at speeds of 45 Mbps and is a single channel. The The DS-3 line operates at speeds of 45 Mbps and is a single channel.
T1 line operates at speeds of 1.536 Mbps and is a single channel consisting The T1 line operates at speeds of 1.536 Mbps and is a single channel
of 24 T1 time slots. The E1 line operates at speeds of 1.984 Mbps and is a consisting of 24 T1 time slots. The E1 line operates at speeds of
single channel consisting of 30 DS0 time slots. 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 B. Channelized: The channel is any one of N time slots within a given
line, where: line, where:
The T1 line consists of any one or more channels. Each channel is any one The T1 line consists of any one or more channels. Each channel is
of 24 time slots. The T1 line operates at speeds in multiples of 56/64 Kbps any one of 24 time slots. The T1 line operates at speeds in
to 1.536 Mbps, with aggregate speed not exceeding 1.536 Mbps. The E1 line multiples of 56/64 Kbps to 1.536 Mbps, with aggregate speed not
consists of one or more channels. Each channel is any one of 31 time slots. exceeding 1.536 Mbps. The E1 line consists of one or more channels.
The E1 line operates at speeds in multiples of 64 Kbps to 1.984 Mbps, with Each channel is any one of 31 time slots. The E1 line operates at
aggregate speed not exceeding 1.984 Mbps. 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 C. Fractional: The T1/E1 channel is one of the following groupings of
consecutively or nonconsecutively assigned time slots: consecutively or non-consecutively assigned time slots:
N DS0 time slots (NX56/64Kbps where N = 1 to 24 DS0 time slots per FT1 N DS0 time slots (NX56/64Kbps where N = 1 to 24 DS0 time slots per
channel). FT1 channel).
N E1 time slots (NX64Kbps, where N = 1 to 30 DS0 time slots per E1 N E1 time slots (NX64Kbps, where N = 1 to 30 DS0 time slots per E1
channel). channel).
Discussion: Access channels specify the physical layer interface speed of Discussion: Access channels specify the physical layer interface
a DTE or DCE. In the case of a DTE, this may not correspond to either the speed of a DTE or DCE. In the case of a DTE, this may not correspond
CIR or EIR. Specifically, based on the service level agreement in place, to either the CIR or EIR. Specifically, based on the service level
the user may not be able to access the entire bandwidth of the access agreement in place, the user may not be able to access the entire
channel. bandwidth of the access channel.
Specification: FRF Specification: FRF
1.2.2. Access Rate (AR) 1.2.2. Access Rate (AR)
Definition: The data rate of the user access channel. The speed of the Definition: The data rate of the user access channel. The speed of
access channel determines how rapidly (maximum rate) the end user can the access channel determines how rapidly (maximum rate) the end user
inject data into a frame relay network. can inject data into a frame relay network.
Discussion: See Access Channel. Discussion: See Access Channel.
Specification: FRF Specification: FRF
1.2.3. Backward Explicit Congestion Notification (BECN) 1.2.3. Backward Explicit Congestion Notification (BECN)
Definition: BECN is a bit in the frame relay header. The bit is set by a Definition: BECN is a bit in the frame relay header. The bit is set
congested network node in any frame that is traveling in the reverse by a congested network node in any frame that is traveling in the
direction of the congestion. reverse direction of the congestion.
Discussion: When a DTE receives frames with the BECN bit asserted, it Discussion: When a DTE receives frames with the BECN bit asserted, it
should begin congestion avoidance procedures. Since the BECN frames are should begin congestion avoidance procedures. Since the BECN frames
traveling in the opposite direction as the congested traffic, the DTE will are traveling in the opposite direction as the congested traffic, the
be the sender. The frame relay layer may communicate the possibility of DTE will be the sender. The frame relay layer may communicate the
congestion to higher layers, which have inherent congestion avoidance possibility of congestion to higher layers, which have inherent
procedures, such as TCP. See Frame Relay Frame. congestion avoidance procedures, such as TCP. See Frame Relay Frame.
Specification: FRF Specification: FRF
1.2.4. Burst Excess(Be) 1.2.4. Burst Excess(Be)
Definition: The maximum amount of uncommitted data (in bits) in excess of Definition: The maximum amount of uncommitted data (in bits) in
Committed Burst Size (Bc) that a frame relay network can attempt to deliver excess of Committed Burst Size (Bc) that a frame relay network can
during a Committed Rate Measurement Interval (Tc). This data (Be) generally attempt to deliver during a Committed Rate Measurement Interval (Tc).
is delivered with a lower probability than Bc. The network treats Be data This data (Be) generally is delivered with a lower probability than
as discard eligible. Bc. The network treats Be data as discard eligible.
Discussion: See also Committed burst Size (Bc), Committed Rate Measurement Discussion: See also Committed burst Size (Bc), Committed Rate
Interval (Tc) and Discard Eligible (De). Measurement Interval (Tc) and Discard Eligible (De).
Specification: FRF Specification: FRF
1.2.5. Committed Burst Size (Bc) 1.2.5. Committed Burst Size (Bc)
Definition: The maximum amount of data (in bits) that the network agrees to Definition: The maximum amount of data (in bits) that the network
transfer, under normal conditions, during a time interval Tc. agrees to transfer, under normal conditions, during a time interval
Tc.
Discussion: See also Excess Burst Size (Be) and Committed Rate Measurement Discussion: See also Excess Burst Size (Be) and Committed Rate
Interval (Tc). Measurement Interval (Tc).
Specification: FRF Specification: FRF
1.2.6. Committed Information Rate (CIR) 1.2.6. Committed Information Rate (CIR)
Definition: CIR is the transport speed the frame relay network will Definition: CIR is the transport speed the frame relay network will
maintain between service locations when data is presented. maintain between service locations when data is presented.
Discussion: CIR specifies the guaranteed data rate between two frame relay Discussion: CIR specifies the guaranteed data rate between two frame
terminal connected by a frame relay network. Data presented to the network relay terminal connected by a frame relay network. Data presented to
in excess of this data rate and below the Excess Information Rate (EIR) the network in excess of this data rate and below the Excess
will be marked as Discard Eligible and may be dropped. Information Rate (EIR) will be marked as Discard Eligible and may be
dropped.
Specification: FRF Specification: FRF
1.2.7. Committed Rate Measurement Interval (Tc) 1.2.7. Committed Rate Measurement Interval (Tc)
Definition: The time interval during which the user can send only Bc- Definition: The time interval during which the user can send only
committed amount of data and Be excess amount of data. In general, the Bc-committed amount of data and Be excess amount of data. In
duration of Tc is proportional to the "burstiness" of the traffic. Tc is general, the duration of Tc is proportional to the "burstiness" of
computed (from the subscription parameters of CIR and Bc) as Tc = Bc/CIR. the traffic. Tc is computed (from the subscription parameters of CIR
Tc is not a periodic time interval. Instead, it is used only to measure and Bc) as Tc = Bc/CIR. Tc is not a periodic time interval.
incoming data, during which it acts like a sliding window. Incoming data Instead, it is used only to measure incoming data, during which it
triggers the Tc interval, which continues until it completes its computed acts like a sliding window. Incoming data triggers the Tc interval,
duration. which continues until it completes its computed duration.
Discussion: See also Committed Information Rate (CIR) and committed Burst Discussion: See also Committed Information Rate (CIR) and committed
Size (Bc). Burst Size (Bc).
Specification: FRF Specification: FRF
1.2.8. Cyclic Redundancy Check (CRC) 1.2.8. Cyclic Redundancy Check (CRC)
Definition: A computational means to ensure the accuracy of frames Definition: A computational means to ensure the accuracy of frames
transmitted between devices in a frame relay network. The mathematical transmitted between devices in a frame relay network. The
function is computed, before the frame is transmitted, at the originating mathematical function is computed, before the frame is transmitted,
device. Its numerical value is computed based on the content of the frame. at the originating device. Its numerical value is computed based on
This value is compared with a recomputed value of the function at the the content of the frame. This value is compared with a recomputed
destination device. See also Frame Check Sequence (FCS). 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 Discussion: CRC is not a measurement, but it is possible to measure
amount of time to perform a CRC on a string of bits. This measurement will the amount of time to perform a CRC on a string of bits. This
not be addressed in this document. measurement will not be addressed in this document.
Specification: FRF Specification: FRF
1.2.9. Data Communications Equipment (DCE) 1.2.9. Data Communications Equipment (DCE)
Definition: Term defined by both frame relay and X.25 committees, that Definition: Term defined by both frame relay and X.25 committees,
applies to switching equipment and is distinguished from the devices that that applies to switching equipment and is distinguished from the
attach to the network (DTE). devices that attach to the network (DTE).
Discussion: Also see DTE. Discussion: Also see DTE.
Specification: FRF Specification: FRF
1.2.10. Data Link Connection Identifier (DLCI) 1.2.10. Data Link Connection Identifier (DLCI)
Definition: A unique number assigned to a PVC end point in a frame relay Definition: A unique number assigned to a PVC end point in a frame
network. Identifies a particular PVC endpoint within a user's access relay network. Identifies a particular PVC endpoint within a user's
channel in a frame relay network and has local significance only to that access channel in a frame relay network and has local significance
channel. only to that channel.
Discussion: None. Discussion: None.
Specification: FRF Specification: FRF
1.2.11. Data Terminal Equipment (DTE) 1.2.11. Data Terminal Equipment (DTE)
Definition: Any network equipment terminating a network connection and is Definition: Any network equipment terminating a network connection
attached to the network. This is distinguished from Data Communications and is attached to the network. This is distinguished from Data
Equipment (DCE), which provides switching and connectivity within the Communications Equipment (DCE), which provides switching and
network. connectivity within the network.
Discussion: See also DCE. Discussion: See also DCE.
Specification: FRF Specification: FRF
1.2.12. Discard Eligible (DE) 1.2.12. Discard Eligible (DE)
Definition: This is a bit in the frame relay header that provides a two Definition: This is a bit in the frame relay header that provides a
level priority indicator, used to bias discard frames in the event of two level priority indicator, used to bias discard frames in the
congestion toward lower priority frames. Similar to the CLP bit in ATM. event of congestion toward lower priority frames. Similar to the CLP
bit in ATM.
Discussion: See Frame Relay Frame. Discussion: See Frame Relay Frame.
Specification: FRF Specification: FRF
1.2.13. Discardable frames 1.2.13. Discardable frames
Definition: Frames identified as being eligible to be dropped in the event Definition: Frames identified as being eligible to be dropped in the
of congestion. event of congestion.
Discussion: The discard eligible field in the frame relay header is the Discussion: The discard eligible field in the frame relay header is
correct -- and by far the most common -- means of indicating which frames the correct -- and by far the most common -- means of indicating
may be dropped in the event of congestion. However, DE is not the only which frames may be dropped in the event of congestion. However, DE
means of identifying which frames may be dropped. There are at least three is not the only means of identifying which frames may be dropped.
other cases that apply. There are at least three other cases that apply.
In the first case, network devices may prioritize frame relay traffic by In the first case, network devices may prioritize frame relay traffic
non-DE means. For example, many service providers prioritize traffic on a by non-DE means. For example, many service providers prioritize
per-PVC basis. In this instance, any traffic from a given DLCI (data link traffic on a per-PVC basis. In this instance, any traffic from a
channel identifier) may be dropped during congestion, regardless of whether given DLCI (data link channel identifier) may be dropped during
DE is set. congestion, regardless of whether DE is set.
In the second case, some implementations use upper-layer criteria, such as In the second case, some implementations use upper-layer criteria,
IP addresses or TCP or UDP port numbers, to prioritize traffic within a such as IP addresses or TCP or UDP port numbers, to prioritize
single PVC. In this instance, the network device may evaluate discard traffic within a single PVC. In this instance, the network device
eligibility based on upper-layer criteria rather than the presence or may evaluate discard eligibility based on upper-layer criteria rather
absence of a DE bit. than the presence or absence of a DE bit.
In the third case, the frame is discarded because of an error in the frame. In the third case, the frame is discarded because of an error in the
Specifically, frames that are too long or too short, frames that are not a frame. Specifically, frames that are too long or too short, frames
multiple of 8 bits in length, frames with an invalid or unrecognized DLCI, that are not a multiple of 8 bits in length, frames with an invalid
frames with an abort sequence, frames with improper flag delimitation, and or unrecognized DLCI, frames with an abort sequence, frames with
frames that fail FCS. improper flag delimitation, and frames that fail FCS.
Specification: FRMIB Specification: FRMIB
1.2.14. Discarded frames 1.2.14. Discarded frames
Definition: Those frames dropped by a network device. Definition: Those frames dropped by a network device.
Discussion: Discardable and discarded frames are not synonymous. Some Discussion: Discardable and discarded frames are not synonymous.
implementations may ignore DE bits or other criteria, even though they Some implementations may ignore DE bits or other criteria, even
supposedly use such criteria to determine which frames to drop in the event though they supposedly use such criteria to determine which frames to
of congestion. drop in the event of congestion.
In other cases, a frame with its DE bit set may not be dropped. One example In other cases, a frame with its DE bit set may not be dropped. One
of this is in cases where congestion clears before the frame can be example of this is in cases where congestion clears before the frame
evaluated. can be evaluated.
Specification: DN Specification: DN
1.2.15. Forward Explicit Congestion Notification (FECN) 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 Definition: FECN is a bit in the frame relay header. The bit is set
should begin congestion avoidance procedures. Since the FECN frames are by a congested network node in any frame that is traveling in the
traveling in the same direction as the congested traffic, the DTE will be same direction of the congestion.
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 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) 1.2.16. Frame Check Sequence (FCS)
Definition: The standard 16-bit cyclic redundancy check used for HDLC and Definition: The standard 16-bit cyclic redundancy check used for HDLC
frame relay frames. The FCS detects bit errors occurring in the bits of the and frame relay frames. The FCS detects bit errors occurring in the
frame between the opening flag and the FCS, and is only effective in bits of the frame between the opening flag and the FCS, and is only
detecting errors in frames no larger than 4096 octets. See also Cyclic effective in detecting errors in frames no larger than 4096 octets.
Redundancy Check (CRC). See also Cyclic Redundancy Check (CRC).
Discussion: FCS is not a measurement, but it is possible to measure the Discussion: FCS is not a measurement, but it is possible to measure
amount of time to perform a FCS on a string of bits. This measurement will the amount of time to perform a FCS on a string of bits. This
not be addressed in this document. measurement will not be addressed in this document.
Specification: FRF Specification: FRF
1.2.17. Frame Entry Event 1.2.17. Frame Entry Event
Definition: Frame enters a network section or end system. The event occurs Definition: Frame enters a network section or end system. The event
when the last bit of the closing flag of the frame crosses the boundary. occurs when the last bit of the closing flag of the frame crosses the
boundary.
Discussion: None. Discussion: None.
Specification: FRF.13 Specification: FRF.13
1.2.18. Frame Exit Event 1.2.18. Frame Exit Event
Definition: Frame exits a network section or end system. The event occurs Definition: Frame exits a network section or end system. The event
when the first bit of the address field of the frame crosses the boundary. occurs when the first bit of the address field of the frame crosses
the boundary.
Discussion: None. Discussion: None.
Specification: FRF.13 Specification: FRF.13
1.2.19. Frame Relay 1.2.19. Frame Relay
Definition: A high-performance interface for packet-switching networks; Definition: A high-performance interface for packet-switching
considered more efficient that X.25. Frame relay technology can handle networks; considered more efficient that X.25. Frame relay
"bursty" communications that have rapidly changing bandwidth requirements. technology can handle "bursty" communications that have rapidly
changing bandwidth requirements.
Discussion: None. Discussion: None.
Specification: FRF Specification: FRF
1.2.20. Frame Relay Frame 1.2.20. Frame Relay Frame
Definition: A logical grouping of information sent as a link-layer unit Definition: A logical grouping of information sent as a link-layer
over a transmission medium. Frame relay frames consist of a pair of flags, unit over a transmission medium. Frame relay frames consist of a
a header, a user data payload and a Frame Check Sequence (FCS). Bit pair of flags, a header, a user data payload and a Frame Check
stuffing differentiates user data bytes from flags. By default, the header Sequence (FCS). Bit stuffing differentiates user data bytes from
is two octets, of which 10 bits are the Data Link Connection Identifier flags. By default, the header is two octets, of which 10 bits are
(DLCI), 1 bit in each octet is used for address extension (AE), and 1 bit the Data Link Connection Identifier (DLCI), 1 bit in each octet is
each for Forward Explicit Congestion Notification (FECN), Backward Explicit used for address extension (AE), and 1 bit each for Forward Explicit
Congestion Notification (BECN) Command/Response (C/R) and Discard Eligible Congestion Notification (FECN), Backward Explicit Congestion
(DE). The EA bit is set to one in the final octet containing the DLCI. A Notification (BECN) Command/Response (C/R) and Discard Eligible (DE).
header may span 2, 3 or 4 octets. 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 Bit 7 6 5 4 3 2 1 0
|---|---|---|---|---|---|---|---| |---|---|---|---|---|---|---|---|
| FLAG | | FLAG |
|-------------------------------| |-------------------------------|
| Upper 6 bits of DLCI |C/R|AE | | Upper 6 bits of DLCI |C/R|AE |
|-------------------------------| |-------------------------------|
| DLCI |FE |BE |DE |AE | | DLCI |FE |BE |DE |AE |
| |CN |CN | | | | |CN |CN | | |
|-------------------------------| |-------------------------------|
| User Data up to | | User Data up to |
| 1600 Octets | | 1600 Octets |
|-------------------------------| |-------------------------------|
| First Octet of FCS | | First Octet of FCS |
|-------------------------------| |-------------------------------|
| Second Octet of FCS | | Second Octet of FCS |
|-------------------------------| |-------------------------------|
| FLAG | | FLAG |
|-------------------------------| |-------------------------------|
Discussion: Frame Relay headers spanning 3 or 4 octets will not be Discussion: Frame Relay headers spanning 3 or 4 octets will not be
discussed in this document. Note, the measurements described later in discussed in this document. Note, the measurements described later
this document are based on 2 octet headers. If longer headers are used, in this document are based on 2 octet headers. If longer headers are
the metric values must take into account the associated overhead. See used, the metric values must take into account the associated
BECN, DE, DLCI and FECN. overhead. See BECN, DE, DLCI and FECN.
Specification: FRF Specification: FRF
1.2.21. Excess Information Rate (EIR) 1.2.21. Excess Information Rate (EIR)
Definition: See Burst Excess. Definition: See Burst Excess.
Discussion: None. Discussion: None.
Specification: FRF Specification: FRF
1.2.22. Network Interworking (FRF.5) 1.2.22. Network Interworking (FRF.5)
Definition: FRF.5 defines a protocol mapping called Network Interworking between Definition: FRF.5 defines a protocol mapping called Network
Frame Relay and Asynchronous Transfer Mode (ATM). Protocol mapping occurs when Interworking between
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. 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.
Specification: FRF.5 Discussion: None.
Specification: FRF.5
1.2.23. Port speed 1.2.23. Port speed
Definition: See Access Rate Definition: See Access Rate
Discussion: None. Discussion: None.
Specification: FRF
Specification: FRF
1.2.24. Service Interworking (FRF.8) 1.2.24. Service Interworking (FRF.8)
Definition: FRF.8 defines a protocol encapsulation called Service Interworking. Definition: FRF.8 defines a protocol encapsulation called Service
Protocol encapsulation occurs when the conversions in the network or in the Interworking. Protocol encapsulation occurs when the conversions in
terminals are such that the protocols used to provide one service make use of the network or in the terminals are such that the protocols used to
the layer service provided by another protocol. This means that at the provide one service make use of the layer service provided by another
interworking point, the two protocols are stacked. When encapsulation is protocol. This means that at the interworking point, the two
performed by the terminal, this scenario is also called interworking by port protocols are stacked. When encapsulation is performed by the
access. Specifically, the ATM service user performs no Frame Relaying specific terminal, this scenario is also called interworking by port access.
functions, and Frame Relaying service user performs no ATM service specific Specifically, the ATM service user performs no Frame Relaying
functions. specific functions, and Frame Relaying service user performs no ATM
service specific functions.
Discussion: None. Discussion: None.
Specification: FRF.8 Specification: FRF.8
1.2.25. Service Availability Parameters 1.2.25. Service Availability Parameters
Definition: The service availability parameters report the operational Definition: The service availability parameters report the
readiness of individual frame relay virtual connections. Service operational readiness of individual frame relay virtual connections.
availability is affected by service outages. Service availability is affected by service outages.
Discussion: Service availability parameters provide metrics for Discussion: Service availability parameters provide metrics for
assessment of frame relay network health and are used to monitor assessment of frame relay network health and are used to monitor
compliance with service level agreements. See Services Outages. compliance with service level agreements. See Services Outages.
Specification: FRF.13 Specification: FRF.13
1.2.26. Service Outages 1.2.26. Service Outages
Definition: Any event that interrupts the transport of frame relay traffic. Two Definition: Any event that interrupts the transport of frame relay
types of outages are differentiated: traffic. Two types of outages are differentiated:
1) Fault outages: Outages resulting from faults in the network and thus tracked 1) Fault outages: Outages resulting from faults in the network and
by the service availability parameters, and thus tracked by the service availability parameters, and
2) Excluded outages: Outages resulting from faults beyond the control of 2) Excluded outages: Outages resulting from faults beyond the control
the network as well as scheduled maintenance. of the network as well as scheduled maintenance.
Discussion: Service availability can be defined on a per-VC basis and/or on a Discussion: Service availability can be defined on a per-VC basis
per-port basis. Frame relay port-based service availability parameters are not and/or on a per-port basis. Frame relay port-based service
addressed in this document. See Service Availability Parameters. availability parameters are not addressed in this document. See
Service Availability Parameters.
Specification: FRF.13 Specification: FRF.13
2. Performance Metrics 2. Performance Metrics
2.1. Definition Format (from RFC1242) 2.1. Definition Format (from RFC1242)
Metric to be defined. Metric to be defined.
Definition: The specific definition for the metric. Definition: The specific definition for the metric.
Discussion: A brief discussion of the metric, its application and any Discussion: A brief discussion of the metric, its application and
restrictions on measurement procedures. any restrictions on measurement procedures.
Measurement units: Intrinsic units used to quantify this metric. This Measurement units: Intrinsic units used to quantify this metric.
includes subsidiary units, e.g. microseconds are acceptable if the This includes subsidiary units, e.g., microseconds are acceptable if
intrinsic unit is seconds. the intrinsic unit is seconds.
2.2. Definitions 2.2. Definitions
2.2.1. Physical Layer- Plesiochronous Data Hierarchy (PDH) 2.2.1. Physical Layer-Plesiochronous Data Hierarchy (PDH)
2.2.1.1. Alarm Indication Signal (AIS) 2.2.1.1. Alarm Indication Signal (AIS)
Definition: An all 1's frame transmitted after the DTE or DCE detects a Definition: An all 1's frame transmitted after the DTE or DCE detects
defect for 2.5 s +/- 0.5 s. a defect for 2.5 s +/- 0.5 s.
Discussion: An AIS will cause loss of information in the PDH frame, which Discussion: An AIS will cause loss of information in the PDH frame,
contains a frame relay frame which may contain IP datagrams. which contains a frame relay frame which may contain IP datagrams.
Measurement units: Dimensionless. Measurement units: Dimensionless.
2.2.1.2. Loss of Frame (LOF) 2.2.1.2. Loss of Frame (LOF)
Definition: An NE transmits an LOF when an OOF condition persists. Definition: An NE transmits an LOF when an OOF condition persists.
Discussion: A LOF will cause loss of information in the PDH frame, which Discussion: A LOF will cause loss of information in the PDH frame,
contains a frame relay frame which may contain IP datagrams. which contains a frame relay frame which may contain IP datagrams.
Measurement units: Dimensionless. Measurement units: Dimensionless.
2.2.1.3. Loss of Signal (LOS) 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 Definition: Indicates that there are no transitions occurring in the
contains a frame relay frame which may contain IP datagrams. received signal.
Measurement units: Dimensionless. 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) 2.2.1.4. Out of Frame (OOF)
Definition: An NE transmits an OOF downstream when it receives framing Definition: An NE transmits an OOF downstream when it receives
errors in a specified number of consecutive frame bit positions. framing errors in a specified number of consecutive frame bit
positions.
Discussion: An OOF will cause loss of information in the PDH frame which Discussion: An OOF will cause loss of information in the PDH frame
contains a frame relay frame which may contain IP datagrams. which contains a frame relay frame which may contain IP datagrams.
Measurement units: Dimensionless. Measurement units: Dimensionless.
2.2.1.5. Remote Alarm Indication (RAI) 2.2.1.5. Remote Alarm Indication (RAI)
Definition: Previously called Yellow Alarm. Transmitted upstream by an NE Definition: Previously called Yellow Alarm. Transmitted upstream by
to indicate that it detected an LOS, LOF, or AIS. an NE to indicate that it detected an LOS, LOF, or AIS.
Discussion: An RAI will cause loss of information in the transmitted PDH Discussion: An RAI will cause loss of information in the transmitted
frame, which may contain a frame relay frame, which, in turn, may contain PDH frame, which may contain a frame relay frame, which, in turn, may
IP datagrams. contain IP datagrams.
Measurement units: Dimensionless. Measurement units: Dimensionless.
2.2.2. Frame Relay Layer 2.2.2. Frame Relay Layer
2.2.2.1. Data Delivery Ratio (DDR) 2.2.2.1. Data Delivery Ratio (DDR)
Definition: The DDR service level parameter reports the networks Definition: The DDR service level parameter reports the networks
effectiveness in transporting offered data (payload without address field effectiveness in transporting offered data (payload without address
or FCS) in one direction of a single virtual connection. The DDR is a ratio field or FCS) in one direction of a single virtual connection. The
of successful payload octets received to attempted payload octets DDR is a ratio of successful payload octets received to attempted
transmitted. Attempted payload octets transmitted are referred to as payload octets transmitted. Attempted payload octets transmitted are
DataOffered. Successfully delivered payload octets are referred to as referred to as DataOffered. Successfully delivered payload octets
DataDelivered. These loads are further differentiated as being within the are referred to as DataDelivered. These loads are further
committed information rate or as burst excess. differentiated as being within the committed information rate or as
burst excess.
Three data relay ratios may be reported:
Data Delivery Ratio (DDR): Three data relay ratios may be reported:
(DataDelivered_c + DataDelivered_e DataDelivered_e+c Data Delivery Ratio (DDR):
DDR = --------------------------------- = -----------------
(DataOffered_c + DataOffered_e) DataOffered_e+c
Data Delivery Ratio (DDR_c) for load consisting of frames within the committed (DataDelivered_c + DataDelivered_e DataDelivered_e+c
information rate: DDR = --------------------------------- = -----------------
(DataOffered_c + DataOffered_e) DataOffered_e+c
DataDelivered_c Data Delivery Ratio (DDR_c) for load consisting of frames within the
DDR_c = ------------- committed information rate:
DataOffered_c
Data Delivery Ratio (DDR_e) for load in excess of the committed information DataDelivered_c
rate: DDR_c = -------------
DataOffered_c
DataDelivered_e Data Delivery Ratio (DDR_e) for load in excess of the committed
DDR_e = --------------- information rate:
DataOffered_e
where DataDelivered_e
DDR_e = ---------------
DataOffered_e
DataDelivered_c: Successfully delivered data payload octets within committed where
information rate,
DataDelivered_e: Successfully delivered data payload octets in excess of CIR, DataDelivered_c: Successfully delivered data payload octets within
committed information rate,
DataDelivereD_e+c: Successfully delivered total data payload octets, including those within committed information rate and those in excess of CIR, DataDelivered_e: Successfully delivered data payload octets in excess
of CIR,
DataOffered_c: Attempted data payload octet transmissions within committed DataDelivereD_e+c: Successfully delivered total data payload octets,
information rate, including those within committed information rate and those in excess
of CIR,
DataOffered_e: Attempted data payload octet transmissions in excess of CIR DataOffered_c: Attempted data payload octet transmissions within
committed information rate,
and DataOffered_e: Attempted data payload octet transmissions in excess
of CIR
DataOffered_e+c: Attempted total data payload octet transmissions, including and
those within committed information rate and those in excess of CIR 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 Each direction of a full duplex connection has a discrete set of data
ratios. delivery ratios.
Discussion: Data delivery ratio measurements may not be representative of data Discussion: Data delivery ratio measurements may not be
delivery effectiveness for a given application. For example, the discarding of representative of data delivery effectiveness for a given
a small frame containing an acknowledgement message may result in the application. For example, the discarding of a small frame containing
retransmission of a large number of data frames. In such an event, a good data an acknowledgement message may result in the retransmission of a
delivery ratio would be reported while the user experienced poor performance. 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. Measurement units: dimensionless.
2.2.2.2. Frame Delivery Ratio (FDR) 2.2.2.2. Frame Delivery Ratio (FDR)
Definition: The FDR service level parameter reports the networks effectiveness Definition: The FDR service level parameter reports the networks
in transporting an offered frame relay load in one direction of a single virtual effectiveness in transporting an offered frame relay load in one
connection. The FDR is a ratio of successful frame receptions to attempted frame direction of a single virtual connection. The FDR is a ratio of
transmissions. Attempted frame transmissions are referred to as Frames Offered. successful frame receptions to attempted frame transmissions.
Successfully delivered frames are referred to as Frames Delivered. These loads Attempted frame transmissions are referred to as Frames Offered.
may be further differentiated as being within the committed information rate or Successfully delivered frames are referred to as Frames Delivered.
as burst excess. 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 Frame Delivery Ratio (FDR):
FDR = ------------------------------------- = -------------------
(FramesOffered_c + FramesOffered_e) FramesOffered_e+c
Frame Delivery Ratio (FDR_c) for load consisting of frames within the committed (FramesDelivered_c + FramesDelivered_e) FramesDelivered_e+c
information rate: FDR = ------------------------------------- = -------------------
(FramesOffered_c + FramesOffered_e) FramesOffered_e+c
FramesDelivered_c Frame Delivery Ratio (FDR_c) for load consisting of frames within the
FDR_c = ----------------- committed information rate:
FramesOffered_c
Frame Delivery Ratio (FDR_c) for load in excess of the committed information FramesDelivered_c
rate: FDR_c = -----------------
FramesOffered_c
FramesDelivered_e Frame Delivery Ratio (FDR_c) for load in excess of the committed
FDR_e = ----------------- information rate:
FramesOffered_e
where FramesDelivered_e
FramesDelivered_c: Successfully delivered frames within committed information rate, FDR_e = -----------------
FramesOffered_e
FramesDelivered_e: Successfully delivered frames in excess of CIR, where
FramesDelivered_e+c: Successfully delivered total frames, including those within committed information rate and those in excess of CIR, FramesDelivered_c: Successfully delivered frames within committed
information rate,
FramesOffered_c: Attempted frame transmissions within committed information rate, FramesDelivered_e: Successfully delivered frames in excess of CIR,
FramesOffered_e: Attempted frame transmissions in excess of CIR FramesDelivered_e+c: Successfully delivered total frames, including
those within committed information rate and those in excess of CIR,
and FramesOffered_c: Attempted frame transmissions within committed
information rate,
FramesOffered_e+c: Attempted total frame transmissions, including those within committed information rate and those in excess of CIR. FramesOffered_e: Attempted frame transmissions in excess of CIR
An independent set of frame delivery ratios exists for each direction of a full and
duplex connection.
Discussion: Frame delivery ratio measurements may not be representative of frame FramesOffered_e+c: Attempted total frame transmissions, including
delivery effectiveness for a given application. For example, the discarding of those within committed information rate and those in excess of CIR.
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. 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) 2.2.2.3. Frame Discard Ratio (FDR)
Definition: The number of received frames that are discarded because of a frame Definition: The number of received frames that are discarded because
error divided by the total number of transmitted frames in one direction of a of a frame error divided by the total number of transmitted frames in
single virtual connection. Frame errors are defined as follows: one direction of a single virtual connection. Frame errors are
defined as follows:
1) frames that are too long or too short, 1) frames that are too long or too short,
2) frames that are not a multiple of 8 bits in length, 2) frames that are not a multiple of 8 bits in length,
3) frames with an invalid or unrecognized DLCI, 3) frames with an invalid or unrecognized DLCI,
4) frames with an abort sequence, 4) frames with an abort sequence,
5) frames with improper flag delimitation, 5) frames with improper flag delimitation,
6) frames that fail FCS. 6) frames that fail FCS.
The formal definition of frame discard ratio is as follows: The formal definition of frame discard ratio is as follows:
sum {i=1 to N} fr_i sum {i=1 to N} fr_i
FDR = ------------------- FDR = -------------------
sum {i=1 to N} ft_i, sum {i=1 to N} ft_i,
where where
fr_i is the number of successfully delivered frames for a particular DLCI at second i fr_i is the number of successfully delivered frames for a particular
DLCI at second i
and 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. 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 Discussion: Frame discards can adversely effect applications running
FR. In general, frame discards will negatively impact TCP throughput; however, on IP over FR. In general, frame discards will negatively impact TCP
in the case of frame discard due to frame error, frame discard will improve throughput; however, in the case of frame discard due to frame error,
performance by dropping errored frames. As a result, these frames will not frame discard will improve performance by dropping errored frames.
adversely effect the forwarding of retransmitted frames As a result, these frames will not adversely effect the forwarding of
retransmitted frames
Measurement units: dimensionless. Measurement units: dimensionless.
2.2.2.4. Frame Error Ratio (FER) 2.2.2.4. Frame Error Ratio (FER)
Definition: The number of received frames that contain an error in the frame Definition: The number of received frames that contain an error in
payload divided by the total number of transmitted frames in one direction of a the frame payload divided by the total number of transmitted frames
single virtual connection. in one direction of a single virtual connection.
The formal definition of frame error ratio is as follows: The formal definition of frame error ratio is as follows:
sum {i=1 to N} fe_i sum {i=1 to N} fe_i
FER = ------------------- FER = -------------------
sum {i=1 to N} ft_i, sum {i=1 to N} ft_i,
where where
fe_i is the number of frames containing a payload error for a particular DLCI at second i fe_i is the number of frames containing a payload error for a
particular DLCI at second i
and 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. 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 Discussion: The delivery of frames containing errors will adversely
applications running on IP over FR. Typically, these errors are caused by effect applications running on IP over FR. Typically, these errors
transmission errors and flagged as failed FCS frames; however, when Frame Relay are caused by transmission errors and flagged as failed FCS frames;
to ATM Network interworking is used, an error may be injected in the frame however, when Frame Relay to ATM Network interworking is used, an
payload which, in turn, is encapsulated into an AAL5 PDU (see RFC 2761 for a error may be injected in the frame payload which, in turn, is
discussion of AAL5 related metrics). encapsulated into an AAL5 PDU (see RFC 2761 for a discussion of AAL5
related metrics).
Measurement units: dimensionless. Measurement units: dimensionless.
2.2.2.5. Frame Excess Ratio (FXR) 2.2.2.5. Frame Excess Ratio (FXR)
Definition: The number of frames received by the network and treated as excess Definition: The number of frames received by the network and treated
traffic divided by the total number of transmitted frames in one direction of a as excess traffic divided by the total number of transmitted frames
single virtual connection. Frames which are sent to the network with DE set to in one direction of a single virtual connection. Frames which are
zero are treated as excess when more than Bc bits are submitted to the network sent to the network with DE set to zero are treated as excess when
during the Committed Information Rate Measurement Interval (Tc). Excess traffic more than Bc bits are submitted to the network during the Committed
may or may not be discarded at the ingress if more than Bc + Be bits are Information Rate Measurement Interval (Tc). Excess traffic may or
submitted to the network during Tc. Traffic discarded at the ingress is not may not be discarded at the ingress if more than Bc + Be bits are
recorded in this measurement. Frames which are sent to the network with DE set submitted to the network during Tc. Traffic discarded at the ingress
to one are also treated as excess traffic. 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: The formal definition of frame excess ratio is as follows:
sum {i=1 to N} fc_i sum {i=1 to N} fc_i
FXR = 1 - ------------------- FXR = 1 - -------------------
sum {i=1 to N} ft_i, sum {i=1 to N} ft_i,
where where
fc_i is the total number of frames which were submitted within the traffic fc_i is the total number of frames which were submitted within the
contract for a particular DLCI at second i traffic contract for a particular DLCI at second i
and and
ft_i is the total number of attempted frame transmissions for a particular DLCI at second i. 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 Discussion: Frame discards can adversely effect applications running
FR. Specifically, frame discards will negatively impact TCP throughput. on IP over FR. Specifically, frame discards will negatively impact
TCP throughput.
Measurement units: dimensionless. Measurement units: dimensionless.
2.2.2.6. Frame Loss Ratio (FLR) 2.2.2.6. Frame Loss Ratio (FLR)
Definition: The FLR is a ratio of successful frame receptions to attempted frame Definition: The FLR is a ratio of successful frame receptions to
transmissions at the committed information rate, in one direction of a single attempted frame transmissions at the committed information rate, in
virtual connection. Attempted frame transmissions are referred to as Frames one direction of a single virtual connection. Attempted frame
Offered. Successfully delivered frames are referred to as Frames Delivered. 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: The formal definition of frame loss ratio is as follows:
FramesDelivered_c FramesDelivered_c
FLR = 1- ----------------- FLR = 1- -----------------
FramesOffered_c, FramesOffered_c,
where where
FramesDelivered_c is the successfully delivered frames within committed FramesDelivered_c is the successfully delivered frames within
information rate for a given DLCI committed information rate for a given DLCI
and and
FramesOffered_c is the attempted frame transmissions within committed FramesOffered_c is the attempted frame transmissions within committed
information rate for a given DLCI information rate for a given DLCI
An independent set of frame delivery ratios exists for each direction of a full An independent set of frame delivery ratios exists for each direction
duplex connection. of a full duplex connection.
Discussion: Frame delivery loss measurements may not be representative of frame Discussion: Frame delivery loss measurements may not be
delivery effectiveness for a given application. For example, the loss of a representative of frame delivery effectiveness for a given
small frame containing an acknowledgement message may result in the application. For example, the loss of a small frame containing an
retransmission of a large number of data frames. In such an event, a good data acknowledgement message may result in the retransmission of a large
delivery ratio would be reported while the user number of data frames. In such an event, a good data delivery ratio
would be reported while the user
Measurement units: dimensionless. Measurement units: dimensionless.
2.2.2.7. Frame Policing Ratio (FPR) 2.2.2.7. Frame Policing Ratio (FPR)
Definition: The number of frames received by the network and treated as excess Definition: The number of frames received by the network and treated
traffic and dropped divided by the total number of received frames, in one as excess traffic and dropped divided by the total number of received
direction of a single virtual connection. Frames which are sent to the network frames, in one direction of a single virtual connection. Frames
with DE set to zero are treated as excess when more than Bc bits are submitted which are sent to the network with DE set to zero are treated as
to the network during the Committed Information Rate Measurement Interval (Tc). excess when more than Bc bits are submitted to the network during the
Excess traffic may or may not be discarded at the ingress if more than Bc + Be Committed Information Rate Measurement Interval (Tc). Excess traffic
bits are submitted to the network during Tc. Traffic discarded at the ingress may or may not be discarded at the ingress if more than Bc + Be bits
is recorded in this measurement. Frames which are sent to the network with DE are submitted to the network during Tc. Traffic discarded at the
set to one are also treated as excess traffic. 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: The formal definition of frame excess ratio is as follows:
sum {i=1 to N} fr_i sum {i=1 to N} fr_i
FPR = 1- ------------------- FPR = 1- -------------------
sum {i=1 to N} ft_i, sum {i=1 to N} ft_i,
where where
fr_i is the successfully delivered frames for a particular DLCI at second i fr_i is the successfully delivered frames for a particular DLCI at
second i
and and
ft_i is the total number of attempted frame transmissions for a particular DLCI ft_i is the total number of attempted frame transmissions for a
at second i. particular DLCI
Discussion: Frame discards can adversely effect applications running on IP over at second i.
FR. Specifically, frame discards will negatively impact TCP throughput.
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) 2.2.2.8. Frame Transfer Delay (FTD)
Definition: The time required to transport frame relay data from measurement Definition: The time required to transport frame relay data from
point 1 to measurement point 2. The frame transfer delay is the difference in measurement point 1 to measurement point 2. The frame transfer delay
seconds between the time a frame exits measurement point 1 and the time the same is the difference in seconds between the time a frame exits
frame enters measurement point 2, in one direction of a single virtual measurement point 1 and the time the same frame enters measurement
connection. The formal definition of frame transfer delay is as follows: 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, FTD = 1/N * sum {i=1 to N} t2_i - t1_i,
where where
t1_i is the time in seconds when the ith frame leaves measurement point 1 (i.e., frame exit event), 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) t2 is the time in seconds when the ith frame arrives at measurement
point 2 (i.e., frame entry event)
and and
N is the number of frames received during a measurement interval T. 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. 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 Discussion: While frame transfer delay is usually computed as an
and, thus, can effect neither IP nor TCP performance, applications such as average and, thus, can effect neither IP nor TCP performance,
voice over IP may be adversely effected by excessive FTD. applications such as voice over IP may be adversely effected by
excessive FTD.
Measurement units: seconds. Measurement units: seconds.
2.2.2.9. Frame Transfer Delay Variation (FTDV) 2.2.2.9. Frame Transfer Delay Variation (FTDV)
Definition: The variation in the time required to transport frame relay data Definition: The variation in the time required to transport frame
from measurement point 1 to measurement point 2. The frame transfer delay relay data from measurement point 1 to measurement point 2. The
variation is the difference in seconds between maximum frame transfer delay and frame transfer delay variation is the difference in seconds between
the minimum frame transfer delay, in one direction of a single virtual maximum frame transfer delay and the minimum frame transfer delay, in
connection. The formal definition of frame transfer delay is as follows: 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. FTDV = max {i=1 to N} FTD_i - min {i=1 to N} FTD_i.
where where
FTD and N are defined as above. FTD and N are defined as above.
Discussion: Large values of FTDV can adversely effect TCP round trip time Discussion: Large values of FTDV can adversely effect TCP round trip
calculation and, thus, TCP throughput. time calculation and, thus, TCP throughput.
Measurement units: seconds. Measurement units: seconds.
3. Security Considerations. 3. Security Considerations
As this document is solely for providing terminology and describes As this document is solely for providing terminology and describes
neither a protocol nor an implementation, there are no security neither a protocol nor an implementation, there are no security
considerations associated with this document. considerations associated with this document.
4. Notices 4. Notices
Internet Engineering Task Force Internet Engineering Task Force
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain intellectual property or other rights that might be claimed to
to the implementation or use of the technology described in this pertain to the implementation or use of the technology described
document or the extent to which any license under such rights might or in this document or the extent to which any license under such
might not be available; neither does it represent that it has made any rights might or might not be available; neither does it represent
effort to identify any such rights. Information on the IETFs procedures that it has made any effort to identify any such rights.
with respect to rights in standards-track and standards- related Information on the IETFs procedures with respect to rights in
documentation can be found in BCP-11. Copies of claims of rights made standards-track and standards-related documentation can be found
available for publication and any assurances of licenses to be made in BCP-11. Copies of claims of rights made available for
available, or the result of an attempt made to obtain a general license publication and any assurances of licenses to be made available,
or permission for the use of such proprietary rights by implementors or or the result of an attempt made to obtain a general license or
users of this specification can be obtained from the IETF Secretariat. 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 The IETF invites any interested party to bring to its attention
copyrights, patents or patent applications, or other proprietary rights, any copyrights, patents or patent applications, or other
which may cover technology that may be required to practice this proprietary rights, which may cover technology that may be
standard. Please address the information to the IETF Executive required to practice this standard. Please address the
Director. information to the IETF Executive Director.
Frame Relay Forum Frame Relay Forum
Copyright Frame Relay Forum 1998. All Rights Reserved. References FRF, Copyright Frame Relay Forum 1998. All Rights Reserved.
FRF.5, FRF.8 and FRF.13 and translations of them may be copied and References FRF, FRF.5, FRF.8 and FRF.13 and translations of them
furnished to others, and works that comment on or otherwise explain it may be copied and furnished to others, and works that comment on
or assist in their implementation may be prepared, copied, published and or otherwise explain it or assist in their implementation may be
distributed, in whole or in part, without restriction of any kind, prepared, copied, published and distributed, in whole or in part,
provided that the above copyright notice and this paragraph are included without restriction of any kind, provided that the above copyright
on all such copies and derivative works. However, these documents notice and this paragraph are included on all such copies and
themselves may not be modified in any way, such as by removing the derivative works. However, these documents themselves may not be
copyright notice or references to the Frame Relay Forum, except as modified in any way, such as by removing the copyright notice or
needed for the purpose of developing Frame Relay standards (in which references to the Frame Relay Forum, except as needed for the
case the procedures for copyrights defined by the Frame Relay Forum must purpose of developing Frame Relay standards (in which case the
be followed), or as required to translate it into languages other than procedures for copyrights defined by the Frame Relay Forum must be
English. followed), or as required to translate it into languages other
than English.
5. Disclaimer 5. References
Copyright (C) The Internet Society (1999). All Rights Reserved. [DN] Private communication from David Newman, Network Test, Inc.
This document and translations of it may be copied and furnished to [FRF] Frame Relay Forum Glossary, http://www.frforum.com, 1999.
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 [FRF.5] Frame Relay Forum, Frame Relay/ATM PVC Network Interworking
revoked by the Internet Society or its successors or assigns. This Implementation Agreement, December 1994.
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 [FRF.8] Frame Relay Forum, Frame Relay/ATM PVC Service Interworking
Implementation Agreement, April 1995.
[DN] Private communication from David Newman, Network Test, Inc. [FRF.13] Frame Relay Forum, Service Level Definitions Implementation
Agreement, August 1998.
[FRF] Frame Relay Forum Glossary, http://www.frforum.com, 1999. [FRMIB] Rehbehn, K and D. Fowler, "Definitions of Managed Objects
for Frame Relay Service", RFC 2954, October 2000.
[FRF.5] Frame Relay Forum, Frame Relay/ATM PVC Network Interworking 6. Editors' Addresses
Implementation Agreement, December 1994.
[FRF.8] Frame Relay Forum, Frame Relay/ATM PVC Service Interworking Jeffrey Dunn
Implementation Agreement, April 1995. Advanced Network Consultants, Inc.
4214 Crest Place
Ellicott City, MD 21043 USA
[FRF.13] Frame Relay Forum, Service Level Definitions Implementation Phone: +1 (410) 750-1700
Agreement, August 1998. EMail: Jeffrey.Dunn@worldnet.att.net
[FRMIB] Definitions of Managed Objects for Frame Relay Service, draft- Cynthia Martin
ietf-frnetmib-frs-mib-09.txt, November, 1999. Advanced Network Consultants, Inc.
4214 Crest Place
Ellicott City, MD 21043 USA
7. Editors Addresses Phone: +1 (410) 750-1700
EMail: Cynthia.E.Martin@worldnet.att.net
Jeffrey Dunn Full Copyright Statement
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 Copyright (C) The Internet Society (2001). All Rights Reserved.
Advanced Network Consultants, Inc.
4214 Crest Place, Ellicott City, MD 21043 USA This document and translations of it may be copied and furnished to
Phone: +1 (410) 750-1700, E-mail: Cynthia.E.Martin@worldnet.att.net 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.
 End of changes. 248 change blocks. 
647 lines changed or deleted 689 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/