Network Working Group                                      J. H. Dunn
INTERNET-DRAFT                                             C. E. Martin
Expires: September, 2000                                   ANC, Inc.

                                                           March, 2000

                 Terminology for Frame Relay Benchmarking
                     <draft-ietf-bmwg-fr-term-03.txt>

Status of this Memo

   This  document  is an Internet-Draft and is in full conformance with all
   provisions  of  Section  10  of  RFC2026.  Internet-Drafts  are  working
   documents  of the Internet Engineering Task Force (IETF), its areas, and
   its working groups.  Note that other groups may also distribute  working
   documents as Internet-Drafts.

   Internet-Drafts  are  draft  documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by  other  documents  at  any
   time.   It is inappropriate to use Internet-Drafts as reference material
   or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This memo  discusses  and  defines  terms  associated  with  performance
   benchmarking  tests  and  the  results  of these tests in the context of
   frame relay switching devices.  The terms defined in this memo  will  be
   used  in  addition  to  terms defined in RFCs 1242, 1944 and 2285.  This
   memo is a product of the Benchmarking Methodology Working  Group  (BMWG)
   of the Internet Engineering Task Force(IETF).

I.  Background



Dunn & Martin                                                      [Page 1]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


1. Introduction.

   This  document  provides  terminology for Frame Relay switching devices.
   It  extends  terminology  already  defined  for   benchmarking   network
   interconnect  devices in RFCs 1242, 1944 and 2285.  Although some of the
   definitions in this memo may be applicable to a broader group of network
   interconnect  devices, the primary focus of the terminology in this memo
   is on Frame Relay Signaling.

   This memo contains two major sections: Background and Definitions.   The
   background   section  provides  the  reader  with  an  overview  of  the
   technology and IETF formalisms.  The definitions section is  split  into
   two  sub- sections.  The formal definitions sub-section is provided as a
   courtesy  to  the  reader.   The  measurement  definitions   sub-section
   contains performance metrics with inherent units.

   The   BMWG   produces  two  major  classes  of  documents:  Benchmarking
   Terminology  documents  and  Benchmarking  Methodology  documents.   The
   Terminology  documents  present  the benchmarks and other related terms.
   The Methodology documents define the procedures required to collect  the
   benchmarks cited in the corresponding Terminology documents.

   For  the  purposes  of computing several of the metrics, certain textual
   conventions are required.  Specifically:

   1) The notation sum {i=1 to N} A_i denotes: the summation of N instances
   of  the  observable A.  For example, the set of observations {1,2,3,4,5}
   would yield the result 15.

   2) The notation max {I=1 to N} A_i and min {I=1 to N} A_i  denotes:  the
   maximum  or  minimum of the observable A over N instances.  For example,
   given the set of observations {1,2,3,4,5}, max {i=1 to 5} =  5  and  min
   {I=1 to 5} = 1.

2. Existing Definitions

   RFC  1242  "Benchmarking  Terminology  for Network Interconnect Devices"
   should be consulted before attempting to make use of this document.  RFC
   1944   "Benchmarking   Methodology  for  Network  Interconnect  Devices"
   contains discussions of a number of terms relevant to  the  benchmarking
   of   switching   devices   and  should  also  be  consulted.   RFC  2285
   "Benchmarking Terminology for LAN Switching Devices" contains  a  number



Dunn & Martin                                                      [Page 2]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


   of  terms pertaining to traffic distributions and datagram interarrival.
   For the sake of clarity and continuity this RFC adopts the template  for
   definitions set out in Section 2 of RFC 1242.

