idnits 2.17.1 draft-ietf-bmwg-fr-term-04.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 109: '... the MUST requirements for the...' RFC 2119 keyword, line 110: '...sfies all the MUST and all the ...' RFC 2119 keyword, line 112: '...atisfies all the MUST requirements but...' RFC 2119 keyword, line 113: '... 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 13 has weird spacing: '... This docum...' == Line 14 has weird spacing: '...visions of S...' == Line 15 has weird spacing: '...cuments of th...' == Line 16 has weird spacing: '...tribute worki...' == Line 20 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 1001, but no explicit reference was found in the text == Unused Reference: 'FRF' is defined on line 1003, but no explicit reference was found in the text == Unused Reference: 'FRMIB' is defined on line 1014, 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. -------------------------------------------------------------------------------- 2 Network Working Group J. H. Dunn 3 INTERNET-DRAFT C. E. Martin 4 Expires: February, 2001 ANC, Inc. 6 July, 2000 8 Terminology for Frame Relay Benchmarking 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, and 16 its working groups. Note that other groups may also distribute working 17 documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (1999). All Rights Reserved. 34 Abstract 36 This memo discusses and defines terms associated with performance 37 benchmarking tests and the results of these tests in the context of 38 frame relay switching devices. The terms defined in this memo will be 39 used in addition to terms defined in RFCs 1242, 1944 and 2285. This 40 memo is a product of the Benchmarking Methodology Working Group (BMWG) 41 of the Internet Engineering Task Force(IETF). 43 I. Background 44 1. Introduction. 46 This document provides terminology for Frame Relay switching devices. 47 It extends terminology already defined for benchmarking network 48 interconnect devices in RFCs 1242, 1944 and 2285. Although some of the 49 definitions in this memo may be applicable to a broader group of network 50 interconnect devices, the primary focus of the terminology in this memo 51 is on Frame Relay Signaling. 53 This memo contains two major sections: Background and Definitions. The 54 background section provides the reader with an overview of the 55 technology and IETF formalisms. The definitions section is split into 56 two sub- sections. The formal definitions sub-section is provided as a 57 courtesy to the reader. The measurement definitions sub-section 58 contains performance metrics with inherent units. 60 The BMWG produces two major classes of documents: Benchmarking 61 Terminology documents and Benchmarking Methodology documents. The 62 Terminology documents present the benchmarks and other related terms. 63 The Methodology documents define the procedures required to collect the 64 benchmarks cited in the corresponding Terminology documents. 66 For the purposes of computing several of the metrics, certain textual 67 conventions are required. Specifically: 69 1) The notation sum {i=1 to N} A_i denotes: the summation of N instances 70 of the observable A. For example, the set of observations {1,2,3,4,5} 71 would yield the result 15. 73 2) The notation max {I=1 to N} A_i and min {I=1 to N} A_i denotes: the 74 maximum or minimum of the observable A over N instances. For example, 75 given the set of observations {1,2,3,4,5}, max {i=1 to 5} = 5 and min 76 {I=1 to 5} = 1. 78 2. Existing Definitions 80 RFC 1242 "Benchmarking Terminology for Network Interconnect Devices" 81 should be consulted before attempting to make use of this document. RFC 82 1944 "Benchmarking Methodology for Network Interconnect Devices" 83 contains discussions of a number of terms relevant to the benchmarking 84 of switching devices and should also be consulted. RFC 2285 85 "Benchmarking Terminology for LAN Switching Devices" contains a number 86 of terms pertaining to traffic distributions and datagram interarrival. 87 For the sake of clarity and continuity this RFC adopts the template for 88 definitions set out in Section 2 of RFC 1242. 90 3. Requirements 92 In this document, the words that are used to define the significance of 93 each particular requirement are capitalized. These words are: 95 * "MUST" This word, or the words "REQUIRED" and "SHALL" mean that the 96 item is an absolute requirement of the specification. 98 * "SHOULD" This word or the adjective "RECOMMENDED" means that there may 99 exist valid reasons in particular circumstances to ignore this item, but 100 the full implications should be understood and the case carefully 101 weighed before choosing a different course. 103 * "MAY" This word or the adjective "OPTIONAL" means that this item is 104 truly optional. One vendor may choose to include the item because a 105 particular marketplace requires it or because it enhances the product, 106 for example; another vendor may omit the same item. 108 An implementation is not compliant if it fails to satisfy one or more of 109 the MUST requirements for the protocols it implements. An 110 implementation that satisfies all the MUST and all the SHOULD 111 requirements for its protocols is said to be "unconditionally 112 compliant"; one that satisfies all the MUST requirements but not all the 113 SHOULD requirements for its protocols is said to be "conditionally 114 compliant". 116 II. Definitions 118 The definitions presented in this section have been divided into two 119 groups. The first group is formal definitions, which are required in 120 the definitions of the performance metrics but are not themselves 121 strictly metrics. These definitions are subsumed from other work done 122 in other working groups both inside and outside the IETF. They are 123 provided as a courtesy to the reader. 125 1. Formal Definitions 127 1.1. Definition Format (from RFC1242) 128 Term to be defined. 130 Definition: The specific definition for the term. 132 Discussion: A brief discussion of the term, its application and any 133 restrictions on measurement procedures. 135 Specification: The working group and document in which the term is 136 specified. Listed in the references. 138 1.2. Frame Relay Related Definitions 140 1.2.1. Access Channel 142 Definition: Access channel refers to the user access channel across which 143 frame relay data travels. Within a given DS-3, T1 or E1 physical line, a 144 channel can be one of the following, depending of how the line is 145 configured. Possible line configurations are: 147 A. Unchannelized: The entire DS-3/T1/E1 line is considered a channel, 148 where: 150 The DS-3 line operates at speeds of 45 Mbps and is a single channel. The 151 T1 line operates at speeds of 1.536 Mbps and is a single channel consisting 152 of 24 T1 time slots. The E1 line operates at speeds of 1.984 Mbps and is a 153 single channel consisting of 30 DS0 time slots. 155 B. Channelized: The channel is any one of N time slots within a given 156 line, where: 158 The T1 line consists of any one or more channels. Each channel is any one 159 of 24 time slots. The T1 line operates at speeds in multiples of 56/64 Kbps 160 to 1.536 Mbps, with aggregate speed not exceeding 1.536 Mbps. The E1 line 161 consists of one or more channels. Each channel is any one of 31 time slots. 162 The E1 line operates at speeds in multiples of 64 Kbps to 1.984 Mbps, with 163 aggregate speed not exceeding 1.984 Mbps. 165 C. Fractional: The T1/E1 channel is one of the following groupings of 166 consecutively or nonconsecutively assigned time slots: 168 N DS0 time slots (NX56/64Kbps where N = 1 to 24 DS0 time slots per FT1 169 channel). 171 N E1 time slots (NX64Kbps, where N = 1 to 30 DS0 time slots per E1 172 channel). 174 Discussion: Access channels specify the physical layer interface speed of 175 a DTE or DCE. In the case of a DTE, this may not correspond to either the 176 CIR or EIR. Specifically, based on the service level agreement in place, 177 the user may not be able to access the entire bandwidth of the access 178 channel. 180 Specification: FRF 182 1.2.2. Access Rate (AR) 184 Definition: The data rate of the user access channel. The speed of the 185 access channel determines how rapidly (maximum rate) the end user can 186 inject data into a frame relay network. 188 Discussion: See Access Channel. 190 Specification: FRF 192 1.2.3. Backward Explicit Congestion Notification (BECN) 194 Definition: BECN is a bit in the frame relay header. The bit is set by a 195 congested network node in any frame that is traveling in the reverse 196 direction of the congestion. 198 Discussion: When a DTE receives frames with the BECN bit asserted, it 199 should begin congestion avoidance procedures. Since the BECN frames are 200 traveling in the opposite direction as the congested traffic, the DTE will 201 be the sender. The frame relay layer may communicate the possibility of 202 congestion to higher layers, which have inherent congestion avoidance 203 procedures, such as TCP. See Frame Relay Frame. 205 Specification: FRF 207 1.2.4. Burst Excess(Be) 209 Definition: The maximum amount of uncommitted data (in bits) in excess of 210 Committed Burst Size (Bc) that a frame relay network can attempt to deliver 211 during a Committed Rate Measurement Interval (Tc). This data (Be) generally 212 is delivered with a lower probability than Bc. The network treats Be data 213 as discard eligible. 215 Discussion: See also Committed burst Size (Bc), Committed Rate Measurement 216 Interval (Tc) and Discard Eligible (De). 218 Specification: FRF 220 1.2.5. Committed Burst Size (Bc) 222 Definition: The maximum amount of data (in bits) that the network agrees to 223 transfer, under normal conditions, during a time interval Tc. 225 Discussion: See also Excess Burst Size (Be) and Committed Rate Measurement 226 Interval (Tc). 228 Specification: FRF 230 1.2.6. Committed Information Rate (CIR) 232 Definition: CIR is the transport speed the frame relay network will 233 maintain between service locations when data is presented. 235 Discussion: CIR specifies the guaranteed data rate between two frame relay 236 terminal connected by a frame relay network. Data presented to the network 237 in excess of this data rate and below the Excess Information Rate (EIR) 238 will be marked as Discard Eligible and may be dropped. 240 Specification: FRF 242 1.2.7. Committed Rate Measurement Interval (Tc) 244 Definition: The time interval during which the user can send only Bc- 245 committed amount of data and Be excess amount of data. In general, the 246 duration of Tc is proportional to the "burstiness" of the traffic. Tc is 247 computed (from the subscription parameters of CIR and Bc) as Tc = Bc/CIR. 248 Tc is not a periodic time interval. Instead, it is used only to measure 249 incoming data, during which it acts like a sliding window. Incoming data 250 triggers the Tc interval, which continues until it completes its commuted 251 duration. 253 Discussion: See also Committed Information Rate (CIR) and committed Burst 254 Size (Bc). 256 Specification: FRF 258 1.2.8. Cyclic Redundancy Check (CRC) 260 Definition: A computational means to ensure the accuracy of frames 261 transmitted between devices in a frame relay network. The mathematical 262 function is computed, before the frame is transmitted, at the originating 263 device. Its numerical value is computed based on the content of the frame. 264 This value is compared with a recomputed value of the function at the 265 destination device. See also Frame Check Sequence (FCS). 267 Discussion: CRC is not a measurement, but it is possible to measure the 268 amount of time to perform a CRC on a string of bits. This measurement will 269 not be addressed in this document. 271 Specification: FRF 273 1.2.9. Data Communications Equipment (DCE) 275 Definition: Term defined by both frame relay and X.25 committees, that 276 applies to switching equipment and is distinguished from the devices that 277 attach to the network (DTE). 279 Discussion: Also see DTE. 281 Specification: FRF 283 1.2.10. Data Link Connection Identifier (DLCI) 285 Definition: A unique number assigned to a PVC end point in a frame relay 286 network. Identifies a particular PVC endpoint within a user's access 287 channel in a frame relay network and has local significance only to that 288 channel. 290 Discussion: None. 292 Specification: FRF 294 1.2.11. Data Terminal Equipment (DTE) 296 Definition: Any network equipment terminating a network connection and is 297 attached to the network. This is distinguished from Data Communications 298 Equipment (DCE), which provides switching and connectivity within the 299 network. 301 Discussion: See also DCE. 303 Specification: FRF 305 1.2.12. Discard Eligible (DE) 307 Definition: This is a bit in the frame relay header that provides a two 308 level priority indicator, used to bias discard frames in the event of 309 congestion toward lower priority frames. Similar to the CLP bit in ATM. 311 Discussion: See Frame Relay Frame. 313 Specification: FRF 315 1.2.13. Discardable frames 317 Definition: Frames identified as being eligible to be dropped in the event 318 of congestion. 320 Discussion: The discard eligible field in the frame relay header is the 321 correct -- and by far the most common -- means of indicating which frames 322 may be dropped in the event of congestion. However, DE is not the only 323 means of identifying which frames may be dropped. There are at least three 324 other cases that apply. 326 In the first case, network devices may prioritize frame relay traffic by 327 non-DE means. For example, many service providers prioritize traffic on a 328 per-PVC basis. In this instance, any traffic from a given DLCI (data link 329 channel identifier) may be dropped during congestion, regardless of whether 330 DE is set. 332 In the second case, some implementations use upper-layer criteria, such as 333 IP addresses or TCP or UDP port numbers, to prioritize traffic within a 334 single PVC. In this instance, the network device may evaluate discard 335 eligibility based on upper-layer criteria rather than the presence or 336 absence of a DE bit. 338 In the third case, the frame is discarded because of an error in the frame. 339 Specifically, frames that are too long or too short, frames that are not a 340 multiple of 8 bits in length, frames with an invalid or unrecognized DLCI, 341 frames with an abort sequence, frames with improper flag delimitation, and 342 frames that fail FCS. 344 Specification: FRMIB 346 1.2.14. Discarded frames 348 Definition: Those frames dropped by a network device. 350 Discussion: Discardable and discarded frames are not synonymous. Some 351 implementations may ignore DE bits or other criteria, even though they 352 supposedly use such criteria to determine which frames to drop in the event 353 of congestion. 355 In other cases, a frame with its DE bit set may not be dropped. One example 356 of this is in cases where congestion clears before the frame can be 357 evaluated. 359 Specification: DN 361 1.2.15. Forward Explicit Congestion Notification (FECN) 363 Definition: FECN is a bit in the frame relay header. The bit is set by a 364 congested network node in any frame that is traveling in the same direction 365 of the congestion. 367 Discussion: When a DTE receives frames with the FECN bit asserted, it 368 should begin congestion avoidance procedures. Since the FECN frames are 369 traveling in the same direction as the congested traffic, the DTE will be 370 the receiver. The frame relay layer may communicate the possibility of 371 congestion to higher layers, which have inherent congestion avoidance 372 procedures, such as TCP. See Frame Relay Frame. 374 Specification: FRF 376 1.2.16. Frame Check Sequence (FCS) 378 Definition: The standard 16-bit cyclic redundancy check used for HDLC and 379 frame relay frames. The FCS detects bit errors occurring in the bits of the 380 frame between the opening flag and the FCS, and is only effective in 381 detecting errors in frames no larger than 4096 octets. See also Cyclic 382 Redundancy Check (CRC). 384 Discussion: FCS is not a measurement, but it is possible to measure the 385 amount of time to perform a FCS on a string of bits. This measurement will 386 not be addressed in this document. 388 Specification: FRF 390 1.2.17. Frame Entry Event 392 Definition: Frame enters a network section or end system. The event occurs 393 when the last bit of the closing flag of the frame crosses the boundary. 395 Discussion: None. 397 Specification: FRF.13 399 1.2.18. Frame Exit Event 401 Definition: Frame exits a network section or end system. The event occurs 402 when the first bit of the address field of the frame crosses the boundary. 404 Discussion: None. 406 Specification: FRF.13 408 1.2.19. Frame Relay 410 Definition: A high-performance interface for packet-switching networks; 411 considered more efficient that X.25. Frame relay technology can handle 412 "bursty" communications that have rapidly changing bandwidth requirements. 414 Discussion: None. 416 Specification: FRF 418 1.2.20. Frame Relay Frame 420 Definition: A logical grouping of information sent as a link-layer unit 421 over a transmission medium. Frame relay frames consist of a pair of flags, 422 a header, a user data payload and a Frame Check Sequence (FCS). Bit 423 stuffing differentiates user data bytes from flags. By default, the header 424 is two octets, of which 10 bits are the Data Link Connection Identifier 425 (DLCI), 1 bit in each octet is used for address extension (AE), and 1 bit 426 each for Forward Explicit Congestion Notification (FECN), Backward Explicit 427 Congestion Notification (BECN) Command/Response (C/R) and Discard Eligible 428 (DE). The EA bit is set to one in the final octet containing the DLCI. A 429 header may span 2, 3 or 4 octets. 431 Bit 7 6 5 4 3 2 1 0 432 |---|---|---|---|---|---|---|---| 433 | FLAG | 434 |-------------------------------| 435 | Upper 6 bits of DLCI |C/R|AE | 436 |-------------------------------| 437 | DLCI |FE |BE |DE |AE | 438 | |CN |CN | | | 439 |-------------------------------| 440 | User Data up to | 441 | 1600 Octets | 442 |-------------------------------| 443 | First Octet of FCS | 444 |-------------------------------| 445 | Second Octet of FCS | 446 |-------------------------------| 447 | FLAG | 448 |-------------------------------| 450 Discussion: Frame Relay headers spanning 3 or 4 octets will not be 451 discussed in this document. Note, the measurements described later in 452 this document are based on 2 octet headers. If longer headers are used, 453 the metric values must take into account the associated overhead. See 454 BECN, DE, DLCI and FECN. 456 Specification: FRF 458 1.2.21. Excess Information Rate (EIR) 460 Definition: See Burst Excess. 462 Discussion: None. 464 Specification: FRF 465 1.2.22. Network Interworking (FRF.5) 467 Definition: FRF.5 defines a protocol mapping called Network Interworking between 468 Frame Relay and Asynchronous Transfer Mode (ATM). Protocol mapping occurs when 469 the network performs conversions in such a way that within a common layer 470 service, the protocol information of one protocol is extracted and mapped on 471 protocol information of another protocol. This means that each communication 472 terminal supports different protocols. The common layer service provided in 473 this interworking scenario is defined by the functions, which are common to the 474 two protocols. Specifically, the ATM terminal must be configured to 475 interoperate with the Frame Relay network and vice versa. 477 Discussion: None. 479 Specification: FRF.5 481 1.2.23. Port speed 483 Definition: See Access Rate 485 Discussion: None. 487 Specification: FRF 489 1.2.24. Service Interworking (FRF.8) 491 Definition: FRF.8 defines a protocol encapsulation called Service Interworking. 492 Protocol encapsulation occurs when the conversions in the network or in the 493 terminals are such that the protocols used to provide one service make use of 494 the layer service provided by another protocol. This means that at the 495 interworking point, the two protocols are stacked. When encapsulation is 496 performed by the terminal, this scenario is also called interworking by port 497 access. Specifically, the ATM service user performs no Frame Relaying specific 498 functions, and Frame Relaying service user performs no ATM service specific 499 functions. 501 Discussion: None. 503 Specification: FRF.8 505 1.2.25. Service Availability Parameters 506 Definition: The service availability parameters report the operational 507 readiness of individual frame relay virtual connections. Service 508 availability is affected by service outages. 510 Discussion: Service availability parameters provide metrics for 511 assessment of frame relay network health and are used to monitor 512 compliance with service level agreements. See Services Outages. 514 Specification: FRF.13 516 1.2.26. Service Outages 518 Definition: Any event that interrupts the transport of frame relay traffic. Two 519 types of outages are differentiated: 521 1) Fault outages: Outages resulting from faults in the network and thus tracked 522 by the service availability parameters, and 524 2) Excluded outages: Outages resulting from faults beyond the control of 525 the network as well as scheduled maintenance. 527 Discussion: Service availability can be defined on a per-VC basis and/or on a 528 per-port basis. Frame relay port-based service availability parameters are not 529 addressed in this document. See Service Availability Parameters. 531 Specification: FRF.13 533 2. Performance Metrics 535 2.1. Definition Format (from RFC1242) 537 Metric to be defined. 539 Definition: The specific definition for the metric. 541 Discussion: A brief discussion of the metric, its application and any 542 restrictions on measurement procedures. 544 Measurement units: Intrinsic units used to quantify this metric. This 545 includes subsidiary units, e.g. microseconds are acceptable if the 546 intrinsic unit is seconds. 548 2.2. Definitions 550 2.2.1. Physical Layer- Plesiochronous Data Hierarchy (PDH) 552 2.2.1.1. Alarm Indication Signal (AIS) 554 Definition: An all 1's frame transmitted after the DTE or DCE detects a 555 defect for 2.5 s +/- 0.5 s. 557 Discussion: An AIS will cause loss of information in the PDH frame which 558 contains a frame relay frame which may contain IP datagrams. 560 Measurement units: Seconds. 562 2.2.1.2. Loss of Frame (LOF) 564 Definition: An NE transmits an LOF when an OOF condition persists. 566 Discussion: A LOF will cause loss of information in the PDH frame which 567 contains a frame relay frame which may contain IP datagrams. 569 Measurement units: Seconds. 571 2.2.1.3. Loss of Signal (LOS) 573 Definition: Indicates that there are no transitions occurring in the 574 received signal. 576 Discussion: A LOS will cause loss of information in the PDH frame which 577 contains a frame relay frame which may contain IP datagrams. 579 Measurement units: Seconds. 581 2.2.1.4. Out of Frame (OOF) 583 Definition: An NE transmits an OOF downstream when it receives framing 584 errors in a specified number of consecutive frame bit positions. 586 Discussion: An OOF will cause loss of information in the PDH frame which 587 contains a frame relay frame which may contain IP datagrams. 589 Measurement units: Seconds. 591 2.2.1.5. Remote Alarm Indication (RAI) 593 Definition: Previously called Yellow Alarm. Transmitted upstream by an NE 594 to indicate that it detected an LOS, LOF, or AIS. 596 Discussion: An RAI will cause loss of information in the transmitted PDH 597 frame, which may contain a frame relay frame, which, in turn, may contain 598 IP datagrams. 600 Measurement units: Seconds. 602 2.2.2. Frame Relay Layer 604 2.2.2.1. Data Delivery Ratio (DDR) 606 Definition: The DDR service level parameter reports the networks 607 effectiveness in transporting offered data (payload without address field 608 or FCS) in one direction of a single virtual connection. The DDR is a ratio 609 of successful payload octets received to attempted payload octets 610 transmitted. Attempted payload octets transmitted are referred to as 611 DataOffered. Successfully delivered payload octets are referred to as 612 DataDelivered. These loads are further differentiated as being within the 613 committed information rate or as burst excess. 615 Three data relay ratios may be reported: 617 Data Delivery Ratio (DDR): 619 (DataDelivered_c + DataDelivered_e DataDelivered_e+c 620 DDR = ------------------------------- = --------------- 621 (DataOffered_c + DataOffered_e) DataOffered_e+c 623 Data Delivery Ratio (DDR_c) for load consisting of frames within the 624 committed information rate: 626 DataDelivered_c 627 DDR_c = ------------- 628 DataOffered_c 630 Data Delivery Ratio (DDR_e) for load in excess of the committed information 631 rate: 633 DataDelivered_e 634 DDR_e = ------------- 635 DataOffered_e 637 where 638 DataDelivered_c: Successfully delivered data payload octets within 639 committed information rate 641 DataDelivered_e: Successfully delivered data payload octets in excess of 642 CIR 644 DataDelivereD_e+c: Successfully delivered total data payload octets, 645 including those within committed information rate and those in excess of 646 CIR 648 DataOffered_c: Attempted data payload octet transmissions within 649 committed information rate 651 DataOffered_e: Attempted data payload octet transmissions in excess of 652 CIR 654 DataOffered_e+c: Attempted total data payload octet transmissions, 655 including those within committed information rate and those in excess of 656 CIR 658 Each direction of a full duplex connection has a discrete set of data 659 delivery ratios. 661 Discussion: Data delivery ratio measurements may not be representative of 662 data delivery effectiveness for a given application. For example, the 663 discarding of a small frame containing an acknowledgement message may 664 result in the retransmission of a large number of data frames. In such an 665 event, a good data delivery ratio would be reported while the user 666 experienced poor performance. 668 Measurement units: dimensionless. 670 2.2.2.2. Frame Delivery Ratio (FDR) 672 Definition: The FDR service level parameter reports the networks 673 effectiveness in transporting an offered frame relay load in one direction 674 of a single virtual connection. The FDR is a ratio of successful frame 675 receptions to attempted frame transmissions. Attempted frame transmissions 676 are referred to as Frames Offered. Successfully delivered frames are 677 referred to as Frames Delivered. These loads may be further differentiated 678 as being within the committed information rate or as burst excess. 680 Frame Delivery Ratio (FDR): 682 (FramesDelivered_c + FramesDelivered_e) FramesDelivered_e+c 683 FDR = ----------------------------------- = ------------------ 684 (FramesOffered_c + FramesOffered_e) FramesOffered_e+c 686 Frame Delivery Ratio (FDR_c) for load consisting of frames within the 687 committed information rate: 689 FramesDelivered_c 690 FDR_c = ---------------- 691 FramesOffered_c 693 Frame Delivery Ratio (FDR_c) for load in excess of the committed 694 information rate: 696 FramesDelivered_e 697 FDR_e = ---------------- 698 FramesOffered_e 700 where 701 FramesDelivered_c: Successfully delivered frames within committed 702 information rate 704 FramesDelivered_e: Successfully delivered frames in excess of CIR 706 FramesDelivered_e+c: Successfully delivered total frames, including 707 those within committed information rate and those in excess of CIR 709 FramesOffered_c: Attempted frame transmissions within committed 710 information rate 712 FramesOffered_e: Attempted frame transmissions in excess of CIR 713 FramesOffered_e+c: Attempted total frame transmissions, including those 714 within committed information rate and those in excess of CIR 716 An independent set of frame delivery ratios exists for each direction of a 717 full duplex connection. 719 Discussion: Frame delivery ratio measurements may not be representative of 720 frame delivery effectiveness for a given application. For example, the 721 discarding of a small frame containing an acknowledgement message may 722 result in the retransmission of a large number of data frames. In such an 723 event, a good data delivery ratio would be reported while the user 725 Measurement units: dimensionless. 727 2.2.2.3. Frame Discard Ratio (FDR) 729 Definition: The number of received frames that are discarded because of a 730 frame error divided by the total number of received frames in one direction 731 of a single virtual connection. Frame errors are defined as follows: 733 1) frames that are too long or too short, 734 2) frames that are not a multiple of 8 bits in length, 735 3) frames with an invalid or unrecognized DLCI, 736 4) frames with an abort sequence, 737 5) frames with improper flag delimitation, 738 6) frames that fail FCS. 740 The formal definition of frame discard ratio is as follows: 742 FDR = sum {i=1 to N} fr_i 743 ------------------- 744 sum {i=1 to N} ft_i, 746 where 747 fr_i is the number of successfully delivered frames for a particular DLCI at 748 second i, 750 and 752 ft_i is the total number of attempted frame transmissions within the committed 753 information rate for a particular DLCI at second i. 755 Discussion: Frame discards can adversely effect applications running on IP over 756 FR. In general, frame discards will negatively impact TCP throughput; however, 757 in the case of frame discard due to frame error, frame discard will improve 758 performance by dropping errored frames. As a result, these frames will not 759 adversely effect the forwarding of retransmitted frames. 761 Measurement units: dimensionless. 763 2.2.2.4. Frame Error Ratio (FER) 765 Definition: The number of received frames that contain an error in the frame 766 payload divided by the total number of received frames in one direction of a 767 single virtual connection. 769 The formal definition of frame error ratio is as follows: 771 FDR = sum {i=1 to N} fe_i 772 ------------------- 773 sum {i=1 to N} ft_i, 775 where 776 fe_i is the number of frames containing a payload error for a particular DLCI at 777 second i, 779 and 781 ft_i is the total number of attempted frame transmissions within the committed 782 information rate for a particular DLCI at second i. 784 Discussion: The delivery of frames containing errors will adversely effect 785 applications running on IP over FR. Typically, these errors are caused by 786 transmission errors and flagged as failed FCS frames; however, when Frame Relay 787 to ATM Network interworking is used, an error may be injected in the frame 788 payload which, in turn, is encapsulated into an AAL5 PDU (see RFC 2761 for a 789 discussion of AAL5 related metrics). 791 Measurement units: dimensionless. 793 2.2.2.5. Frame Excess Ratio (FXR) 795 Definition: The number of frames received by the network and treated as excess 796 traffic divided by the total number of received frames in one direction of a 797 single virtual connection. Frames which are sent to the network with DE set to 798 zero are treated as excess when more than Bc bits are submitted to the network 799 during the Committed Information Rate Measurement Interval (Tc). Excess traffic 800 may or may not be discarded at the ingress if more than Bc + Be bits are 801 submitted to the network during Tc. Traffic discarded at the ingress is not 802 recorded in this measurement. Frames which are sent to the network with DE set 803 to one are also treated as excess traffic. 805 The formal definition of frame excess ratio is as follows: 807 FXR = sum {i=1 to N} fc_i 808 1 - ------------------- 809 sum {i=1 to N} ft_i, 811 where 813 fc_i is the total number of frames which were submitted within the traffic 814 contract for a particular DLCI at second i 816 and 818 ft_i is the total number of attempted frame transmissions for a particular DLCI 819 at second i. 821 Discussion: Frame discards can adversely effect applications running on IP over 822 FR. Specifically, frame discards will negatively impact TCP throughput. 824 Measurement units: dimensionless. 826 2.2.2.6. Frame Loss Ratio (FLR) 828 Definition: The FLR is a ratio of successful frame receptions to attempted frame 829 transmissions at the committed information rate, in one direction of a single 830 virtual connection. Attempted frame transmissions are referred to as Frames 831 Offered. Successfully delivered frames are referred to as Frames Delivered. 833 The formal definition of frame loss ratio is as follows: 835 FramesDelivered_c 836 FLR = 1- ----------------- 837 FramesOffered_c 839 where 840 FramesDelivered_c is the successfully delivered frames within committed 841 information rate for a given DLCI, 843 and 845 FramesOffered_c is the attempted frame transmissions within committed 846 information rate for a given DLCI 848 An independent set of frame delivery ratios exists for each direction of a full 849 duplex connection. 851 Discussion: Frame delivery loss measurements may not be representative of frame 852 delivery effectiveness for a given application. For example, the loss of a 853 small frame containing an acknowledgement message may result in the 854 retransmission of a large number of data frames. In such an event, a good data 855 delivery ratio would be reported while the user 857 Measurement units: dimensionless. 859 2.2.2.7. Frame Policing Ratio (FPR) 861 Definition: The number of frames received by the network and treated as excess 862 traffic and dropped divided by the total number of received frames, in one 863 direction of a single virtual connection. Frames which are sent to the network 864 with DE set to zero are treated as excess when more than Bc bits are submitted 865 to the network during the Committed Information Rate Measurement Interval (Tc). 866 Excess traffic may or may not be discarded at the ingress if more than Bc + Be 867 bits are submitted to the network during Tc. Traffic discarded at the ingress 868 is recorded in this measurement. Frames which are sent to the network with DE 869 set to one are also treated as excess traffic. 871 The formal definition of frame excess ratio is as follows: 873 FPR = sum {i=1 to N} fr_i 874 1- ------------------- 875 sum {i=1 to N} ft_i, 877 where 878 fr_i is the successfully delivered frames for a particular DLCI at second i, 880 and 881 ft_i is the total number of attempted frame transmissions for a particular DLCI 882 at second i. 884 Discussion: Frame discards can adversely effect applications running on IP over 885 FR. Specifically, frame discards will negatively impact TCP throughput. 887 2.2.2.8. Frame Transfer Delay (FTD) 889 Definition: The time required to transport frame relay data from measurement 890 point 1 to measurement point 2. The frame transfer delay is the difference in 891 seconds between the time a frame exits measurement point 1 and the time the same 892 frame enters measurement point 2, in one direction of a single virtual 893 connection. The formal definition of frame transfer delay is as follows: 895 FTD = 1/N * sum {i=1 to N} t2_i - t1_i, 897 where 898 t1 is the time in seconds when a frame left measurement point 1 (i.e., frame 899 exit event), 901 t2 is the time in seconds when a frame arrived at measurement point 2 (i.e., 902 frame entry event). FTD is computed for a specific DLCI and a specified 903 integration period of N seconds 905 Discussion: While frame transfer delay is usually computed as an average 906 and, thus, can effect neither IP nor TCP performance, applications such as 907 voice over IP may be adversely effected by excessive FTD. 909 Measurement units: seconds. 911 2.2.2.9. Frame Transfer Delay Variation (FTDV) 913 Definition: The variation in the time required to transport frame relay data 914 from measurement point 1 to measurement point 2. The frame transfer delay 915 variation is the difference in seconds between maximum frame transfer delay and 916 the minimum frame transfer delay, in one direction of a single virtual 917 connection. The formal definition of frame transfer delay is as follows 919 FTDV = max {i=1 to N} FTD_i - min {i=1 to N} FTD_i. 921 where 922 FTD is defined as above. 923 Discussion: Large values of FTDV can adversely effect TCP round trip time 924 calculation and, thus, TCP throughput. 926 Measurement units: seconds. 928 3. Security Considerations. 930 As this document is solely for providing terminology and describes 931 neither a protocol nor an implementation, there are no security 932 considerations associated with this document. 934 4. Notices 936 Internet Engineering Task Force 938 The IETF takes no position regarding the validity or scope of any 939 intellectual property or other rights that might be claimed to pertain 940 to the implementation or use of the technology described in this 941 document or the extent to which any license under such rights might or 942 might not be available; neither does it represent that it has made any 943 effort to identify any such rights. Information on the IETFs procedures 944 with respect to rights in standards-track and standards- related 945 documentation can be found in BCP-11. Copies of claims of rights made 946 available for publication and any assurances of licenses to be made 947 available, or the result of an attempt made to obtain a general license 948 or permission for the use of such proprietary rights by implementors or 949 users of this specification can be obtained from the IETF Secretariat. 951 The IETF invites any interested party to bring to its attention any 952 copyrights, patents or patent applications, or other proprietary rights, 953 which may cover technology that may be required to practice this 954 standard. Please address the information to the IETF Executive 955 Director. 957 Frame Relay Forum 959 Copyright Frame Relay Forum 1998. All Rights Reserved. References FRF, 960 FRF.5, FRF.8 and FRF.13 and translations of them may be copied and 961 furnished to others, and works that comment on or otherwise explain it 962 or assist in their implementation may be prepared, copied, published and 963 distributed, in whole or in part, without restriction of any kind, 964 provided that the above copyright notice and this paragraph are included 965 on all such copies and derivative works. However, these documents 966 themselves may not be modified in any way, such as by removing the 967 copyright notice or references to the Frame Relay Forum, except as 968 needed for the purpose of developing Frame Relay standards (in which 969 case the procedures for copyrights defined by the Frame Relay Forum must 970 be followed), or as required to translate it into languages other than 971 English. 973 5. Disclaimer 975 Copyright (C) The Internet Society (1999). All Rights Reserved. 977 This document and translations of it may be copied and furnished to 978 others, and derivative works that comment on or otherwise explain it or 979 assist in its implementation may be prepared, copied, published and 980 distributed, in whole or in part, without restriction of any kind, 981 provided that the above copyright notice and this paragraph are included 982 on all such copies and derivative works. However, this document itself 983 may not be modified in any way, such as by removing the copyright notice 984 or references to the Internet Society or other Internet organizations, 985 except as needed for the purpose of developing Internet standards in 986 which case the procedures for copyrights defined in the Internet 987 Standards process must be followed, or as required to translate it into 988 languages other than English. 990 The limited permissions granted above are perpetual and will not be 991 revoked by the Internet Society or its successors or assigns. This 992 document and the information contained herein is provided on an "AS IS" 993 basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 994 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 995 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 996 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 997 PARTICULAR PURPOSE. 999 6. References 1001 [DN] Private communication from David Newman, Network Test, Inc. 1003 [FRF] Frame Relay Forum Glossary, http://www.frforum.com, 1999. 1005 [FRF.5] Frame Relay Forum, Frame Relay/ATM PVC Network Interworking 1006 Implementation Agreement, December 1994. 1008 [FRF.8] Frame Relay Forum, Frame Relay/ATM PVC Service Interworking 1009 Implementation Agreement, April 1995. 1011 [FRF.13] Frame Relay Forum, Service Level Definitions Implementation 1012 Agreement, August 1998. 1014 [FRMIB] Definitions of Managed Objects for Frame Relay Service, draft- 1015 ietf-frnetmib-frs-mib-09.txt, November, 1999. 1017 7. Editors Addresses 1019 Jeffrey Dunn 1020 Advanced Network Consultants, Inc. 1021 4214 Crest Place, Ellicott City, MD 21043 USA 1022 Phone: +1 (410) 750-1700, E-mail: Jeffrey.Dunn@worldnet.att.net 1024 Cynthia Martin 1025 Advanced Network Consultants, Inc. 1026 4214 Crest Place, Ellicott City, MD 21043 USA 1027 Phone: +1 (410) 750-1700, E-mail: Cynthia.E.Martin@worldnet.att.net