[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: May, 2000                                         ANC, Inc.

                                                           November, 1999

                 Terminology for Frame Relay Benchmarking
                     <draft-ietf-bmwg-fr-term-02.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

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



Dunn & Martin                                                      [Page 1]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     November 1999


   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.

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.

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



Dunn & Martin                                                      [Page 2]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     November 1999


   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)

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 E1 time slots.

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



Dunn & Martin                                                      [Page 3]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     November 1999


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 T1 time slots (NX56/64Kbps where N = 1  to  23  T1  time  slots  per  FT1
channel).

N E1 time slots (NX64Kbps, where N = 1 to 30 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.




Dunn & Martin                                                      [Page 4]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     November 1999


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

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.




Dunn & Martin                                                      [Page 5]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     November 1999


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




Dunn & Martin                                                      [Page 6]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     November 1999


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.  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.14.  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.15.  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.




Dunn & Martin                                                      [Page 7]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     November 1999


Discussion: None.

Specification:  FRF.13

1.2.16.  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.17.  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.18.  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.

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



Dunn & Martin                                                      [Page 8]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     November 1999


     |      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.19.  Excess Information Rate (EIR)

Definition: See Burst Excess.

Discussion: None.

Specification: FRF

1.2.20.  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.21.  Port speed

Definition:  See Access Rate

Discussion: None.

Specification:  FRF




Dunn & Martin                                                      [Page 9]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     November 1999


1.2.22.  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.23.  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

1.2.24.  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)



Dunn & Martin                                                     [Page 10]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     November 1999


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



Dunn & Martin                                                     [Page 11]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     November 1999


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.

2.2.1.5.  Remote Alarm Indication (RAI)

Definition: Previously called Yellow. 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 PDH frame which
contains a frame relay frame which may contain IP datagrams.

Measurement units: Seconds.

2.2.2.  Frame Relay Layer

2.2.2.1.  Frame Relay Virtual Connection Availability (FRVCA)

Definition: A service availability parameter, which provides a  measure  of
the per cent availability of a frame relay PVC.

           IntervalTime - ExcludedOutageTime - OutageTime
   FRVCA = ---------------------------------------------- * 100,
                  IntervalTime - ExcludedOutageTime

where
   IntervalTime: Time in seconds of period that availability is measured

   OutageTime:  Aggregate  time  of all fault outages that occur during the
   period availability is measured in seconds

   ExcludedOutageTime: Aggregate time of all excluded  outages  that  occur
   during the period availability is measured in seconds

Discussion: None.

Measurement units:  Dimensionless.

2.2.2.2.  Frame Relay Mean Time To Repair (FRMTTR)

Definition: A service availability parameter for virtual connections, which
provides a measure of the time period to bring a frame  relay  PVC  from  a
failed to an operation state.

If OutageCount > 0, then





Dunn & Martin                                                     [Page 12]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     November 1999

               OutageTime
      FRMTTR = -----------,
               OutageCount

where
   OutageTime:  Aggregate  time  of all fault outages that occur during the
   period availability is measured in seconds

   OutageCount: Count of all fault outages that  occur  during  the  period
   availability is measured

Else if OutageCount = 0, then FRMTTR = 0.

Discussion: None.

Measurement units: seconds.

2.2.2.3. Frame Relay Mean Time Between Service Outages (FRMTBSO)

Definition:  A service availability parameter for virtual connection, which
provides a measure of the time period between frame relay PVC failures.

If OutageCount > 0, then

                IntervalTime - ExcludedOutageTime - OutageTime
      FRMTBSO = ----------------------------------------------
                             OutageCount

where
   IntervalTime: Time in seconds of period that availability is measured

   OutageTime: Aggregate time of all fault outages that  occur  during  the
   period availability is measured in seconds

   ExcludedOutageTime:  Aggregate  time  of all excluded outages that occur
   during the period availability is measured in seconds

   OutageCount: Count of all fault outages that  occur  during  the  period
   availability is measured

Else if OutageCount = 0, then FRMTBSO = 0.

Discussion: None.

Measurement units: seconds.

2.2.2.4.  Frame Transfer Delay (FTD)

Definition:   The   time  required  to  transport  frame  relay  data  from



Dunn & Martin                                                     [Page 13]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     November 1999


measurement point 1 to measurement  point  2.   The  frame  transfer  delay
service  level  parameter  is  the difference in seconds between the time a
frame exits measurement  point  1  and  the  time  the  same  frame  enters
measurement  point  2.  The formal definition of frame transfer delay is as
follows FTD = t2 - t1.

where
   t1 is the time in seconds when a frame left measurement point  1  (i.e.,
   frame exit event),

   t2 is the time in milliseconds when a frame arrived at measurement point
   2 (i.e., frame entry event).

Discussion: None.

Measurement units: seconds.

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

         (FramesDeliveredc + FramesDeliverede) FramesDeliveredc+e
   FDR = ----------------------------------- = ------------------
           (FramesOfferedc + FramesOfferede)    FramesOfferedc+e


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

         FramesDeliveredc
  FDRc = ----------------
          FramesOfferedc

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

         FramesDeliverede
  FDRe = ----------------
          FramesOfferede




Dunn & Martin                                                     [Page 14]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     November 1999


where
   FramesDeliveredc:  Successfully  delivered   frames   within   committed
   information rate

   FramesDeliverede: Successfully delivered frames in excess of CIR

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

   FramesOfferedc:   Attempted   frame   transmissions   within   committed
   information rate

   FramesOfferede: Attempted frame transmissions in excess of CIR

   FramesOfferedc+e:  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: None.

Measurement units: dimensionless.

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

         (DataDeliveredc + DataDeliverede) DataDeliveredc+e
   DDR = ------------------------------- = ---------------
           (DataOfferedc + DataOfferede)   DataOfferedc+e


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





Dunn & Martin                                                     [Page 15]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     November 1999

          DataDeliveredc
   DDRc = -------------
          DataOfferedc


Data  Delivery Ratio (DDRe) for load in excess of the committed information
rate:

          DataDeliverede
   DDRe = -------------
          DataOfferede

where
   DataDeliveredc:  Successfully  delivered  data  payload  octets   within
   committed information rate

   DataDeliverede:  Successfully delivered data payload octets in excess of
   CIR

   DataDeliveredc+e: Successfully  delivered  total  data  payload  octets,
   including those within committed information rate and those in excess of
   CIR

   DataOfferedc:  Attempted  data  payload   octet   transmissions   within
   committed information rate

   DataOfferede:  Attempted  data  payload octet transmissions in excess of
   CIR

   DataOfferedc+e:  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.

3. Security Considerations.

   As this document is  solely  for  providing  terminology  and  describes
   neither  a  protocol  nor  an  implementation,  there  are  no  security



Dunn & Martin                                                     [Page 16]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     November 1999


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



Dunn & Martin                                                     [Page 17]


INTERNET-DRAFT   Terminology for Frame Relay Benchmarking     November 1999


   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

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

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


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