3. Requirements

   In  this document, the words that are used to define the significance of
   each particular requirement are capitalized. These words are:

   * "MUST" This word, or the words "REQUIRED" and "SHALL"  mean  that  the
   item is an absolute requirement of the specification.

   * "SHOULD" This word or the adjective "RECOMMENDED" means that there may
   exist valid reasons in particular circumstances to ignore this item, but
   the  full  implications  should  be  understood  and  the case carefully
   weighed before choosing a different course.

   * "MAY" This word or the adjective "OPTIONAL" means that  this  item  is
   truly  optional.   One  vendor  may choose to include the item because a
   particular marketplace requires it or because it enhances  the  product,
   for example; another vendor may omit the same item.

   An implementation is not compliant if it fails to satisfy one or more of
   the  MUST  requirements   for   the   protocols   it   implements.    An
   implementation   that   satisfies  all  the  MUST  and  all  the  SHOULD
   requirements  for  its  protocols  is  said   to   be   "unconditionally
   compliant"; one that satisfies all the MUST requirements but not all the
   SHOULD requirements for its  protocols  is  said  to  be  "conditionally
   compliant".

II. Definitions

   The  definitions  presented  in  this section have been divided into two
   groups.  The first group is formal definitions, which  are  required  in
   the  definitions  of  the  performance  metrics  but  are not themselves
   strictly metrics.  These definitions are subsumed from other  work  done
   in  other  working  groups  both  inside and outside the IETF.  They are
   provided as a courtesy to the reader.

1. Formal Definitions

1.1.  Definition Format (from RFC1242)



Dunn & Martin                                                      [Page 3]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


Term to be defined.

Definition: The specific definition for the term.

Discussion: A brief  discussion  of  the  term,  its  application  and  any
restrictions on measurement procedures.

Specification:   The  working  group  and  document  in  which  the term is
specified.  Listed in the references.

1.2.  Frame Relay Related Definitions

1.2.1.  Access Channel

Definition: Access channel refers to the user access channel  across  which
frame  relay  data  travels. Within a given DS-3, T1 or E1 physical line, a
channel can be  one  of  the  following,  depending  of  how  the  line  is
configured.  Possible line configurations are:

A.  Unchannelized:  The  entire  DS-3/T1/E1  line  is considered a channel,
where:

The DS-3 line operates at speeds of 45 Mbps and is a single  channel.   The
T1 line operates at speeds of 1.536 Mbps and is a single channel consisting
of 24 T1 time slots.  The E1 line operates at speeds of 1.984 Mbps and is a
single channel consisting of 30 DS0 time slots.

B.  Channelized:   The  channel  is  any one of N time slots within a given
line, where:

The T1 line consists of any one or more channels. Each channel is  any  one
of 24 time slots. The T1 line operates at speeds in multiples of 56/64 Kbps
to 1.536 Mbps, with aggregate speed not exceeding 1.536 Mbps.  The E1  line
consists of one or more channels. Each channel is any one of 31 time slots.
The E1 line operates at speeds in multiples of 64 Kbps to 1.984 Mbps,  with
aggregate speed not exceeding 1.984 Mbps.

C.  Fractional:   The  T1/E1  channel  is one of the following groupings of
consecutively or nonconsecutively assigned time slots:

N DS0 time slots (NX56/64Kbps where N = 1 to 24  DS0  time  slots  per  FT1
channel).



Dunn & Martin                                                      [Page 4]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


N  E1  time  slots  (NX64Kbps,  where  N  =  1  to 30 DS0 time slots per E1
channel).

Discussion:  Access channels specify the physical layer interface speed  of
a  DTE or DCE.  In the case of a DTE, this may not correspond to either the
CIR or EIR.  Specifically, based on the service level agreement  in  place,
the  user  may  not  be  able  to access the entire bandwidth of the access
channel.

Specification: FRF

1.2.2.  Access Rate (AR)

Definition:  The data rate of the user access channel.  The  speed  of  the
access  channel  determines  how  rapidly  (maximum  rate) the end user can
inject data into a frame relay network.

Discussion:  See Access Channel.

Specification: FRF

1.2.3.  Backward Explicit Congestion Notification (BECN)

Definition:  BECN is a bit in the frame relay header.  The bit is set by  a
congested  network  node  in  any  frame  that  is traveling in the reverse
direction of the congestion.

