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