[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 02 03 04 05 RFC 3133

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

                                                           October, 2000

                 Terminology for Frame Relay Benchmarking
                     <draft-ietf-bmwg-fr-term-05.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     October, 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     October, 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     October, 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     October, 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     October, 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  computed
duration.

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



Dunn & Martin                                                      [Page 6]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     October, 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     October, 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     October, 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     October, 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     October, 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     October, 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     October, 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     October, 2000


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.

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.



Dunn & Martin                                                     [Page 14]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     October, 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: 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 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:



Dunn & Martin                                                     [Page 15]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     October, 2000


           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

   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



Dunn & Martin                                                     [Page 16]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     October, 2000


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

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



Dunn & Martin                                                     [Page 17]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     October, 2000


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.

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.




Dunn & Martin                                                     [Page 18]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     October, 2000


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



Dunn & Martin                                                     [Page 19]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     October, 2000


             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.

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



Dunn & Martin                                                     [Page 20]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     October, 2000


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:

              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)




Dunn & Martin                                                     [Page 21]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     October, 2000


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.

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.



Dunn & Martin                                                     [Page 22]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     October, 2000


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



Dunn & Martin                                                     [Page 23]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     October, 2000


   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
   Implementation Agreement, December 1994.

   [FRF.8]  Frame  Relay  Forum,  Frame  Relay/ATM PVC Service Interworking
   Implementation Agreement, April 1995.



Dunn & Martin                                                     [Page 24]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     October, 2000


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


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/