Discussion: When a DTE receives frames  with  the  BECN  bit  asserted,  it
should  begin  congestion  avoidance procedures.  Since the BECN frames are
traveling in the opposite direction as the congested traffic, the DTE  will
be  the  sender.   The frame relay layer may communicate the possibility of
congestion to higher  layers,  which  have  inherent  congestion  avoidance
procedures, such as TCP.  See Frame Relay Frame.

Specification: FRF

1.2.4.  Burst Excess(Be)

Definition:  The  maximum amount of uncommitted data (in bits) in excess of
Committed Burst Size (Bc) that a frame relay network can attempt to deliver
during a Committed Rate Measurement Interval (Tc). This data (Be) generally
is delivered with a lower probability than Bc. The network treats  Be  data



Dunn & Martin                                                      [Page 5]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


as discard eligible.

Discussion:  See also Committed burst Size (Bc), Committed Rate Measurement
Interval (Tc) and Discard Eligible (De).

Specification: FRF

1.2.5.  Committed Burst Size (Bc)

Definition: The maximum amount of data (in bits) that the network agrees to
transfer, under normal conditions, during a time interval Tc.

Discussion:  See also Excess Burst Size (Be) and Committed Rate Measurement
Interval (Tc).

Specification: FRF

1.2.6.  Committed Information Rate (CIR)

Definition: CIR is  the  transport  speed  the  frame  relay  network  will
maintain between service locations when data is presented.

Discussion:  CIR specifies the guaranteed data rate between two frame relay
terminal connected by a frame relay network.  Data presented to the network
in  excess  of  this  data rate and below the Excess Information Rate (EIR)
will be marked as Discard Eligible and may be dropped.

Specification: FRF

1.2.7.  Committed Rate Measurement Interval (Tc)

Definition: The time interval during which  the  user  can  send  only  Bc-
committed  amount  of  data  and  Be excess amount of data. In general, the
duration of Tc is proportional to the "burstiness" of the  traffic.  Tc  is
computed  (from  the subscription parameters of CIR and Bc) as Tc = Bc/CIR.
Tc is not a periodic time interval. Instead, it is  used  only  to  measure
incoming  data,  during  which it acts like a sliding window. Incoming data
triggers the Tc interval, which continues until it completes  its  commuted
duration.

Discussion:  See  also Committed Information Rate (CIR) and committed Burst
Size (Bc).



Dunn & Martin                                                      [Page 6]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


Specification: FRF

1.2.8.  Cyclic Redundancy Check (CRC)

Definition:  A  computational  means  to  ensure  the  accuracy  of  frames
transmitted  between  devices  in  a  frame relay network. The mathematical
function is computed, before the frame is transmitted, at  the  originating
device.  Its numerical value is computed based on the content of the frame.
This value is compared with a recomputed  value  of  the  function  at  the
destination device. See also Frame Check Sequence (FCS).

Discussion:  CRC  is  not  a measurement, but it is possible to measure the
amount of time to perform a CRC on a string of bits. This measurement  will
not be addressed in this document.

Specification: FRF

1.2.9.  Data Communications Equipment (DCE)

Definition:   Term  defined  by  both frame relay and X.25 committees, that
applies to switching equipment and is distinguished from the  devices  that
attach to the network (DTE).

Discussion: Also see DTE.

Specification: FRF

1.2.10.  Data Link Connection Identifier (DLCI)

Definition:  A  unique  number assigned to a PVC end point in a frame relay
network. Identifies a  particular  PVC  endpoint  within  a  user's  access
channel  in  a  frame relay network and has local significance only to that
channel.

Discussion: None.

Specification: FRF

1.2.11.  Data Terminal Equipment (DTE)

Definition:  Any network equipment terminating a network connection and  is
attached  to  the  network.  This is distinguished from Data Communications



Dunn & Martin                                                      [Page 7]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


Equipment (DCE), which  provides  switching  and  connectivity  within  the
network.

Discussion: See also DCE.

Specification: FRF

1.2.12.  Discard Eligible (DE)

Definition:  This  is  a  bit in the frame relay header that provides a two
level priority indicator, used to bias  discard  frames  in  the  event  of
congestion toward lower priority frames.  Similar to the CLP bit in ATM.

