draft-ietf-bmwg-fr-term-02.txt   draft-ietf-bmwg-fr-term-03.txt 
Network Working Group J. H. Dunn Network Working Group J. H. Dunn
INTERNET-DRAFT C. E. Martin INTERNET-DRAFT C. E. Martin
Expires: May, 2000 ANC, Inc. Expires: September, 2000 ANC, Inc.
November, 1999 March, 2000
Terminology for Frame Relay Benchmarking Terminology for Frame Relay Benchmarking
<draft-ietf-bmwg-fr-term-02.txt> <draft-ietf-bmwg-fr-term-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 2, line 21 skipping to change at page 2, line 27
two sub- sections. The formal definitions sub-section is provided as a two sub- sections. The formal definitions sub-section is provided as a
courtesy to the reader. The measurement definitions sub-section courtesy to the reader. The measurement definitions sub-section
contains performance metrics with inherent units. contains performance metrics with inherent units.
The BMWG produces two major classes of documents: Benchmarking The BMWG produces two major classes of documents: Benchmarking
Terminology documents and Benchmarking Methodology documents. The Terminology documents and Benchmarking Methodology documents. The
Terminology documents present the benchmarks and other related terms. Terminology documents present the benchmarks and other related terms.
The Methodology documents define the procedures required to collect the The Methodology documents define the procedures required to collect the
benchmarks cited in the corresponding Terminology documents. 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 2. Existing Definitions
RFC 1242 "Benchmarking Terminology for Network Interconnect Devices" RFC 1242 "Benchmarking Terminology for Network Interconnect Devices"
should be consulted before attempting to make use of this document. RFC should be consulted before attempting to make use of this document. RFC
1944 "Benchmarking Methodology for Network Interconnect Devices" 1944 "Benchmarking Methodology for Network Interconnect Devices"
contains discussions of a number of terms relevant to the benchmarking contains discussions of a number of terms relevant to the benchmarking
of switching devices and should also be consulted. RFC 2285 of switching devices and should also be consulted. RFC 2285
"Benchmarking Terminology for LAN Switching Devices" contains a number "Benchmarking Terminology for LAN Switching Devices" contains a number
of terms pertaining to traffic distributions and datagram interarrival. of terms pertaining to traffic distributions and datagram interarrival.
For the sake of clarity and continuity this RFC adopts the template for For the sake of clarity and continuity this RFC adopts the template for
skipping to change at page 3, line 49 skipping to change at page 4, line 30
frame relay data travels. Within a given DS-3, T1 or E1 physical line, a 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 channel can be one of the following, depending of how the line is
configured. Possible line configurations are: configured. Possible line configurations are:
A. Unchannelized: The entire DS-3/T1/E1 line is considered a channel, A. Unchannelized: The entire DS-3/T1/E1 line is considered a channel,
where: where:
The DS-3 line operates at speeds of 45 Mbps and is a single channel. The 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 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 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. single channel consisting of 30 DS0 time slots.
B. Channelized: The channel is any one of N time slots within a given B. Channelized: The channel is any one of N time slots within a given
line, where: line, where:
The T1 line consists of any one or more channels. Each channel is any one 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 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 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. 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 The E1 line operates at speeds in multiples of 64 Kbps to 1.984 Mbps, with
aggregate speed not exceeding 1.984 Mbps. aggregate speed not exceeding 1.984 Mbps.
C. Fractional: The T1/E1 channel is one of the following groupings of C. Fractional: The T1/E1 channel is one of the following groupings of
skipping to change at page 4, line 17 skipping to change at page 4, line 45
The T1 line consists of any one or more channels. Each channel is any one 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 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 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. 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 The E1 line operates at speeds in multiples of 64 Kbps to 1.984 Mbps, with
aggregate speed not exceeding 1.984 Mbps. aggregate speed not exceeding 1.984 Mbps.
C. Fractional: The T1/E1 channel is one of the following groupings of C. Fractional: The T1/E1 channel is one of the following groupings of
consecutively or nonconsecutively assigned time slots: consecutively or nonconsecutively assigned time slots:
N T1 time slots (NX56/64Kbps where N = 1 to 23 T1 time slots per FT1 N DS0 time slots (NX56/64Kbps where N = 1 to 24 DS0 time slots per FT1
channel). channel).
N E1 time slots (NX64Kbps, where N = 1 to 30 time slots per E1 channel). 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 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 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, 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 the user may not be able to access the entire bandwidth of the access
channel. channel.
Specification: FRF Specification: FRF
1.2.2. Access Rate (AR) 1.2.2. Access Rate (AR)
skipping to change at page 7, line 19 skipping to change at page 8, line 22
1.2.12. Discard Eligible (DE) 1.2.12. Discard Eligible (DE)
Definition: This is a bit in the frame relay header that provides a two 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 level priority indicator, used to bias discard frames in the event of
congestion toward lower priority frames. Similar to the CLP bit in ATM. congestion toward lower priority frames. Similar to the CLP bit in ATM.
Discussion: See Frame Relay Frame. Discussion: See Frame Relay Frame.
Specification: FRF Specification: FRF
1.2.13. Forward Explicit Congestion Notification (FECN) 1.2.13. Discardable frames
Definition: Frames identified as being eligible to be dropped in the event
of congestion.
Discussion: The discard eligible field in the frame relay header is the
correct -- and by far the most common -- means of indicating which frames
may be dropped in the event of congestion. However, DE is not the only
means of identifying which frames may be dropped. There are at least three
other cases that apply.
In the first case, network devices may prioritize frame relay traffic by
non-DE means. For example, many service providers prioritize traffic on a
per-PVC basis. In this instance, any traffic from a given DLCI (data link
channel identifier) may be dropped during congestion, regardless of whether
DE is set.
In the second case, some implementations use upper-layer criteria, such as
IP addresses or TCP or UDP port numbers, to prioritize traffic within a
single PVC. In this instance, the network device may evaluate discard
eligibility based on upper-layer criteria rather than the presence or
absence of a DE bit.
In the third case, the frame is discarded because of an error in the frame.
Specifically, frames that are too long or too short, frames that are not a
multiple of 8 bits in length, frames with an invalid or unrecognized DLCI,
frames with an abort sequence, frames with improper flag delimitation, and
frames that fail FCS.
Specification: FRMIB
1.2.14. Discarded frames
Definition: Those frames dropped by a network device.
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 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 congested network node in any frame that is traveling in the same direction
of the congestion. of the congestion.
Discussion: When a DTE receives frames with the FECN bit asserted, it Discussion: When a DTE receives frames with the FECN bit asserted, it
should begin congestion avoidance procedures. Since the FECN frames are should begin congestion avoidance procedures. Since the FECN frames are
traveling in the same direction as the congested traffic, the DTE will be traveling in the same direction as the congested traffic, the DTE will be
the receiver. The frame relay layer may communicate the possibility of the receiver. The frame relay layer may communicate the possibility of
congestion to higher layers, which have inherent congestion avoidance congestion to higher layers, which have inherent congestion avoidance
procedures, such as TCP. See Frame Relay Frame. procedures, such as TCP. See Frame Relay Frame.
Specification: FRF Specification: FRF
1.2.14. Frame Check Sequence (FCS) 1.2.16. Frame Check Sequence (FCS)
Definition: The standard 16-bit cyclic redundancy check used for HDLC and 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 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 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 detecting errors in frames no larger than 4096 octets. See also Cyclic
Redundancy Check (CRC). Redundancy Check (CRC).
Discussion: FCS is not a measurement, but it is possible to measure the 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 amount of time to perform a FCS on a string of bits. This measurement will
not be addressed in this document. not be addressed in this document.
Specification: FRF Specification: FRF
1.2.15. Frame Entry Event 1.2.17. Frame Entry Event
Definition: Frame enters a network section or end system. The event occurs 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. when the last bit of the closing flag of the frame crosses the boundary.
Discussion: None. Discussion: None.
Specification: FRF.13 Specification: FRF.13
1.2.16. Frame Exit Event 1.2.18. Frame Exit Event
Definition: Frame exits a network section or end system. The event occurs 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. when the first bit of the address field of the frame crosses the boundary.
Discussion: None. Discussion: None.
Specification: FRF.13 Specification: FRF.13
1.2.17. Frame Relay 1.2.19. Frame Relay
Definition: A high-performance interface for packet-switching networks; Definition: A high-performance interface for packet-switching networks;
considered more efficient that X.25. Frame relay technology can handle considered more efficient that X.25. Frame relay technology can handle
"bursty" communications that have rapidly changing bandwidth requirements. "bursty" communications that have rapidly changing bandwidth requirements.
Discussion: None. Discussion: None.
Specification: FRF Specification: FRF
1.2.18. Frame Relay Frame 1.2.20. Frame Relay Frame
Definition: A logical grouping of information sent as a link-layer unit 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, 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 a header, a user data payload and a Frame Check Sequence (FCS). Bit
stuffing differentiates user data bytes from flags. By default, the header stuffing differentiates user data bytes from flags. By default, the header
is two octets, of which 10 bits are the Data Link Connection Identifier 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 (DLCI), 1 bit in each octet is used for address extension (AE), and 1 bit
each for Forward Explicit Congestion Notification (FECN), Backward Explicit each for Forward Explicit Congestion Notification (FECN), Backward Explicit
Congestion Notification (BECN) Command/Response (C/R) and Discard Eligible 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 (DE). The EA bit is set to one in the final octet containing the DLCI. A
header may span 2, 3 or 4 octets. header may span 2, 3 or 4 octets.
Bit 7 6 5 4 3 2 1 0 Bit 7 6 5 4 3 2 1 0
|---|---|---|---|---|---|---|---| |---|---|---|---|---|---|---|---|
| FLAG | | FLAG |
skipping to change at page 9, line 19 skipping to change at page 11, line 39
|-------------------------------| |-------------------------------|
Discussion: Frame Relay headers spanning 3 or 4 octets will not be Discussion: Frame Relay headers spanning 3 or 4 octets will not be
discussed in this document. Note, the measurements described later in discussed in this document. Note, the measurements described later in
this document are based on 2 octet headers. If longer headers are used, this document are based on 2 octet headers. If longer headers are used,
the metric values must take into account the associated overhead. See the metric values must take into account the associated overhead. See
BECN, DE, DLCI and FECN. BECN, DE, DLCI and FECN.
Specification: FRF Specification: FRF
1.2.19. Excess Information Rate (EIR) 1.2.21. Excess Information Rate (EIR)
Definition: See Burst Excess. Definition: See Burst Excess.
Discussion: None. Discussion: None.
Specification: FRF Specification: FRF
1.2.20. Network Interworking (FRF.5) 1.2.22. Network Interworking (FRF.5)
Definition: FRF.5 defines a protocol mapping called Network Interworking between Definition: FRF.5 defines a protocol mapping called Network Interworking between
Frame Relay and Asynchronous Transfer Mode (ATM). Protocol mapping occurs when Frame Relay and Asynchronous Transfer Mode (ATM). Protocol mapping occurs when
the network performs conversions in such a way that within a common layer 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 service, the protocol information of one protocol is extracted and mapped on
protocol information of another protocol. This means that each communication protocol information of another protocol. This means that each communication
terminal supports different protocols. The common layer service provided in terminal supports different protocols. The common layer service provided in
this interworking scenario is defined by the functions, which are common to the this interworking scenario is defined by the functions, which are common to the
two protocols. Specifically, the ATM terminal must be configured to two protocols. Specifically, the ATM terminal must be configured to
interoperate with the Frame Relay network and vice versa. interoperate with the Frame Relay network and vice versa.
Discussion: None. Discussion: None.
Specification: FRF.5 Specification: FRF.5
1.2.21. Port speed 1.2.23. Port speed
Definition: See Access Rate Definition: See Access Rate
Discussion: None. Discussion: None.
Specification: FRF Specification: FRF
1.2.22. Service Interworking (FRF.8) 1.2.24. Service Interworking (FRF.8)
Definition: FRF.8 defines a protocol encapsulation called Service Interworking. Definition: FRF.8 defines a protocol encapsulation called Service Interworking.
Protocol encapsulation occurs when the conversions in the network or in the 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 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 the layer service provided by another protocol. This means that at the
interworking point, the two protocols are stacked. When encapsulation is interworking point, the two protocols are stacked. When encapsulation is
performed by the terminal, this scenario is also called interworking by port performed by the terminal, this scenario is also called interworking by port
access. Specifically, the ATM service user performs no Frame Relaying specific access. Specifically, the ATM service user performs no Frame Relaying specific
functions, and Frame Relaying service user performs no ATM service specific functions, and Frame Relaying service user performs no ATM service specific
functions. functions.
Discussion: None. Discussion: None.
Specification: FRF.8 Specification: FRF.8
1.2.23. Service Availability Parameters 1.2.25. Service Availability Parameters
Definition: The service availability parameters report the operational Definition: The service availability parameters report the operational
readiness of individual frame relay virtual connections. Service readiness of individual frame relay virtual connections. Service
availability is affected by service outages. availability is affected by service outages.
Discussion: Service availability parameters provide metrics for Discussion: Service availability parameters provide metrics for
assessment of frame relay network health and are used to monitor assessment of frame relay network health and are used to monitor
compliance with service level agreements. See Services Outages. compliance with service level agreements. See Services Outages.
Specification: FRF.13 Specification: FRF.13
1.2.24. Service Outages 1.2.26. Service Outages
Definition: Any event that interrupts the transport of frame relay traffic. Two Definition: Any event that interrupts the transport of frame relay traffic. Two
types of outages are differentiated: types of outages are differentiated:
1) Fault outages: Outages resulting from faults in the network and thus tracked 1) Fault outages: Outages resulting from faults in the network and thus tracked
by the service availability parameters, and by the service availability parameters, and
2) Excluded outages: Outages resulting from faults beyond the control of 2) Excluded outages: Outages resulting from faults beyond the control of
the network as well as scheduled maintenance. the network as well as scheduled maintenance.
skipping to change at page 12, line 12 skipping to change at page 15, line 7
Definition: An NE transmits an OOF downstream when it receives framing Definition: An NE transmits an OOF downstream when it receives framing
errors in a specified number of consecutive frame bit positions. errors in a specified number of consecutive frame bit positions.
Discussion: An OOF will cause loss of information in the PDH frame which Discussion: An OOF will cause loss of information in the PDH frame which
contains a frame relay frame which may contain IP datagrams. contains a frame relay frame which may contain IP datagrams.
Measurement units: Seconds. Measurement units: Seconds.
2.2.1.5. Remote Alarm Indication (RAI) 2.2.1.5. Remote Alarm Indication (RAI)
Definition: Previously called Yellow. Transmitted upstream by an NE to Definition: Previously called Yellow Alarm. Transmitted upstream by an NE
indicate that it detected an LOS, LOF, or AIS. to indicate that it detected an LOS, LOF, or AIS.
Discussion: An RAI will cause loss of information in the PDH frame which Discussion: An RAI will cause loss of information in the transmitted PDH
contains a frame relay frame which may contain IP datagrams. frame, which may contain a frame relay frame, which, in turn, may contain
IP datagrams.
Measurement units: Seconds. Measurement units: Seconds.
2.2.2. Frame Relay Layer 2.2.2. Frame Relay Layer
2.2.2.1. Frame Relay Virtual Connection Availability (FRVCA) 2.2.2.1. Data Delivery Ratio (DDR)
Definition: A service availability parameter, which provides a measure of Definition: The DDR service level parameter reports the networks
the per cent availability of a frame relay PVC. 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.
IntervalTime - ExcludedOutageTime - OutageTime Three data relay ratios may be reported:
FRVCA = ---------------------------------------------- * 100,
IntervalTime - ExcludedOutageTime Data Delivery Ratio (DDR):
(DataDelivered_c + DataDelivered_e DataDelivered_e+c
DDR = ------------------------------- = ---------------
(DataOffered_c + DataOffered_e) DataOffered_e+c
Data Delivery Ratio (DDR_c) for load consisting of frames within the
committed information rate:
DataDelivered_c
DDR_c = -------------
DataOffered_c
Data Delivery Ratio (DDR_e) for load in excess of the committed information
rate:
DataDelivered_e
DDR_e = -------------
DataOffered_e
where where
IntervalTime: Time in seconds of period that availability is measured DataDelivered_c: Successfully delivered data payload octets within
committed information rate
OutageTime: Aggregate time of all fault outages that occur during the DataDelivered_e: Successfully delivered data payload octets in excess of
period availability is measured in seconds CIR
ExcludedOutageTime: Aggregate time of all excluded outages that occur DataDelivereD_e+c: Successfully delivered total data payload octets,
during the period availability is measured in seconds including those within committed information rate and those in excess of
CIR
Discussion: None. DataOffered_c: Attempted data payload octet transmissions within
committed information rate
Measurement units: Dimensionless. DataOffered_e: Attempted data payload octet transmissions in excess of
CIR
2.2.2.2. Frame Relay Mean Time To Repair (FRMTTR) DataOffered_e+c: Attempted total data payload octet transmissions,
including those within committed information rate and those in excess of
CIR
Definition: A service availability parameter for virtual connections, which Each direction of a full duplex connection has a discrete set of data
provides a measure of the time period to bring a frame relay PVC from a delivery ratios.
failed to an operation state.
If OutageCount > 0, then Discussion: Data delivery ratio measurements may not be representative of
OutageTime data delivery effectiveness for a given application. For example, the
FRMTTR = -----------, discarding of a small frame containing an acknowledgement message may
OutageCount 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.
where Measurement units: dimensionless.
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 2.2.2.2. Frame Delivery Ratio (FDR)
availability is measured
Else if OutageCount = 0, then FRMTTR = 0. Definition: The FDR service level parameter reports the networks
Discussion: None. 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.
Measurement units: seconds. Frame Delivery Ratio (FDR):
2.2.2.3. Frame Relay Mean Time Between Service Outages (FRMTBSO) (FramesDelivered_c + FramesDelivered_e) FramesDelivered_e+c
FDR = ----------------------------------- = ------------------
(FramesOffered_c + FramesOffered_e) FramesOffered_e+c
Definition: A service availability parameter for virtual connection, which Frame Delivery Ratio (FDR_c) for load consisting of frames within the
provides a measure of the time period between frame relay PVC failures. committed information rate:
If OutageCount > 0, then FramesDelivered_c
FDR_c = ----------------
FramesOffered_c
IntervalTime - ExcludedOutageTime - OutageTime Frame Delivery Ratio (FDR_c) for load in excess of the committed
FRMTBSO = ---------------------------------------------- information rate:
OutageCount
FramesDelivered_e
FDR_e = ----------------
FramesOffered_e
where where
IntervalTime: Time in seconds of period that availability is measured FramesDelivered_c: Successfully delivered frames within committed
information rate
OutageTime: Aggregate time of all fault outages that occur during the FramesDelivered_e: Successfully delivered frames in excess of CIR
period availability is measured in seconds
ExcludedOutageTime: Aggregate time of all excluded outages that occur FramesDelivered_e+c: Successfully delivered total frames, including
during the period availability is measured in seconds those within committed information rate and those in excess of CIR
OutageCount: Count of all fault outages that occur during the period FramesOffered_c: Attempted frame transmissions within committed
availability is measured information rate
Else if OutageCount = 0, then FRMTBSO = 0. FramesOffered_e: Attempted frame transmissions in excess of CIR
FramesOffered_e+c: Attempted total frame transmissions, including those
within committed information rate and those in excess of CIR
Discussion: None. An independent set of frame delivery ratios exists for each direction of a
full duplex connection.
Measurement units: seconds. Discussion: Frame delivery ratio measurements may not be representative of
frame delivery effectiveness for a given application. For example, the
discarding of a small frame containing an acknowledgement message may
result in the retransmission of a large number of data frames. In such an
event, a good data delivery ratio would be reported while the user
2.2.2.4. Frame Transfer Delay (FTD) Measurement units: dimensionless.
Definition: The time required to transport frame relay data from 2.2.2.3. Frame Discard Ratio (FDR)
measurement point 1 to measurement point 2. The frame transfer delay Definition: The number of received frames that are discarded because of a
service level parameter is the difference in seconds between the time a frame error divided by the total number of received frames in one direction
frame exits measurement point 1 and the time the same frame enters of a single virtual connection. Frame errors are defined as follows:
measurement point 2. The formal definition of frame transfer delay is as
follows FTD = t2 - t1. 1) frames that are too long or too short,
2) frames that are not a multiple of 8 bits in length,
3) frames with an invalid or unrecognized DLCI,
4) frames with an abort sequence,
5) frames with improper flag delimitation,
6) frames that fail FCS.
The formal definition of frame discard ratio is as follows:
FDR = sum {i=1 to N} fr_i
-------------------
sum {i=1 to N} ft_i,
where where
t1 is the time in seconds when a frame left measurement point 1 (i.e., fr_i is the number of successfully delivered frames for a particular DLCI at
frame exit event), second i,
t2 is the time in milliseconds when a frame arrived at measurement point and
2 (i.e., frame entry event).
Discussion: None. ft_i is the total number of attempted frame transmissions within the committed
information rate for a particular DLCI at second i.
Measurement units: seconds. 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.
2.2.2.5. Frame Delivery Ratio (FDR) Measurement units: dimensionless.
Definition: The FDR service level parameter reports the networks 2.2.2.4. Frame Error Ratio (FER)
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): Definition: The number of received frames that contain an error in the frame
payload divided by the total number of received frames in one direction of a
single virtual connection.
(FramesDeliveredc + FramesDeliverede) FramesDeliveredc+e The formal definition of frame error ratio is as follows:
FDR = ----------------------------------- = ------------------
(FramesOfferedc + FramesOfferede) FramesOfferedc+e
Frame Delivery Ratio (FDRc) for load consisting of frames within the FDR = sum {i=1 to N} fe_i
committed information rate: -------------------
sum {i=1 to N} ft_i,
FramesDeliveredc where
FDRc = ---------------- fe_i is the number of frames containing a payload error for a particular DLCI at
FramesOfferedc second i,
Frame Delivery Ratio (FDRe) for load in excess of the committed information and
rate:
FramesDeliverede ft_i is the total number of attempted frame transmissions within the committed
FDRe = ---------------- information rate for a particular DLCI at second i.
FramesOfferede
Discussion: The delivery of frames containing errors will adversely effect
applications running on IP over FR. Typically, these errors are caused by
transmission errors and flagged as failed FCS frames; however, when Frame Relay
to ATM Network interworking is used, an error may be injected in the frame
payload which, in turn, is encapsulated into an AAL5 PDU (see RFC 2761 for a
discussion of AAL5 related metrics).
Measurement units: dimensionless.
2.2.2.5. Frame Excess Ratio (FXR)
Definition: The number of frames received by the network and treated as excess
traffic divided by the total number of received frames in one direction of a
single virtual connection. Frames which are sent to the network with DE set to
zero are treated as excess when more than Bc bits are submitted to the network
during the Committed Information Rate Measurement Interval (Tc). Excess traffic
may or may not be discarded at the ingress if more than Bc + Be bits are
submitted to the network during Tc. Traffic discarded at the ingress is not
recorded in this measurement. Frames which are sent to the network with DE set
to one are also treated as excess traffic.
The formal definition of frame excess ratio is as follows:
FXR = sum {i=1 to N} fc_i
1 - -------------------
sum {i=1 to N} ft_i,
where where
FramesDeliveredc: Successfully delivered frames within committed
information rate
FramesDeliverede: Successfully delivered frames in excess of CIR fc_i is the total number of frames which were submitted within the traffic
contract for a particular DLCI at second i
FramesDeliveredc+e: Successfully delivered total frames, including those and
within committed information rate and those in excess of CIR
FramesOfferedc: Attempted frame transmissions within committed ft_i is the total number of attempted frame transmissions for a particular DLCI
information rate at second i.
FramesOfferede: Attempted frame transmissions in excess of CIR Discussion: Frame discards can adversely effect applications running on IP over
FR. Specifically, frame discards will negatively impact TCP throughput.
FramesOfferedc+e: Attempted total frame transmissions, including those Measurement units: dimensionless.
within committed information rate and those in excess of CIR
An independent set of frame delivery ratios exists for each direction of a 2.2.2.6. Frame Loss Ratio (FLR)
full duplex connection.
Discussion: None. 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. Measurement units: dimensionless.
2.2.2.6. Data Delivery Ratio (DDR) 2.2.2.7. Frame Policing Ratio (FPR)
Definition: The DDR service level parameter reports the networks Definition: The number of frames received by the network and treated as excess
effectiveness in transporting offered data (payload without address field traffic and dropped divided by the total number of received frames, in one
or FCS) in one direction of a single virtual connection. The DDR is a ratio direction of a single virtual connection. Frames which are sent to the network
of successful payload octets received to attempted payload octets with DE set to zero are treated as excess when more than Bc bits are submitted
transmitted. Attempted payload octets transmitted are referred to as to the network during the Committed Information Rate Measurement Interval (Tc).
DataOffered. Successfully delivered payload octets are referred to as Excess traffic may or may not be discarded at the ingress if more than Bc + Be
DataDelivered. These loads are further differentiated as being within the bits are submitted to the network during Tc. Traffic discarded at the ingress
committed information rate or as burst excess. is recorded in this measurement. Frames which are sent to the network with DE
set to one are also treated as excess traffic.
Three data relay ratios may be reported: The formal definition of frame excess ratio is as follows:
Data Delivery Ratio (DDR): FPR = sum {i=1 to N} fr_i
1- -------------------
sum {i=1 to N} ft_i,
(DataDeliveredc + DataDeliverede) DataDeliveredc+e where
DDR = ------------------------------- = --------------- fr_i is the successfully delivered frames for a particular DLCI at second i,
(DataOfferedc + DataOfferede) DataOfferedc+e
Data Delivery Ratio (DDRc) for load consisting of frames within the and
committed information rate: ft_i is the total number of attempted frame transmissions for a particular DLCI
at second i.
DataDeliveredc Discussion: Frame discards can adversely effect applications running on IP over
DDRc = ------------- FR. Specifically, frame discards will negatively impact TCP throughput.
DataOfferedc
Data Delivery Ratio (DDRe) for load in excess of the committed information 2.2.2.8. Frame Transfer Delay (FTD)
rate:
DataDeliverede Definition: The time required to transport frame relay data from measurement
DDRe = ------------- point 1 to measurement point 2. The frame transfer delay is the difference in
DataOfferede 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 where
DataDeliveredc: Successfully delivered data payload octets within t1 is the time in seconds when a frame left measurement point 1 (i.e., frame
committed information rate exit event),
DataDeliverede: Successfully delivered data payload octets in excess of t2 is the time in seconds when a frame arrived at measurement point 2 (i.e.,
CIR frame entry event). FTD is computed for a specific DLCI and a specified
integration period of N seconds
DataDeliveredc+e: Successfully delivered total data payload octets, Discussion: While frame transfer delay is usually computed as an average
including those within committed information rate and those in excess of and, thus, can effect neither IP nor TCP performance, applications such as
CIR voice over IP may be adversely effected by excessive FTD.
DataOfferedc: Attempted data payload octet transmissions within Measurement units: seconds.
committed information rate
DataOfferede: Attempted data payload octet transmissions in excess of 2.2.2.9. Frame Transfer Delay Variation (FTDV)
CIR
DataOfferedc+e: Attempted total data payload octet transmissions, Definition: The variation in the time required to transport frame relay data
including those within committed information rate and those in excess of from measurement point 1 to measurement point 2. The frame transfer delay
CIR 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
Each direction of a full duplex connection has a discrete set of data FTDV = max {i=1 to N} FTD_i min {i=1 to N} FTD_i.
delivery ratios.
Discussion: Data delivery ratio measurements may not be representative of where
data delivery effectiveness for a given application. For example, the FTD is defined as above.
discarding of a small frame containing an acknowledgement message may Discussion: Large values of FTDV can adversely effect TCP round trip time
result in the retransmission of a large number of data frames. In such an calculation and, thus, TCP throughput.
event, a good data delivery ratio would be reported while the user
experienced poor performance.
Measurement units: dimensionless. Measurement units: seconds.
3. Security Considerations. 3. Security Considerations.
As this document is solely for providing terminology and describes As this document is solely for providing terminology and describes
neither a protocol nor an implementation, there are no security neither a protocol nor an implementation, there are no security
considerations associated with this document. considerations associated with this document.
4. Notices 4. Notices
Internet Engineering Task Force Internet Engineering Task Force
skipping to change at page 17, line 31 skipping to change at page 23, line 41
users of this specification can be obtained from the IETF Secretariat. users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights, copyrights, patents or patent applications, or other proprietary rights,
which may cover technology that may be required to practice this which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive standard. Please address the information to the IETF Executive
Director. Director.
Frame Relay Forum Frame Relay Forum
Copyright Frame Relay Forum 1998. All Rights Reserved. References Copyright Frame Relay Forum 1998. All Rights Reserved. References FRF,
FRF, FRF.5, FRF.8 and FRF.13 and translations of them may be copied and 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 furnished to others, and works that comment on or otherwise explain it
or assist in their implementation may be prepared, copied, published and or assist in their implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, these documents on all such copies and derivative works. However, these documents
themselves may not be modified in any way, such as by removing the themselves may not be modified in any way, such as by removing the
copyright notice or references to the Frame Relay Forum, except as copyright notice or references to the Frame Relay Forum, except as
needed for the purpose of developing Frame Relay standards (in which needed for the purpose of developing Frame Relay standards (in which
case the procedures for copyrights defined by the Frame Relay Forum must case the procedures for copyrights defined by the Frame Relay Forum must
be followed), or as required to translate it into languages other than be followed), or as required to translate it into languages other than
skipping to change at page 18, line 25 skipping to change at page 24, line 41
revoked by the Internet Society or its successors or assigns. This revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS IS" document and the information contained herein is provided on an "AS IS"
basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 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 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
6. References 6. References
[DN] Private communication from David Newman, Network Test, Inc.
[FRF] Frame Relay Forum Glossary, http://www.frforum.com, 1999. [FRF] Frame Relay Forum Glossary, http://www.frforum.com, 1999.
[FRF.5] Frame Relay Forum, Frame Relay/ATM PVC Network Interworking [FRF.5] Frame Relay Forum, Frame Relay/ATM PVC Network Interworking
Implementation Agreement, December 1994. Implementation Agreement, December 1994.
[FRF.8] Frame Relay Forum, Frame Relay/ATM PVC Service Interworking [FRF.8] Frame Relay Forum, Frame Relay/ATM PVC Service Interworking
Implementation Agreement, April 1995. Implementation Agreement, April 1995.
[FRF.13] Frame Relay Forum, Service Level Definitions Implementation [FRF.13] Frame Relay Forum, Service Level Definitions Implementation
Agreement, August 1998. Agreement, August 1998.
[FRMIB] Definitions of Managed Objects for Frame Relay Service, draft-
ietf-frnetmib-frs-mib-09.txt, November, 1999.
7. Editors Addresses 7. Editors Addresses
Jeffrey Dunn Jeffrey Dunn
Advanced Network Consultants, Inc. Advanced Network Consultants, Inc.
4214 Crest Place, Ellicott City, MD 21043 USA 4214 Crest Place, Ellicott City, MD 21043 USA
Phone: +1 (410) 750-1700, E-mail: Jeffrey.Dunn@worldnet.att.net Phone: +1 (410) 750-1700, E-mail: Jeffrey.Dunn@worldnet.att.net
Cynthia Martin Cynthia Martin
Advanced Network Consultants, Inc. Advanced Network Consultants, Inc.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/