Network Working Group J. H. Dunn INTERNET-DRAFT C. E. Martin Expires: April, 2000 ANC, Inc. October, 1999 Terminology for Frame Relay Benchmarking 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. 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 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. Dunn & Martin [Page 1] INTERNET-DRAFT Terminology for Frame Relay Benchmarking October 1999 This memo contains two major sections: Background and Definitions. Within the definitions section is a formal definitions sub-section, provided as a courtesy to the reader, and a measurement definitions sub- section, this 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. Definitions are indexed and grouped together in sections for ease of reference. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 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 Dunn & Martin [Page 2] INTERNET-DRAFT Terminology for Frame Relay Benchmarking October 1999 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 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 T1/E1 line is considered a channel, where: 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 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. Dunn & Martin [Page 3] INTERNET-DRAFT Terminology for Frame Relay Benchmarking October 1999 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. 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. See also Committed burst Size (Bc) and Committed Rate Measurement Interval (Tc). Discussion: 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. See also Excess Burst Size (Be). Discussion: 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 Dunn & Martin [Page 4] INTERNET-DRAFT Terminology for Frame Relay Benchmarking October 1999 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. See also Committed Information Rate (CIR) and committed Burst Size (Bc). Discussion: 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). Also see DTE. Discussion: Specification: FRF 1.2.10. Data Link Connection Identifier (DLCI) Dunn & Martin [Page 5] INTERNET-DRAFT Terminology for Frame Relay Benchmarking October 1999 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: 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. See also DCE. Discussion: 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: 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. Specification: FRF 1.2.14. Frame Check Sequence (FCS) Definition: The standard 16-bit cyclic redundancy check used for HDLC and Dunn & Martin [Page 6] INTERNET-DRAFT Terminology for Frame Relay Benchmarking October 1999 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. Discussion: 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: 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: 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 Dunn & Martin [Page 7] INTERNET-DRAFT Terminology for Frame Relay Benchmarking October 1999 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 DLCI may span 2, 3 or 4 octets. Bit 7 6 5 4 3 2 1 0 |---|---|---|---|---|---|---|---| | FLAG | |-------------------------------| | Upper 6 bits of DLCI |C/R|AE | |-------------------------------| | DLCI |FE |BE |DE |AE | | |CN |CN | | | |-------------------------------| | User Data up to | | 1600 Octets | |-------------------------------| | First Octet of FCS | |-------------------------------| | Second Octet of FCS | |-------------------------------| | FLAG | |-------------------------------| Discussion: 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. Dunn & Martin [Page 8] INTERNET-DRAFT Terminology for Frame Relay Benchmarking October 1999 Discussion: Specification: FRF.5 1.2.21. Out of Frame (OOF) Definition: An NE transmits an OOF downstream when it receives framing errors in a specified number of consecutive frame bit positions. Discussion: None. Specification: FRF 1.2.22. Port speed Definition: See Access Rate Discussion: None. Specification: FRF 1.2.23. 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: Specification: FRF.8 1.2.24. 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 Dunn & Martin [Page 9] INTERNET-DRAFT Terminology for Frame Relay Benchmarking October 1999 1.2.25. Service Outages Definition: Any event that interrupts the transport of frame relay traffic. Two types of outages are differentiated: 1) Fault outages: Outages resulting from faults in the network and thus tracked by the service availability parameters, and 2) Excluded outages: Outages resulting from faults beyond the control of the network as well as scheduled maintenance. Discussion: Service availability can be defined on a per-VC basis and/or on a per-port basis. Frame relay port-based service availability parameters are not addressed in this document. See Service Availability Parameters. Specification: FRF.13 2. Performance Metrics 2.1. Definition Format (from RFC1242) Metric to be defined. Definition: The specific definition for the metric. Discussion: A brief discussion of the metric, its application and any restrictions on measurement procedures. Measurement units: Intrinsic units used to quantify this metric. This includes subsidiary units, e.g. microseconds are acceptable if the intrinsic unit is seconds. 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) Dunn & Martin [Page 10] INTERNET-DRAFT Terminology for Frame Relay Benchmarking October 1999 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. 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 minutes 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 Discussion: Dunn & Martin [Page 11] INTERNET-DRAFT Terminology for Frame Relay Benchmarking October 1999 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 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: 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 minutes 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 OutageCount: Count of all fault outages that occur during the period Dunn & Martin [Page 12] INTERNET-DRAFT Terminology for Frame Relay Benchmarking October 1999 availability is measured Else if OutageCount = 0, then FRMTBSO = 0. Discussion: Measurement units: seconds. 2.2.2.4. 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 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: 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: Dunn & Martin [Page 13] INTERNET-DRAFT Terminology for Frame Relay Benchmarking October 1999 FramesDeliveredc FDRc = ---------------- FramesOfferedc Frame Delivery Ratio (FDRe) for load in excess of the committed information rate: FramesDeliverede FDRe = ---------------- FramesOfferede 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: 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: Dunn & Martin [Page 14] INTERNET-DRAFT Terminology for Frame Relay Benchmarking October 1999 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: 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 Dunn & Martin [Page 15] INTERNET-DRAFT Terminology for Frame Relay Benchmarking October 1999 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 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 Dunn & Martin [Page 16] INTERNET-DRAFT Terminology for Frame Relay Benchmarking October 1999 case the procedures for copyrights defined by the Frame Relay Forum must be followed), or as required to translate it into languages other than English. 5. Disclaimer Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 6. References [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 Dunn & Martin [Page 17] INTERNET-DRAFT Terminology for Frame Relay Benchmarking October 1999 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]