Discussion: See Frame Relay Frame.

Specification: FRF

1.2.13.  Discardable frames

Definition:  Frames identified as being eligible to be dropped in the event
of congestion.

Discussion: The discard eligible field in the frame  relay  header  is  the
correct  --  and by far the most common -- means of indicating which frames
may be dropped in the event of congestion. However,  DE  is  not  the  only
means  of identifying which frames may be dropped. There are at least three
other cases that apply.

In the first case, network devices may prioritize frame  relay  traffic  by
non-DE  means.  For example, many service providers prioritize traffic on a
per-PVC basis. In this instance, any traffic from a given DLCI  (data  link
channel identifier) may be dropped during congestion, regardless of whether
DE is set.

In the second case, some implementations use upper-layer criteria, such  as
IP  addresses  or  TCP  or UDP port numbers, to prioritize traffic within a
single PVC. In this instance,  the  network  device  may  evaluate  discard
eligibility  based  on  upper-layer  criteria  rather  than the presence or
absence of a DE bit.

In the third case, the frame is discarded because of an error in the frame.
Specifically,  frames that are too long or too short, frames that are not a



Dunn & Martin                                                      [Page 8]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


multiple of 8 bits in length, frames with an invalid or unrecognized  DLCI,
frames  with an abort sequence, frames with improper flag delimitation, and
frames that fail FCS.

Specification: FRMIB

1.2.14.  Discarded frames

Definition: Those frames dropped by a network device.

Discussion: Discardable and  discarded  frames  are  not  synonymous.  Some
implementations  may  ignore  DE  bits  or other criteria, even though they
supposedly use such criteria to determine which frames to drop in the event
of congestion.

In other cases, a frame with its DE bit set may not be dropped. One example
of this is in cases  where  congestion  clears  before  the  frame  can  be
evaluated.

Specification: DN

1.2.15.  Forward Explicit Congestion Notification (FECN)

Definition:   FECN is a bit in the frame relay header.  The bit is set by a
congested network node in any frame that is traveling in the same direction
of the congestion.

Discussion:  When  a  DTE  receives  frames  with the FECN bit asserted, it
should begin congestion avoidance procedures.  Since the  FECN  frames  are
traveling  in  the same direction as the congested traffic, the DTE will be
the receiver.  The frame relay layer may  communicate  the  possibility  of
congestion  to  higher  layers,  which  have  inherent congestion avoidance
procedures, such as TCP. See Frame Relay Frame.

Specification: FRF

1.2.16.  Frame Check Sequence (FCS)

Definition:  The standard 16-bit cyclic redundancy check used for HDLC  and
frame relay frames. The FCS detects bit errors occurring in the bits of the
frame between the opening flag and  the  FCS,  and  is  only  effective  in
detecting  errors  in  frames  no  larger than 4096 octets. See also Cyclic



Dunn & Martin                                                      [Page 9]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


Redundancy Check (CRC).

Discussion: FCS is not a measurement, but it is  possible  to  measure  the
amount  of time to perform a FCS on a string of bits. This measurement will
not be addressed in this document.

Specification: FRF

1.2.17.  Frame Entry Event

Definition: Frame enters a network section or end system. The event  occurs
when the last bit of the closing flag of the frame crosses the boundary.

Discussion: None.

Specification:  FRF.13

1.2.18.  Frame Exit Event

Definition:  Frame exits a network section or end system.  The event occurs
when the first bit of the address field of the frame crosses the  boundary.

Discussion: None.

Specification:  FRF.13

1.2.19.  Frame Relay

Definition:   A  high-performance  interface for packet-switching networks;
considered more efficient that X.25.  Frame  relay  technology  can  handle
"bursty"  communications that have rapidly changing bandwidth requirements.

Discussion: None.

Specification: FRF

1.2.20.  Frame Relay Frame

Definition:  A logical grouping of information sent as  a  link-layer  unit
over  a transmission medium. Frame relay frames consist of a pair of flags,
a header, a user data payload  and  a  Frame  Check  Sequence  (FCS).   Bit
stuffing differentiates user data bytes from flags.  By default, the header



