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: [email protected]


  Cynthia Martin
  Advanced Network Consultants, Inc.
  4214 Crest Place
  Ellicott City, MD 21043 USA

  Phone: +1 (410) 750-1700
  EMail: [email protected]















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]