rfc3133.txt

RFC 的详细文档！

   The formal definition of frame discard ratio is as follows:

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

   where

   fr_i is the number of successfully delivered frames for a particular
   DLCI at second i

   and

   ft_i is the total number of attempted frame transmissions within the
   committed plus extended information rate for a particular DLCI at
   second i.

   Discussion: Frame discards can adversely effect applications running
   on IP over FR.  In general, frame discards will negatively impact TCP
   throughput; however, in the case of frame discard due to frame error,
   frame discard will improve performance by dropping errored frames.
   As a result, these frames will not adversely effect the forwarding of
   retransmitted frames

   Measurement units: dimensionless.

2.2.2.4. Frame Error Ratio (FER)

   Definition: The number of received frames that contain an error in
   the frame payload divided by the total number of transmitted frames
   in one direction of a single virtual connection.

   The formal definition of frame error ratio is as follows:

           sum {i=1 to N} fe_i
     FER = -------------------
           sum {i=1 to N} ft_i,

   where

   fe_i is the number of frames containing a payload error for a
   particular DLCI at second i

   and

   ft_i is the total number of attempted frame transmissions within the
   committed plus the extended information rate for a particular DLCI at
   second i.  This statistic includes those frames which have an error



Dunn & Martin                Informational                     [Page 17]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


   in the Frame Check Sequence (FCS).  Frame errors in the absence of
   FCS errors can be detected by sending frames containing a known
   pattern; however, this indicates an equipment defect.

   Discussion: The delivery of frames containing errors will adversely
   effect applications running on IP over FR.  Typically, these errors
   are caused by transmission errors and flagged as failed FCS frames;
   however, when Frame Relay to ATM Network interworking is used, an
   error may be injected in the frame payload which, in turn, is
   encapsulated into an AAL5 PDU (see RFC 2761 for a discussion of AAL5
   related metrics).

   Measurement units: dimensionless.

2.2.2.5. Frame Excess Ratio (FXR)

   Definition: The number of frames received by the network and treated
   as excess traffic divided by the total number of transmitted frames
   in one direction of a single virtual connection.  Frames which are
   sent to the network with DE set to zero are treated as excess when
   more than Bc bits are submitted to the network during the Committed
   Information Rate Measurement Interval (Tc).  Excess traffic may or
   may not be discarded at the ingress if more than Bc + Be bits are
   submitted to the network during Tc.  Traffic discarded at the ingress
   is not recorded in this measurement.  Frames which are sent to the
   network with DE set to one are also treated as excess traffic.

   The formal definition of frame excess ratio is as follows:

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

   where

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

   and

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

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

   Measurement units: dimensionless.



Dunn & Martin                Informational                     [Page 18]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


2.2.2.6. Frame Loss Ratio (FLR)

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

   The formal definition of frame loss ratio is as follows:

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

   where

   FramesDelivered_c is the successfully delivered frames within
   committed information rate for a given DLCI

   and

   FramesOffered_c is the attempted frame transmissions within committed
   information rate for a given DLCI

   An independent set of frame delivery ratios exists for each direction
   of a full duplex connection.

   Discussion: Frame delivery loss measurements may not be
   representative of frame delivery effectiveness for a given
   application.  For example, the loss of a small frame containing an
   acknowledgement message may result in the retransmission of a large
   number of data frames.  In such an event, a good data delivery ratio
   would be reported while the user

   Measurement units: dimensionless.

2.2.2.7. Frame Policing Ratio (FPR)

   Definition: The number of frames received by the network and treated
   as excess traffic and dropped divided by the total number of received
   frames, in one direction of a single virtual connection.  Frames
   which are sent to the network with DE set to zero are treated as
   excess when more than Bc bits are submitted to the network during the
   Committed Information Rate Measurement Interval (Tc).  Excess traffic
   may or may not be discarded at the ingress if more than Bc + Be bits
   are submitted to the network during Tc.  Traffic discarded at the
   ingress is recorded in this measurement.  Frames which are sent to
   the network with DE set to one are also treated as excess traffic.



Dunn & Martin                Informational                     [Page 19]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


   The formal definition of frame excess ratio is as follows:

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

   where

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

   and

   ft_i is the total number of attempted frame transmissions for a
   particular DLCI

   at second i.

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