Dunn & Martin                                                     [Page 10]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


is two octets, of which 10 bits are the  Data  Link  Connection  Identifier
(DLCI),  1  bit in each octet is used for address extension (AE), and 1 bit
each for Forward Explicit Congestion Notification (FECN), Backward Explicit
Congestion  Notification (BECN) Command/Response (C/R) and Discard Eligible
(DE).  The EA bit is set to one in the final octet containing the DLCI.   A
header may span 2, 3 or 4 octets.

 Bit   7   6   5   4   3   2   1   0
     |---|---|---|---|---|---|---|---|
     |             FLAG              |
     |-------------------------------|
     | Upper 6 bits of DLCI  |C/R|AE |
     |-------------------------------|
     |     DLCI      |FE |BE |DE |AE |
     |               |CN |CN |   |   |
     |-------------------------------|
     |       User Data up to         |
     |          1600 Octets          |
     |-------------------------------|
     |      First Octet of FCS       |
     |-------------------------------|
     |      Second Octet of FCS      |
     |-------------------------------|
     |             FLAG              |
     |-------------------------------|


Discussion: Frame Relay headers spanning 3 or 4 octets will not be
discussed in this document.  Note, the measurements described later in
this document are based on 2 octet headers.  If longer headers are used,
the metric values must take into account the associated overhead.  See
BECN, DE, DLCI and FECN.

Specification: FRF

1.2.21.  Excess Information Rate (EIR)

Definition: See Burst Excess.

Discussion: None.

Specification: FRF



Dunn & Martin                                                     [Page 11]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


1.2.22.  Network Interworking (FRF.5)

Definition: FRF.5 defines a protocol mapping called Network Interworking between
Frame Relay and Asynchronous Transfer Mode (ATM). Protocol mapping occurs when
the network performs conversions in such a way that within a common layer
service, the protocol information of one protocol is extracted and mapped on
protocol information of another protocol.  This means that each communication
terminal supports different protocols.  The common layer service provided in
this interworking scenario is defined by the functions, which are common to the
two protocols.  Specifically, the ATM terminal must be configured to
interoperate with the Frame Relay network and vice versa.

Discussion: None.

Specification:  FRF.5

1.2.23.  Port speed

Definition:  See Access Rate

Discussion: None.

Specification:  FRF

1.2.24.  Service Interworking (FRF.8)

Definition: FRF.8 defines a protocol encapsulation called Service Interworking.
Protocol encapsulation occurs when the conversions in the network or in the
terminals are such that the protocols used to provide one service make use of
the layer service provided by another protocol.  This means that at the
interworking point, the two protocols are stacked.  When encapsulation is
performed by the terminal, this scenario is also called interworking by port
access.  Specifically, the ATM service user performs no Frame Relaying specific
functions, and Frame Relaying service user performs no ATM service specific
functions.

Discussion: None.

Specification:  FRF.8

1.2.25.  Service Availability Parameters




Dunn & Martin                                                     [Page 12]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


Definition:  The service availability parameters report the operational
readiness of individual frame relay virtual connections.  Service
availability is affected by service outages.

Discussion:  Service availability parameters provide metrics for
assessment of frame relay network health and are used to monitor
compliance with service level agreements.  See Services Outages.

Specification:  FRF.13

1.2.26.  Service Outages

Definition: Any event that interrupts the transport of frame relay traffic.  Two
types of outages are differentiated:

1) Fault outages: Outages resulting from faults in the network and thus tracked
by the service availability parameters, and

2) Excluded outages: Outages resulting from faults beyond the control of
the network as well as scheduled maintenance.

Discussion: Service availability can be defined on a per-VC basis and/or on a
per-port basis.  Frame relay port-based service availability parameters are not
addressed in this document.  See Service Availability Parameters.

Specification: FRF.13

2. Performance Metrics

2.1.  Definition Format (from RFC1242)

Metric to be defined.

