idnits 2.17.1 draft-ietf-bmwg-fr-term-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 25 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 207 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 359 instances of too long lines in the document, the longest one being 11 characters in excess of 72. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 108: '... the MUST requirements for the...' RFC 2119 keyword, line 109: '...sfies all the MUST and all the ...' RFC 2119 keyword, line 111: '...atisfies all the MUST requirements but...' RFC 2119 keyword, line 112: '... SHOULD requirements for its protoc...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 12 has weird spacing: '... This docum...' == Line 13 has weird spacing: '...visions of S...' == Line 14 has weird spacing: '...cuments of th...' == Line 15 has weird spacing: '...tribute worki...' == Line 19 has weird spacing: '...eted by other...' == (202 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'DN' is defined on line 1000, but no explicit reference was found in the text == Unused Reference: 'FRF' is defined on line 1002, but no explicit reference was found in the text == Unused Reference: 'FRMIB' is defined on line 1013, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DN' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRF' == Outdated reference: A later version (-12) exists of draft-ietf-frnetmib-frs-mib-09 Summary: 8 errors (**), 0 flaws (~~), 15 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. H. Dunn 2 INTERNET-DRAFT C. E. Martin 3 Expires: September, 2000 ANC, Inc. 5 March, 2000 7 Terminology for Frame Relay Benchmarking 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society (1999). All Rights Reserved. 33 Abstract 35 This memo discusses and defines terms associated with performance 36 benchmarking tests and the results of these tests in the context of 37 frame relay switching devices. The terms defined in this memo will be 38 used in addition to terms defined in RFCs 1242, 1944 and 2285. This 39 memo is a product of the Benchmarking Methodology Working Group (BMWG) 40 of the Internet Engineering Task Force(IETF). 42 I. Background 43 1. Introduction. 45 This document provides terminology for Frame Relay switching devices. 46 It extends terminology already defined for benchmarking network 47 interconnect devices in RFCs 1242, 1944 and 2285. Although some of the 48 definitions in this memo may be applicable to a broader group of network 49 interconnect devices, the primary focus of the terminology in this memo 50 is on Frame Relay Signaling. 52 This memo contains two major sections: Background and Definitions. The 53 background section provides the reader with an overview of the 54 technology and IETF formalisms. The definitions section is split into 55 two sub- sections. The formal definitions sub-section is provided as a 56 courtesy to the reader. The measurement definitions sub-section 57 contains performance metrics with inherent units. 59 The BMWG produces two major classes of documents: Benchmarking 60 Terminology documents and Benchmarking Methodology documents. The 61 Terminology documents present the benchmarks and other related terms. 62 The Methodology documents define the procedures required to collect the 63 benchmarks cited in the corresponding Terminology documents. 65 For the purposes of computing several of the metrics, certain textual 66 conventions are required. Specifically: 68 1) The notation sum {i=1 to N} A_i denotes: the summation of N instances 69 of the observable A. For example, the set of observations {1,2,3,4,5} 70 would yield the result 15. 72 2) The notation max {I=1 to N} A_i and min {I=1 to N} A_i denotes: the 73 maximum or minimum of the observable A over N instances. For example, 74 given the set of observations {1,2,3,4,5}, max {i=1 to 5} = 5 and min 75 {I=1 to 5} = 1. 77 2. Existing Definitions 79 RFC 1242 "Benchmarking Terminology for Network Interconnect Devices" 80 should be consulted before attempting to make use of this document. RFC 81 1944 "Benchmarking Methodology for Network Interconnect Devices" 82 contains discussions of a number of terms relevant to the benchmarking 83 of switching devices and should also be consulted. RFC 2285 84 "Benchmarking Terminology for LAN Switching Devices" contains a number 85 of terms pertaining to traffic distributions and datagram interarrival. 86 For the sake of clarity and continuity this RFC adopts the template for 87 definitions set out in Section 2 of RFC 1242. 89 3. Requirements 91 In this document, the words that are used to define the significance of 92 each particular requirement are capitalized. These words are: 94 * "MUST" This word, or the words "REQUIRED" and "SHALL" mean that the 95 item is an absolute requirement of the specification. 97 * "SHOULD" This word or the adjective "RECOMMENDED" means that there may 98 exist valid reasons in particular circumstances to ignore this item, but 99 the full implications should be understood and the case carefully 100 weighed before choosing a different course. 102 * "MAY" This word or the adjective "OPTIONAL" means that this item is 103 truly optional. One vendor may choose to include the item because a 104 particular marketplace requires it or because it enhances the product, 105 for example; another vendor may omit the same item. 107 An implementation is not compliant if it fails to satisfy one or more of 108 the MUST requirements for the protocols it implements. An 109 implementation that satisfies all the MUST and all the SHOULD 110 requirements for its protocols is said to be "unconditionally 111 compliant"; one that satisfies all the MUST requirements but not all the 112 SHOULD requirements for its protocols is said to be "conditionally 113 compliant". 115 II. Definitions 117 The definitions presented in this section have been divided into two 118 groups. The first group is formal definitions, which are required in 119 the definitions of the performance metrics but are not themselves 120 strictly metrics. These definitions are subsumed from other work done 121 in other working groups both inside and outside the IETF. They are 122 provided as a courtesy to the reader. 124 1. Formal Definitions 126 1.1. Definition Format (from RFC1242) 127 Term to be defined. 129 Definition: The specific definition for the term. 131 Discussion: A brief discussion of the term, its application and any 132 restrictions on measurement procedures. 134 Specification: The working group and document in which the term is 135 specified. Listed in the references. 137 1.2. Frame Relay Related Definitions 139 1.2.1. Access Channel 141 Definition: Access channel refers to the user access channel across which 142 frame relay data travels. Within a given DS-3, T1 or E1 physical line, a 143 channel can be one of the following, depending of how the line is 144 configured. Possible line configurations are: 146 A. Unchannelized: The entire DS-3/T1/E1 line is considered a channel, 147 where: 149 The DS-3 line operates at speeds of 45 Mbps and is a single channel. The 150 T1 line operates at speeds of 1.536 Mbps and is a single channel consisting 151 of 24 T1 time slots. The E1 line operates at speeds of 1.984 Mbps and is a 152 single channel consisting of 30 DS0 time slots. 154 B. Channelized: The channel is any one of N time slots within a given 155 line, where: 157 The T1 line consists of any one or more channels. Each channel is any one 158 of 24 time slots. The T1 line operates at speeds in multiples of 56/64 Kbps 159 to 1.536 Mbps, with aggregate speed not exceeding 1.536 Mbps. The E1 line 160 consists of one or more channels. Each channel is any one of 31 time slots. 161 The E1 line operates at speeds in multiples of 64 Kbps to 1.984 Mbps, with 162 aggregate speed not exceeding 1.984 Mbps. 164 C. Fractional: The T1/E1 channel is one of the following groupings of 165 consecutively or nonconsecutively assigned time slots: 167 N DS0 time slots (NX56/64Kbps where N = 1 to 24 DS0 time slots per FT1 168 channel). 170 N E1 time slots (NX64Kbps, where N = 1 to 30 DS0 time slots per E1 171 channel). 173 Discussion: Access channels specify the physical layer interface speed of 174 a DTE or DCE. In the case of a DTE, this may not correspond to either the 175 CIR or EIR. Specifically, based on the service level agreement in place, 176 the user may not be able to access the entire bandwidth of the access 177 channel. 179 Specification: FRF 181 1.2.2. Access Rate (AR) 183 Definition: The data rate of the user access channel. The speed of the 184 access channel determines how rapidly (maximum rate) the end user can 185 inject data into a frame relay network. 187 Discussion: See Access Channel. 189 Specification: FRF 191 1.2.3. Backward Explicit Congestion Notification (BECN) 193 Definition: BECN is a bit in the frame relay header. The bit is set by a 194 congested network node in any frame that is traveling in the reverse 195 direction of the congestion. 197 Discussion: When a DTE receives frames with the BECN bit asserted, it 198 should begin congestion avoidance procedures. Since the BECN frames are 199 traveling in the opposite direction as the congested traffic, the DTE will 200 be the sender. The frame relay layer may communicate the possibility of 201 congestion to higher layers, which have inherent congestion avoidance 202 procedures, such as TCP. See Frame Relay Frame. 204 Specification: FRF 206 1.2.4. Burst Excess(Be) 208 Definition: The maximum amount of uncommitted data (in bits) in excess of 209 Committed Burst Size (Bc) that a frame relay network can attempt to deliver 210 during a Committed Rate Measurement Interval (Tc). This data (Be) generally 211 is delivered with a lower probability than Bc. The network treats Be data 212 as discard eligible. 214 Discussion: See also Committed burst Size (Bc), Committed Rate Measurement 215 Interval (Tc) and Discard Eligible (De). 217 Specification: FRF 219 1.2.5. Committed Burst Size (Bc) 221 Definition: The maximum amount of data (in bits) that the network agrees to 222 transfer, under normal conditions, during a time interval Tc. 224 Discussion: See also Excess Burst Size (Be) and Committed Rate Measurement 225 Interval (Tc). 227 Specification: FRF 229 1.2.6. Committed Information Rate (CIR) 231 Definition: CIR is the transport speed the frame relay network will 232 maintain between service locations when data is presented. 234 Discussion: CIR specifies the guaranteed data rate between two frame relay 235 terminal connected by a frame relay network. Data presented to the network 236 in excess of this data rate and below the Excess Information Rate (EIR) 237 will be marked as Discard Eligible and may be dropped. 239 Specification: FRF 241 1.2.7. Committed Rate Measurement Interval (Tc) 243 Definition: The time interval during which the user can send only Bc- 244 committed amount of data and Be excess amount of data. In general, the 245 duration of Tc is proportional to the "burstiness" of the traffic. Tc is 246 computed (from the subscription parameters of CIR and Bc) as Tc = Bc/CIR. 247 Tc is not a periodic time interval. Instead, it is used only to measure 248 incoming data, during which it acts like a sliding window. Incoming data 249 triggers the Tc interval, which continues until it completes its commuted 250 duration. 252 Discussion: See also Committed Information Rate (CIR) and committed Burst 253 Size (Bc). 255 Specification: FRF 257 1.2.8. Cyclic Redundancy Check (CRC) 259 Definition: A computational means to ensure the accuracy of frames 260 transmitted between devices in a frame relay network. The mathematical 261 function is computed, before the frame is transmitted, at the originating 262 device. Its numerical value is computed based on the content of the frame. 263 This value is compared with a recomputed value of the function at the 264 destination device. See also Frame Check Sequence (FCS). 266 Discussion: CRC is not a measurement, but it is possible to measure the 267 amount of time to perform a CRC on a string of bits. This measurement will 268 not be addressed in this document. 270 Specification: FRF 272 1.2.9. Data Communications Equipment (DCE) 274 Definition: Term defined by both frame relay and X.25 committees, that 275 applies to switching equipment and is distinguished from the devices that 276 attach to the network (DTE). 278 Discussion: Also see DTE. 280 Specification: FRF 282 1.2.10. Data Link Connection Identifier (DLCI) 284 Definition: A unique number assigned to a PVC end point in a frame relay 285 network. Identifies a particular PVC endpoint within a user's access 286 channel in a frame relay network and has local significance only to that 287 channel. 289 Discussion: None. 291 Specification: FRF 293 1.2.11. Data Terminal Equipment (DTE) 295 Definition: Any network equipment terminating a network connection and is 296 attached to the network. This is distinguished from Data Communications 297 Equipment (DCE), which provides switching and connectivity within the 298 network. 300 Discussion: See also DCE. 302 Specification: FRF 304 1.2.12. Discard Eligible (DE) 306 Definition: This is a bit in the frame relay header that provides a two 307 level priority indicator, used to bias discard frames in the event of 308 congestion toward lower priority frames. Similar to the CLP bit in ATM. 310 Discussion: See Frame Relay Frame. 312 Specification: FRF 314 1.2.13. Discardable frames 316 Definition: Frames identified as being eligible to be dropped in the event 317 of congestion. 319 Discussion: The discard eligible field in the frame relay header is the 320 correct -- and by far the most common -- means of indicating which frames 321 may be dropped in the event of congestion. However, DE is not the only 322 means of identifying which frames may be dropped. There are at least three 323 other cases that apply. 325 In the first case, network devices may prioritize frame relay traffic by 326 non-DE means. For example, many service providers prioritize traffic on a 327 per-PVC basis. In this instance, any traffic from a given DLCI (data link 328 channel identifier) may be dropped during congestion, regardless of whether 329 DE is set. 331 In the second case, some implementations use upper-layer criteria, such as 332 IP addresses or TCP or UDP port numbers, to prioritize traffic within a 333 single PVC. In this instance, the network device may evaluate discard 334 eligibility based on upper-layer criteria rather than the presence or 335 absence of a DE bit. 337 In the third case, the frame is discarded because of an error in the frame. 338 Specifically, frames that are too long or too short, frames that are not a 339 multiple of 8 bits in length, frames with an invalid or unrecognized DLCI, 340 frames with an abort sequence, frames with improper flag delimitation, and 341 frames that fail FCS. 343 Specification: FRMIB 345 1.2.14. Discarded frames 347 Definition: Those frames dropped by a network device. 349 Discussion: Discardable and discarded frames are not synonymous. Some 350 implementations may ignore DE bits or other criteria, even though they 351 supposedly use such criteria to determine which frames to drop in the event 352 of congestion. 354 In other cases, a frame with its DE bit set may not be dropped. One example 355 of this is in cases where congestion clears before the frame can be 356 evaluated. 358 Specification: DN 360 1.2.15. Forward Explicit Congestion Notification (FECN) 362 Definition: FECN is a bit in the frame relay header. The bit is set by a 363 congested network node in any frame that is traveling in the same direction 364 of the congestion. 366 Discussion: When a DTE receives frames with the FECN bit asserted, it 367 should begin congestion avoidance procedures. Since the FECN frames are 368 traveling in the same direction as the congested traffic, the DTE will be 369 the receiver. The frame relay layer may communicate the possibility of 370 congestion to higher layers, which have inherent congestion avoidance 371 procedures, such as TCP. See Frame Relay Frame. 373 Specification: FRF 375 1.2.16. Frame Check Sequence (FCS) 377 Definition: The standard 16-bit cyclic redundancy check used for HDLC and 378 frame relay frames. The FCS detects bit errors occurring in the bits of the 379 frame between the opening flag and the FCS, and is only effective in 380 detecting errors in frames no larger than 4096 octets. See also Cyclic 381 Redundancy Check (CRC). 383 Discussion: FCS is not a measurement, but it is possible to measure the 384 amount of time to perform a FCS on a string of bits. This measurement will 385 not be addressed in this document. 387 Specification: FRF 389 1.2.17. Frame Entry Event 391 Definition: Frame enters a network section or end system. The event occurs 392 when the last bit of the closing flag of the frame crosses the boundary. 394 Discussion: None. 396 Specification: FRF.13 398 1.2.18. Frame Exit Event 400 Definition: Frame exits a network section or end system. The event occurs 401 when the first bit of the address field of the frame crosses the boundary. 403 Discussion: None. 405 Specification: FRF.13 407 1.2.19. Frame Relay 409 Definition: A high-performance interface for packet-switching networks; 410 considered more efficient that X.25. Frame relay technology can handle 411 "bursty" communications that have rapidly changing bandwidth requirements. 413 Discussion: None. 415 Specification: FRF 417 1.2.20. Frame Relay Frame 419 Definition: A logical grouping of information sent as a link-layer unit 420 over a transmission medium. Frame relay frames consist of a pair of flags, 421 a header, a user data payload and a Frame Check Sequence (FCS). Bit 422 stuffing differentiates user data bytes from flags. By default, the header 423 is two octets, of which 10 bits are the Data Link Connection Identifier 424 (DLCI), 1 bit in each octet is used for address extension (AE), and 1 bit 425 each for Forward Explicit Congestion Notification (FECN), Backward Explicit 426 Congestion Notification (BECN) Command/Response (C/R) and Discard Eligible 427 (DE). The EA bit is set to one in the final octet containing the DLCI. A 428 header may span 2, 3 or 4 octets. 430 Bit 7 6 5 4 3 2 1 0 431 |---|---|---|---|---|---|---|---| 432 | FLAG | 433 |-------------------------------| 434 | Upper 6 bits of DLCI |C/R|AE | 435 |-------------------------------| 436 | DLCI |FE |BE |DE |AE | 437 | |CN |CN | | | 438 |-------------------------------| 439 | User Data up to | 440 | 1600 Octets | 441 |-------------------------------| 442 | First Octet of FCS | 443 |-------------------------------| 444 | Second Octet of FCS | 445 |-------------------------------| 446 | FLAG | 447 |-------------------------------| 449 Discussion: Frame Relay headers spanning 3 or 4 octets will not be 450 discussed in this document. Note, the measurements described later in 451 this document are based on 2 octet headers. If longer headers are used, 452 the metric values must take into account the associated overhead. See 453 BECN, DE, DLCI and FECN. 455 Specification: FRF 457 1.2.21. Excess Information Rate (EIR) 459 Definition: See Burst Excess. 461 Discussion: None. 463 Specification: FRF 464 1.2.22. Network Interworking (FRF.5) 466 Definition: FRF.5 defines a protocol mapping called Network Interworking between 467 Frame Relay and Asynchronous Transfer Mode (ATM). Protocol mapping occurs when 468 the network performs conversions in such a way that within a common layer 469 service, the protocol information of one protocol is extracted and mapped on 470 protocol information of another protocol. This means that each communication 471 terminal supports different protocols. The common layer service provided in 472 this interworking scenario is defined by the functions, which are common to the 473 two protocols. Specifically, the ATM terminal must be configured to 474 interoperate with the Frame Relay network and vice versa. 476 Discussion: None. 478 Specification: FRF.5 480 1.2.23. Port speed 482 Definition: See Access Rate 484 Discussion: None. 486 Specification: FRF 488 1.2.24. Service Interworking (FRF.8) 490 Definition: FRF.8 defines a protocol encapsulation called Service Interworking. 491 Protocol encapsulation occurs when the conversions in the network or in the 492 terminals are such that the protocols used to provide one service make use of 493 the layer service provided by another protocol. This means that at the 494 interworking point, the two protocols are stacked. When encapsulation is 495 performed by the terminal, this scenario is also called interworking by port 496 access. Specifically, the ATM service user performs no Frame Relaying specific 497 functions, and Frame Relaying service user performs no ATM service specific 498 functions. 500 Discussion: None. 502 Specification: FRF.8 504 1.2.25. Service Availability Parameters 505 Definition: The service availability parameters report the operational 506 readiness of individual frame relay virtual connections. Service 507 availability is affected by service outages. 509 Discussion: Service availability parameters provide metrics for 510 assessment of frame relay network health and are used to monitor 511 compliance with service level agreements. See Services Outages. 513 Specification: FRF.13 515 1.2.26. Service Outages 517 Definition: Any event that interrupts the transport of frame relay traffic. Two 518 types of outages are differentiated: 520 1) Fault outages: Outages resulting from faults in the network and thus tracked 521 by the service availability parameters, and 523 2) Excluded outages: Outages resulting from faults beyond the control of 524 the network as well as scheduled maintenance. 526 Discussion: Service availability can be defined on a per-VC basis and/or on a 527 per-port basis. Frame relay port-based service availability parameters are not 528 addressed in this document. See Service Availability Parameters. 530 Specification: FRF.13 532 2. Performance Metrics 534 2.1. Definition Format (from RFC1242) 536 Metric to be defined. 538 Definition: The specific definition for the metric. 540 Discussion: A brief discussion of the metric, its application and any 541 restrictions on measurement procedures. 543 Measurement units: Intrinsic units used to quantify this metric. This 544 includes subsidiary units, e.g. microseconds are acceptable if the 545 intrinsic unit is seconds. 547 2.2. Definitions 549 2.2.1. Physical Layer- Plesiochronous Data Hierarchy (PDH) 551 2.2.1.1. Alarm Indication Signal (AIS) 553 Definition: An all 1s frame transmitted after the DTE or DCE detects a 554 defect for 2.5 s +/- 0.5 s. 556 Discussion: An AIS will cause loss of information in the PDH frame which 557 contains a frame relay frame which may contain IP datagrams. 559 Measurement units: Seconds. 561 2.2.1.2. Loss of Frame (LOF) 563 Definition: An NE transmits an LOF when an OOF condition persists. 565 Discussion: A LOF will cause loss of information in the PDH frame which 566 contains a frame relay frame which may contain IP datagrams. 568 Measurement units: Seconds. 570 2.2.1.3. Loss of Signal (LOS) 572 Definition: Indicates that there are no transitions occurring in the 573 received signal. 575 Discussion: A LOS will cause loss of information in the PDH frame which 576 contains a frame relay frame which may contain IP datagrams. 578 Measurement units: Seconds. 580 2.2.1.4. Out of Frame (OOF) 582 Definition: An NE transmits an OOF downstream when it receives framing 583 errors in a specified number of consecutive frame bit positions. 585 Discussion: An OOF will cause loss of information in the PDH frame which 586 contains a frame relay frame which may contain IP datagrams. 588 Measurement units: Seconds. 590 2.2.1.5. Remote Alarm Indication (RAI) 592 Definition: Previously called Yellow Alarm. Transmitted upstream by an NE 593 to indicate that it detected an LOS, LOF, or AIS. 595 Discussion: An RAI will cause loss of information in the transmitted PDH 596 frame, which may contain a frame relay frame, which, in turn, may contain 597 IP datagrams. 599 Measurement units: Seconds. 601 2.2.2. Frame Relay Layer 603 2.2.2.1. Data Delivery Ratio (DDR) 605 Definition: The DDR service level parameter reports the networks 606 effectiveness in transporting offered data (payload without address field 607 or FCS) in one direction of a single virtual connection. The DDR is a ratio 608 of successful payload octets received to attempted payload octets 609 transmitted. Attempted payload octets transmitted are referred to as 610 DataOffered. Successfully delivered payload octets are referred to as 611 DataDelivered. These loads are further differentiated as being within the 612 committed information rate or as burst excess. 614 Three data relay ratios may be reported: 616 Data Delivery Ratio (DDR): 618 (DataDelivered_c + DataDelivered_e DataDelivered_e+c 619 DDR = ------------------------------- = --------------- 620 (DataOffered_c + DataOffered_e) DataOffered_e+c 622 Data Delivery Ratio (DDR_c) for load consisting of frames within the 623 committed information rate: 625 DataDelivered_c 626 DDR_c = ------------- 627 DataOffered_c 629 Data Delivery Ratio (DDR_e) for load in excess of the committed information 630 rate: 632 DataDelivered_e 633 DDR_e = ------------- 634 DataOffered_e 636 where 637 DataDelivered_c: Successfully delivered data payload octets within 638 committed information rate 640 DataDelivered_e: Successfully delivered data payload octets in excess of 641 CIR 643 DataDelivereD_e+c: Successfully delivered total data payload octets, 644 including those within committed information rate and those in excess of 645 CIR 647 DataOffered_c: Attempted data payload octet transmissions within 648 committed information rate 650 DataOffered_e: Attempted data payload octet transmissions in excess of 651 CIR 653 DataOffered_e+c: Attempted total data payload octet transmissions, 654 including those within committed information rate and those in excess of 655 CIR 657 Each direction of a full duplex connection has a discrete set of data 658 delivery ratios. 660 Discussion: Data delivery ratio measurements may not be representative of 661 data delivery effectiveness for a given application. For example, the 662 discarding of a small frame containing an acknowledgement message may 663 result in the retransmission of a large number of data frames. In such an 664 event, a good data delivery ratio would be reported while the user 665 experienced poor performance. 667 Measurement units: dimensionless. 669 2.2.2.2. Frame Delivery Ratio (FDR) 671 Definition: The FDR service level parameter reports the networks 672 effectiveness in transporting an offered frame relay load in one direction 673 of a single virtual connection. The FDR is a ratio of successful frame 674 receptions to attempted frame transmissions. Attempted frame transmissions 675 are referred to as Frames Offered. Successfully delivered frames are 676 referred to as Frames Delivered. These loads may be further differentiated 677 as being within the committed information rate or as burst excess. 679 Frame Delivery Ratio (FDR): 681 (FramesDelivered_c + FramesDelivered_e) FramesDelivered_e+c 682 FDR = ----------------------------------- = ------------------ 683 (FramesOffered_c + FramesOffered_e) FramesOffered_e+c 685 Frame Delivery Ratio (FDR_c) for load consisting of frames within the 686 committed information rate: 688 FramesDelivered_c 689 FDR_c = ---------------- 690 FramesOffered_c 692 Frame Delivery Ratio (FDR_c) for load in excess of the committed 693 information rate: 695 FramesDelivered_e 696 FDR_e = ---------------- 697 FramesOffered_e 699 where 700 FramesDelivered_c: Successfully delivered frames within committed 701 information rate 703 FramesDelivered_e: Successfully delivered frames in excess of CIR 705 FramesDelivered_e+c: Successfully delivered total frames, including 706 those within committed information rate and those in excess of CIR 708 FramesOffered_c: Attempted frame transmissions within committed 709 information rate 711 FramesOffered_e: Attempted frame transmissions in excess of CIR 712 FramesOffered_e+c: Attempted total frame transmissions, including those 713 within committed information rate and those in excess of CIR 715 An independent set of frame delivery ratios exists for each direction of a 716 full duplex connection. 718 Discussion: Frame delivery ratio measurements may not be representative of 719 frame delivery effectiveness for a given application. For example, the 720 discarding of a small frame containing an acknowledgement message may 721 result in the retransmission of a large number of data frames. In such an 722 event, a good data delivery ratio would be reported while the user 724 Measurement units: dimensionless. 726 2.2.2.3. Frame Discard Ratio (FDR) 728 Definition: The number of received frames that are discarded because of a 729 frame error divided by the total number of received frames in one direction 730 of a single virtual connection. Frame errors are defined as follows: 732 1) frames that are too long or too short, 733 2) frames that are not a multiple of 8 bits in length, 734 3) frames with an invalid or unrecognized DLCI, 735 4) frames with an abort sequence, 736 5) frames with improper flag delimitation, 737 6) frames that fail FCS. 739 The formal definition of frame discard ratio is as follows: 741 FDR = sum {i=1 to N} fr_i 742 ------------------- 743 sum {i=1 to N} ft_i, 745 where 746 fr_i is the number of successfully delivered frames for a particular DLCI at 747 second i, 749 and 751 ft_i is the total number of attempted frame transmissions within the committed 752 information rate for a particular DLCI at second i. 754 Discussion: Frame discards can adversely effect applications running on IP over 755 FR. In general, frame discards will negatively impact TCP throughput; however, 756 in the case of frame discard due to frame error, frame discard will improve 757 performance by dropping errored frames. As a result, these frames will not 758 adversely effect the forwarding of retransmitted frames. 760 Measurement units: dimensionless. 762 2.2.2.4. Frame Error Ratio (FER) 764 Definition: The number of received frames that contain an error in the frame 765 payload divided by the total number of received frames in one direction of a 766 single virtual connection. 768 The formal definition of frame error ratio is as follows: 770 FDR = sum {i=1 to N} fe_i 771 ------------------- 772 sum {i=1 to N} ft_i, 774 where 775 fe_i is the number of frames containing a payload error for a particular DLCI at 776 second i, 778 and 780 ft_i is the total number of attempted frame transmissions within the committed 781 information rate for a particular DLCI at second i. 783 Discussion: The delivery of frames containing errors will adversely effect 784 applications running on IP over FR. Typically, these errors are caused by 785 transmission errors and flagged as failed FCS frames; however, when Frame Relay 786 to ATM Network interworking is used, an error may be injected in the frame 787 payload which, in turn, is encapsulated into an AAL5 PDU (see RFC 2761 for a 788 discussion of AAL5 related metrics). 790 Measurement units: dimensionless. 792 2.2.2.5. Frame Excess Ratio (FXR) 794 Definition: The number of frames received by the network and treated as excess 795 traffic divided by the total number of received frames in one direction of a 796 single virtual connection. Frames which are sent to the network with DE set to 797 zero are treated as excess when more than Bc bits are submitted to the network 798 during the Committed Information Rate Measurement Interval (Tc). Excess traffic 799 may or may not be discarded at the ingress if more than Bc + Be bits are 800 submitted to the network during Tc. Traffic discarded at the ingress is not 801 recorded in this measurement. Frames which are sent to the network with DE set 802 to one are also treated as excess traffic. 804 The formal definition of frame excess ratio is as follows: 806 FXR = sum {i=1 to N} fc_i 807 1 - ------------------- 808 sum {i=1 to N} ft_i, 810 where 812 fc_i is the total number of frames which were submitted within the traffic 813 contract for a particular DLCI at second i 815 and 817 ft_i is the total number of attempted frame transmissions for a particular DLCI 818 at second i. 820 Discussion: Frame discards can adversely effect applications running on IP over 821 FR. Specifically, frame discards will negatively impact TCP throughput. 823 Measurement units: dimensionless. 825 2.2.2.6. Frame Loss Ratio (FLR) 827 Definition: The FLR is a ratio of successful frame receptions to attempted frame 828 transmissions at the committed information rate, in one direction of a single 829 virtual connection. Attempted frame transmissions are referred to as Frames 830 Offered. Successfully delivered frames are referred to as Frames Delivered. 832 The formal definition of frame loss ratio is as follows: 834 FramesDelivered_c 835 FLR = 1- ----------------- 836 FramesOffered_c 838 where 839 FramesDelivered_c is the successfully delivered frames within committed 840 information rate for a given DLCI, 842 and 844 FramesOffered_c is the attempted frame transmissions within committed 845 information rate for a given DLCI 847 An independent set of frame delivery ratios exists for each direction of a full 848 duplex connection. 850 Discussion: Frame delivery loss measurements may not be representative of frame 851 delivery effectiveness for a given application. For example, the loss of a 852 small frame containing an acknowledgement message may result in the 853 retransmission of a large number of data frames. In such an event, a good data 854 delivery ratio would be reported while the user 856 Measurement units: dimensionless. 858 2.2.2.7. Frame Policing Ratio (FPR) 860 Definition: The number of frames received by the network and treated as excess 861 traffic and dropped divided by the total number of received frames, in one 862 direction of a single virtual connection. Frames which are sent to the network 863 with DE set to zero are treated as excess when more than Bc bits are submitted 864 to the network during the Committed Information Rate Measurement Interval (Tc). 865 Excess traffic may or may not be discarded at the ingress if more than Bc + Be 866 bits are submitted to the network during Tc. Traffic discarded at the ingress 867 is recorded in this measurement. Frames which are sent to the network with DE 868 set to one are also treated as excess traffic. 870 The formal definition of frame excess ratio is as follows: 872 FPR = sum {i=1 to N} fr_i 873 1- ------------------- 874 sum {i=1 to N} ft_i, 876 where 877 fr_i is the successfully delivered frames for a particular DLCI at second i, 879 and 880 ft_i is the total number of attempted frame transmissions for a particular DLCI 881 at second i. 883 Discussion: Frame discards can adversely effect applications running on IP over 884 FR. Specifically, frame discards will negatively impact TCP throughput. 886 2.2.2.8. Frame Transfer Delay (FTD) 888 Definition: The time required to transport frame relay data from measurement 889 point 1 to measurement point 2. The frame transfer delay is the difference in 890 seconds between the time a frame exits measurement point 1 and the time the same 891 frame enters measurement point 2, in one direction of a single virtual 892 connection. The formal definition of frame transfer delay is as follows: 894 FTD = 1/N * sum {i=1 to N} t2_i t1_i, 896 where 897 t1 is the time in seconds when a frame left measurement point 1 (i.e., frame 898 exit event), 900 t2 is the time in seconds when a frame arrived at measurement point 2 (i.e., 901 frame entry event). FTD is computed for a specific DLCI and a specified 902 integration period of N seconds 904 Discussion: While frame transfer delay is usually computed as an average 905 and, thus, can effect neither IP nor TCP performance, applications such as 906 voice over IP may be adversely effected by excessive FTD. 908 Measurement units: seconds. 910 2.2.2.9. Frame Transfer Delay Variation (FTDV) 912 Definition: The variation in the time required to transport frame relay data 913 from measurement point 1 to measurement point 2. The frame transfer delay 914 variation is the difference in seconds between maximum frame transfer delay and 915 the minimum frame transfer delay, in one direction of a single virtual 916 connection. The formal definition of frame transfer delay is as follows 918 FTDV = max {i=1 to N} FTD_i min {i=1 to N} FTD_i. 920 where 921 FTD is defined as above. 922 Discussion: Large values of FTDV can adversely effect TCP round trip time 923 calculation and, thus, TCP throughput. 925 Measurement units: seconds. 927 3. Security Considerations. 929 As this document is solely for providing terminology and describes 930 neither a protocol nor an implementation, there are no security 931 considerations associated with this document. 933 4. Notices 935 Internet Engineering Task Force 937 The IETF takes no position regarding the validity or scope of any 938 intellectual property or other rights that might be claimed to pertain 939 to the implementation or use of the technology described in this 940 document or the extent to which any license under such rights might or 941 might not be available; neither does it represent that it has made any 942 effort to identify any such rights. Information on the IETFs procedures 943 with respect to rights in standards-track and standards- related 944 documentation can be found in BCP-11. Copies of claims of rights made 945 available for publication and any assurances of licenses to be made 946 available, or the result of an attempt made to obtain a general license 947 or permission for the use of such proprietary rights by implementors or 948 users of this specification can be obtained from the IETF Secretariat. 950 The IETF invites any interested party to bring to its attention any 951 copyrights, patents or patent applications, or other proprietary rights, 952 which may cover technology that may be required to practice this 953 standard. Please address the information to the IETF Executive 954 Director. 956 Frame Relay Forum 958 Copyright Frame Relay Forum 1998. All Rights Reserved. References FRF, 959 FRF.5, FRF.8 and FRF.13 and translations of them may be copied and 960 furnished to others, and works that comment on or otherwise explain it 961 or assist in their implementation may be prepared, copied, published and 962 distributed, in whole or in part, without restriction of any kind, 963 provided that the above copyright notice and this paragraph are included 964 on all such copies and derivative works. However, these documents 965 themselves may not be modified in any way, such as by removing the 966 copyright notice or references to the Frame Relay Forum, except as 967 needed for the purpose of developing Frame Relay standards (in which 968 case the procedures for copyrights defined by the Frame Relay Forum must 969 be followed), or as required to translate it into languages other than 970 English. 972 5. Disclaimer 974 Copyright (C) The Internet Society (1999). All Rights Reserved. 976 This document and translations of it may be copied and furnished to 977 others, and derivative works that comment on or otherwise explain it or 978 assist in its implementation may be prepared, copied, published and 979 distributed, in whole or in part, without restriction of any kind, 980 provided that the above copyright notice and this paragraph are included 981 on all such copies and derivative works. However, this document itself 982 may not be modified in any way, such as by removing the copyright notice 983 or references to the Internet Society or other Internet organizations, 984 except as needed for the purpose of developing Internet standards in 985 which case the procedures for copyrights defined in the Internet 986 Standards process must be followed, or as required to translate it into 987 languages other than English. 989 The limited permissions granted above are perpetual and will not be 990 revoked by the Internet Society or its successors or assigns. This 991 document and the information contained herein is provided on an "AS IS" 992 basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 993 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 994 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 995 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 996 PARTICULAR PURPOSE. 998 6. References 1000 [DN] Private communication from David Newman, Network Test, Inc. 1002 [FRF] Frame Relay Forum Glossary, http://www.frforum.com, 1999. 1004 [FRF.5] Frame Relay Forum, Frame Relay/ATM PVC Network Interworking 1005 Implementation Agreement, December 1994. 1007 [FRF.8] Frame Relay Forum, Frame Relay/ATM PVC Service Interworking 1008 Implementation Agreement, April 1995. 1010 [FRF.13] Frame Relay Forum, Service Level Definitions Implementation 1011 Agreement, August 1998. 1013 [FRMIB] Definitions of Managed Objects for Frame Relay Service, draft- 1014 ietf-frnetmib-frs-mib-09.txt, November, 1999. 1016 7. Editors Addresses 1018 Jeffrey Dunn 1019 Advanced Network Consultants, Inc. 1020 4214 Crest Place, Ellicott City, MD 21043 USA 1021 Phone: +1 (410) 750-1700, E-mail: Jeffrey.Dunn@worldnet.att.net 1023 Cynthia Martin 1024 Advanced Network Consultants, Inc. 1025 4214 Crest Place, Ellicott City, MD 21043 USA 1026 Phone: +1 (410) 750-1700, E-mail: Cynthia.E.Martin@worldnet.att.net