idnits 2.17.1 draft-ietf-bmwg-call-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 177 has weird spacing: '...maximum and m...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9387 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Call/Cell Benchmarking Terminology August 1998 3 Network Working Group J. H. Dunn 4 INTERNET-DRAFT Hewlett-Packard 5 Expires in six months C. E. Martin 6 Hewlett-Packard 8 August 1998 10 Terminology for Call/Cell Benchmarking 11 draft-ietf-bmwg-call-02.txt 13 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as ``work 23 in progress.'' 25 To view the entire list of current Internet-Drafts, please check 26 the "1id-abstracts.txt" listing contained in the Internet-Drafts 27 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 28 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 29 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 30 (US West Coast). 32 Abstract 34 This memo discusses and defines terms associated with performance 35 benchmarking tests and the results of these tests in the context 36 of cell-based and call-based switching devices. The terms defined 37 in this memo will be used in addition to terms defined in RFCs 38 1242, 1944 and 2285. This memo is a product of the Benchmarking 39 Methodology Working Group (BMWG) of the Internet Engineering Task 40 Force (IETF). 42 I. Background 44 1. Introduction 46 This document provides terminology for benchmarking cell-based and 47 call-based switching devices. It extends terminology already 48 defined for benchmarking network interconnect devices in RFCs 49 1242, 1944 and 2285. Although some of the definitions in this 50 memo may be applicable to a broader group of network interconnect 51 devices, the primary focus of the terminology in this memo is on 52 cell-based and call-based switches. Specifically, this includes 53 Asynchronous Transfer Mode (ATM) cell relay and signaling and 54 Frame Relay (FR) signaling. 56 This memo contains two major sections: Background and Definitions. 57 Within the definitions section are a formal definitions sub- 58 section, provided as a courtesy to the reader, and a measurement 59 definitions sub-section which contains performance metrics with 60 inherent units. 62 2. Existing Definitions 64 RFC 1242 "Benchmarking Terminology for Network Interconnect 65 Devices" should be consulted before attempting to make use of this 66 document. RFC 1944 "Benchmarking Methodology for Network 67 Interconnect Devices" contains discussions of a number of terms 68 relevant to the benchmarking of switching devices and should also 69 be consulted. RFC 2285 "Benchmarking Terminology for LAN 70 Switching Devices" contains a number of terms pertaining to 71 traffic distributions and datagram interarrival. 72 For the sake of clarity and continuity this RFC adopts the 73 template for definitions set out in Section 2 of RFC 1242. 74 Definitions are indexed and grouped together in sections for ease 75 of reference. 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 77 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 78 "OPTIONAL" in this document are to be interpreted as described in 79 RFC 2119. 81 II. Definitions 83 The definitions presented in this section have been divided into 84 two groups. The first group is formal definitions, which are 85 required in the definitions of the performance metrics but are not 86 themselves strictly metrics. These definitions are subsumed from 87 other work done in other working groups both inside and outside 88 the IETF. They are provided as a courtesy to the reader. 90 1. Formal Definitions 92 1.1. Definition Format (from RFC1242) 94 Term to be defined. 96 Definition: The specific definition for the term. 98 Discussion: A brief discussion of the term, its application and 99 any restrictions on measurement procedures. 101 Specification: The working group and document in which the term 102 is specified. Listed in the references. 104 1.2 Definitions 106 1.2.1 Available Bit Rate (ABR): 108 Definition: ABR is an ATM layer service category for which the 109 limiting ATM layer transfer characteristics provided by the 110 network may change subsequent to connection establishment. A flow 111 control mechanism is specified which supports several types of 112 feedback to control the source rate in response to changing ATM 113 layer transfer characteristics. 115 Discussion: It is expected that an end-system that adapts its 116 traffic in accordance with the feedback will experience a low cell 117 loss ratio and obtain a fair share of the available bandwidth 118 according to a network specific allocation policy. Cell delay 119 variation is not controlled in this service, although admitted 120 cells are not delayed unnecessarily. 122 Specification: AF-TM4.0 124 1.2.2 Call-based 126 Definition: An association between two or more users or between a 127 user and a network entity that is established by the use of 128 network capabilities. This association may have zero or more 129 connections. 131 Discussion: none 133 Specification: AF-UNI3.1 134 1.2.3 Cell 136 Definition: A unit of transmission in ATM. A fixed size frame 137 consisting of a 5 octet header and a 48 octet payload. 139 Discussion: none 141 Specification: AF-UNI3.1 143 2. Performance Metrics 145 2.1. Definition Format (from RFC1242) 147 Metric to be defined. 149 Definition: The specific definition for the metric. 151 Discussion: A brief discussion of the metric, its application and 152 any restrictions on measurement procedures. 154 Measurement units: Intrinsic units used to quantify this metric. 155 This includes subsidiary units, e.g. microseconds are acceptable 156 if the intrinsic unit is seconds. 158 2.2 Definitions 160 2.2.1 Cell Transfer Delay (CTD) 162 Definition: The elapsed time between a cell exit event at the 163 measurement point 1 (e.g., at the source UNI) and the 164 corresponding cell entry event at a measurement point 2 (e.g., the 165 destination UNI) for a particular connection. 167 Discussion: The cell transfer delay between two measurement points 168 is the sum of the total inter-ATM node transmission delay and the 169 total ATM node processing delay. 171 Measurement units: seconds 172 2.2.2 Cell Delay Variation (CDV) 174 Definition: The variation in cell transfer delay associated with 175 a given traffic load, orientation and distribution, as well as an 176 integration period. CDV = max(CTD) - min(CTD) where max and min 177 indicate the maximum and minimum over the integration period, 178 respectively. 180 Discussion: CDV is a component of cell transfer delay, induced by 181 buffering and cell scheduling. Peak-to-peak CDV is a QoS delay 182 parameter associated with CBR and VBR services. The peak-to-peak 183 CDV is the ((1-a) quantile of the CTD) minus the fixed CTD that 184 could be experienced by any delivered cell on a connection during 185 the entire connection holding time. The parameter "a" is the 186 probability of a cell arriving late. 188 Measurement Units: seconds. 190 2.2.3 Cell Error Ratio (CER) 192 Definition: The ratio of errored cells in a transmission in 193 relation to the total cells sent in a transmission associated with 194 a given traffic load, orientation and distribution, as well as an 195 integration period. CER = Errored Cells / Total Cells 196 Transmitted. 198 Discussion: The measurement is taken over a time interval and is 199 desirable to be measured on an in-service circuit. 201 Measurement Units: dimensionless. 203 2.2.4 Cell Loss Ratio (CLR) 205 Definition: The ratio of lost cells in a transmission in relation 206 to the total cells sent in a transmission associated with a given 207 traffic load, orientation and distribution, as well as an 208 integration period. CLR = Lost Cells / Total Cells Transmitted. 210 Discussion: CLR is a negotiated QoS parameter and acceptable 211 values are network specific. The objective is to minimize CLR 212 provided the end-system adapts the traffic to the changing ATM 213 layer transfer characteristics. The CLR parameter is the value of 214 CLR that the network agrees to offer as an objective over the 215 lifetime of the connection. It is expressed as an order of 216 magnitude, having a range of 10-1 to 10-15 and unspecified. 218 Measurement Units: dimensionless. 220 2.2.5 Cell Misinsertion Rate (CMR) 222 Definition: The ratio of cells received at an endpoint that were 223 not originally transmitted by the source end in relation to the 224 total number of cells properly transmitted associated with a given 225 traffic load, orientation and distribution, as well as an 226 integration period. CMR = Mis-inserted Cells / Total Cells 227 Transmitted. 229 Discussion: none 231 Measurement Units: dimensionless. 233 3. Security Considerations 234 Security issues are not addressed in this memo. 236 4. References 238 [AF-TM4.0] ATM Forum, Traffic Management Specification Version 239 4.0, af-tm-0056.00, April 1996. 241 [AF-UNI3.1] ATM Forum, User Network Interface Specification 242 Version 3.1, September 1994. 244 5. Editor's Addresses 246 Jeffrey Dunn 247 Hewlett-Packard 248 3701 Koppers St. 249 Baltimore, MD 21227 USA 251 Phone: +1 (410) 362-7612 252 E-mail: jeff_dunn@hp.com 254 Cynthia Martin 255 Hewlett-Packard 256 3701 Koppers St. 257 Baltimore, MD 21227 259 Phone +1 (410) 362-7631 260 E-mail: cynthia_martin@hp.com