Definition:  The specific definition for the metric.

Discussion:   A  brief  discussion  of  the metric, its application and any
restrictions on measurement procedures.

Measurement units: Intrinsic units used  to  quantify  this  metric.   This
includes   subsidiary  units,  e.g.  microseconds  are  acceptable  if  the
intrinsic unit is seconds.




Dunn & Martin                                                     [Page 13]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


2.2.  Definitions

2.2.1.  Physical Layer- Plesiochronous Data Hierarchy (PDH)

2.2.1.1.  Alarm Indication Signal (AIS)

Definition:  An all 1s 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: Seconds.

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: Seconds.

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: Seconds.

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: Seconds.



Dunn & Martin                                                     [Page 14]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


2.2.1.5.  Remote Alarm Indication (RAI)

Definition:  Previously  called Yellow Alarm. Transmitted upstream by an NE
to indicate that it detected an LOS, LOF, or AIS.

Discussion: An RAI will cause loss of information in  the  transmitted  PDH
frame,  which  may contain a frame relay frame, which, in turn, may contain
IP datagrams.

Measurement units: Seconds.

2.2.2.  Frame Relay Layer

2.2.2.1.  Data Delivery Ratio (DDR)

Definition:  The  DDR  service  level  parameter   reports   the   networks
effectiveness  in  transporting offered data (payload without address field
or FCS) in one direction of a single virtual connection. The DDR is a ratio
of   successful   payload  octets  received  to  attempted  payload  octets
transmitted.  Attempted payload  octets  transmitted  are  referred  to  as
DataOffered.   Successfully  delivered  payload  octets  are referred to as
DataDelivered.  These loads are further differentiated as being within  the
committed information rate or as burst excess.

Three data relay ratios may be reported:

Data Delivery Ratio (DDR):

         (DataDelivered_c + DataDelivered_e     DataDelivered_e+c
   DDR = ------------------------------- = ---------------
           (DataOffered_c + DataOffered_e)        DataOffered_e+c


Data  Delivery  Ratio  (DDR_c)  for  load  consisting  of frames within the
committed information rate:

         DataDelivered_c
   DDR_c = -------------
          DataOffered_c


Data Delivery Ratio (DDR_e) for load in excess of the committed information



Dunn & Martin                                                     [Page 15]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


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

   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



Dunn & Martin                                                     [Page 16]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


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):

         (FramesDelivered_c + FramesDelivered_e)     FramesDelivered_e+c
   FDR = ----------------------------------- = ------------------
           (FramesOffered_c + FramesOffered_e)        FramesOffered_e+c


Frame  Delivery  Ratio  (FDR_c)  for  load  consisting of frames within the
committed information rate:

         FramesDelivered_c
  FDR_c = ----------------
          FramesOffered_c

Frame  Delivery  Ratio  (FDR_c)  for  load  in  excess  of  the   committed
information rate:

         FramesDelivered_e
  FDR_e = ----------------
          FramesOffered_e

where
   FramesDelivered_c:   Successfully   delivered  frames  within  committed
   information rate

   FramesDelivered_e: Successfully delivered frames in excess of CIR

   FramesDelivered_e+c:  Successfully  delivered  total  frames,  including
   those within committed information rate and those in excess of CIR

   FramesOffered_c:   Attempted   frame   transmissions   within  committed
   information rate

   FramesOffered_e: Attempted frame transmissions in excess of CIR




Dunn & Martin                                                     [Page 17]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


   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 received frames in one direction
of a single virtual connection. Frame errors are defined as follows:

1) frames that are too long or too short,
2) frames that are not a multiple of 8 bits in length,
3) frames with an invalid or unrecognized DLCI,
4) frames with an abort sequence,
5) frames with improper flag delimitation,
6) frames that fail FCS.

The formal definition of frame discard ratio is as follows:

FDR = sum {i=1 to N} fr_i
      -------------------
      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
   information rate for a particular DLCI at second i.




