doc: Add RFC documents

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]
+