2.2.2.8. Frame Transfer Delay (FTD)

   Definition: The time required to transport frame relay data from
   measurement point 1 to measurement point 2.  The frame transfer delay
   is the difference in seconds between the time a frame exits
   measurement point 1 and the time the same frame enters measurement
   point 2, in one direction of a single virtual connection.  The formal
   definition of frame transfer delay is as follows:

      FTD = 1/N * sum {i=1 to N} t2_i - t1_i,

   where

   t1_i is the time in seconds when the ith frame leaves measurement
   point 1 (i.e., frame exit event),

   t2 is the time in seconds when the ith frame arrives at measurement
   point 2 (i.e., frame entry event)

   and

   N is the number of frames received during a measurement interval T.

   FTD is computed for a specific DLCI and a specified integration
   period of T seconds.  The computation does not include frames which
   are transmitted during the measurement period but not received.



Dunn & Martin                Informational                     [Page 20]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


   Discussion: While frame transfer delay is usually computed as an
   average and, thus, can effect neither IP nor TCP performance,
   applications such as voice over IP may be adversely effected by
   excessive FTD.

   Measurement units: seconds.

2.2.2.9. Frame Transfer Delay Variation (FTDV)

   Definition: The variation in the time required to transport frame
   relay data from measurement point 1 to measurement point 2.  The
   frame transfer delay variation is the difference in seconds between
   maximum frame transfer delay and the minimum frame transfer delay, in
   one direction of a single virtual connection.  The formal definition
   of frame transfer delay is as follows:

      FTDV = max {i=1 to N} FTD_i - min {i=1 to N} FTD_i.

   where

   FTD and N are defined as above.

   Discussion: Large values of FTDV can adversely effect TCP round trip
   time calculation and, thus, TCP throughput.

   Measurement units: seconds.

3. Security Considerations

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

4. Notices

   Internet Engineering Task Force

      The IETF takes no position regarding the validity or scope of any
      intellectual property or other rights that might be claimed to
      pertain to the implementation or use of the technology described
      in this document or the extent to which any license under such
      rights might or might not be available; neither does it represent
      that it has made any effort to identify any such rights.
      Information on the IETFs procedures with respect to rights in
      standards-track and standards-related documentation can be found
      in BCP-11.  Copies of claims of rights made available for
      publication and any assurances of licenses to be made available,
      or the result of an attempt made to obtain a general license or



Dunn & Martin                Informational                     [Page 21]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


      permission for the use of such proprietary rights by implementors
      or users of this specification can be obtained from the IETF
      Secretariat.

      The IETF invites any interested party to bring to its attention
      any copyrights, patents or patent applications, or other
      proprietary rights, which may cover technology that may be
      required to practice this standard.  Please address the
      information to the IETF Executive Director.

   Frame Relay Forum

      Copyright Frame Relay Forum 1998.  All Rights Reserved.
      References FRF, FRF.5, FRF.8 and FRF.13 and translations of them
      may be copied and furnished to others, and works that comment on
      or otherwise explain it or assist in their implementation may be
      prepared, copied, published and distributed, in whole or in part,
      without restriction of any kind, provided that the above copyright
      notice and this paragraph are included on all such copies and
      derivative works.  However, these documents themselves may not be
      modified in any way, such as by removing the copyright notice or
      references to the Frame Relay Forum, except as needed for the
      purpose of developing Frame Relay standards (in which case the
      procedures for copyrights defined by the Frame Relay Forum must be
      followed), or as required to translate it into languages other
      than English.

























Dunn & Martin                Informational                     [Page 22]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


5. References

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

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

   [FRF.5]  Frame Relay Forum, Frame Relay/ATM PVC Network Interworking
            Implementation Agreement, December 1994.

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

   [FRF.13] Frame Relay Forum, Service Level Definitions Implementation
            Agreement, August 1998.

   [FRMIB]  Rehbehn, K and D. Fowler, "Definitions of Managed Objects
            for Frame Relay Service", RFC 2954, October 2000.

6. Editors' Addresses

   Jeffrey Dunn
   Advanced Network Consultants, Inc.
   4214 Crest Place
   Ellicott City, MD 21043 USA

   Phone: [phone]
   EMail: [e-mail]


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

   Phone: [phone]
   EMail: [e-mail]















Dunn & Martin                Informational                     [Page 23]

RFC 3133        Terminology for Frame Relay Benchmarking       June 2001


Full Copyright Statement

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

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

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Dunn & Martin                Informational                     [Page 24]