Dunn & Martin                                                     [Page 18]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


   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 received frames in one direction of a
   single virtual connection.

   The formal definition of frame error ratio is as follows:

   FDR = sum {i=1 to N} fe_i
         -------------------
         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
   information rate for a particular DLCI at second i.

   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 received frames in one direction of a



Dunn & Martin                                                     [Page 19]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


   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:

   FXR =     sum {i=1 to N} fc_i
         1 - -------------------
             sum {i=1 to N} ft_i,

   where

   fc_i is the total number of frames which were submitted within the traffic
   contract for a particular DLCI at second i

   and

   ft_i is the total number of attempted frame transmissions for a particular DLCI
   at second i.

   Discussion:  Frame discards can adversely effect applications running on IP over
   FR.  Specifically, frame discards will negatively impact TCP throughput.

   Measurement units: dimensionless.

   2.2.2.6.  Frame Loss Ratio (FLR)

   Definition: The FLR is a ratio of successful frame receptions to attempted frame
   transmissions at the committed information rate, in one direction of a single
   virtual connection.  Attempted frame transmissions are referred to as Frames
   Offered.  Successfully delivered frames are referred to as Frames Delivered.

   The formal definition of frame loss ratio is as follows:

                 FramesDelivered_c
      FLR =  1-  -----------------
                 FramesOffered_c




Dunn & Martin                                                     [Page 20]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


   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.

The formal definition of frame excess ratio is as follows:

FPR =      sum {i=1 to N} fr_i
       1-  -------------------
           sum {i=1 to N} ft_i,

where
   fr_i is the successfully delivered frames for a particular DLCI at second i,

   and



Dunn & Martin                                                     [Page 21]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


   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 is the time in seconds when a frame left measurement point 1 (i.e., frame
   exit event),

   t2 is the time in seconds when a frame arrived at measurement point 2 (i.e.,
   frame entry event). FTD is computed for a specific DLCI and a specified
   integration period of N seconds

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




Dunn & Martin                                                     [Page 22]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


   FTD is 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 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,



Dunn & Martin                                                     [Page 23]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


   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.

5. Disclaimer

   Copyright (C) The Internet Society (1999). All Rights Reserved.

   This  document  and  translations  of  it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it  or
   assist  in  its  implementation  may  be prepared, copied, published and
   distributed, in whole or in  part,  without  restriction  of  any  kind,
   provided that the above copyright notice and this paragraph are included
   on all such copies and derivative works.  However, this document  itself
   may not be modified in any way, such as by removing the copyright notice
   or references to the Internet Society or other  Internet  organizations,
   except  as  needed  for  the purpose of developing Internet standards in
   which case  the  procedures  for  copyrights  defined  in  the  Internet
   Standards  process must be followed, or as required to translate it into
   languages other than English.

   The limited permissions granted above are  perpetual  and  will  not  be
   revoked  by  the  Internet  Society  or  its successors or assigns. This
   document and the information contained herein is provided on an "AS  IS"
   basis  and  THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
   DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT  LIMITED
   TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
   PARTICULAR PURPOSE.

6. References

   [DN] Private communication from David Newman, Network Test, Inc.

   [FRF] Frame Relay Forum Glossary, http://www.frforum.com, 1999.

   [FRF.5]  Frame  Relay  Forum,  Frame  Relay/ATM PVC Network Interworking



Dunn & Martin                                                     [Page 24]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking       March, 2000


   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] Definitions of Managed Objects for Frame Relay  Service,  draft-
   ietf-frnetmib-frs-mib-09.txt, November, 1999.

7. Editors Addresses

   Jeffrey Dunn
   Advanced Network Consultants, Inc.
   4214 Crest Place, Ellicott City, MD 21043 USA
   Phone: +1 (410) 750-1700, E-mail: Jeffrey.Dunn@worldnet.att.net

   Cynthia Martin
   Advanced Network Consultants, Inc.
   4214 Crest Place, Ellicott City, MD 21043 USA
   Phone: +1 (410) 750-1700, E-mail: Cynthia.E.Martin@worldnet.att.net























Dunn & Martin                                                     [Page 25]