idnits 2.17.1 draft-ietf-bmwg-fr-term-05.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 179 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 353 instances of too long lines in the document, the longest one being 321 characters in excess of 72. ** 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...' == (174 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 1003, but no explicit reference was found in the text == Unused Reference: 'FRF' is defined on line 1005, but no explicit reference was found in the text == Unused Reference: 'FRMIB' is defined on line 1016, 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 (~~), 14 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 October, 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 computed 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: Dimensionless. 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: Dimensionless. 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: Dimensionless. 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: Dimensionless. 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: Dimensionless. 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 committed 624 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 639 DataDelivered_c: Successfully delivered data payload octets within committed 640 information rate, 642 DataDelivered_e: Successfully delivered data payload octets in excess of CIR, 644 DataDelivereD_e+c: Successfully delivered total data payload octets, including those within committed information rate and those in excess of CIR, 646 DataOffered_c: Attempted data payload octet transmissions within committed 647 information rate, 649 DataOffered_e: Attempted data payload octet transmissions in excess of CIR 651 and 653 DataOffered_e+c: Attempted total data payload octet transmissions, including 654 those within committed information rate and those in excess of CIR 656 Each direction of a full duplex connection has a discrete set of data delivery 657 ratios. 659 Discussion: Data delivery ratio measurements may not be representative of data 660 delivery effectiveness for a given application. For example, the discarding of 661 a small frame containing an acknowledgement message may result in the 662 retransmission of a large number of data frames. In such an event, a good data 663 delivery ratio would be reported while the user experienced poor performance. 665 Measurement units: dimensionless. 667 2.2.2.2. Frame Delivery Ratio (FDR) 669 Definition: The FDR service level parameter reports the networks effectiveness 670 in transporting an offered frame relay load in one direction of a single virtual 671 connection. The FDR is a ratio of successful frame receptions to attempted frame 672 transmissions. Attempted frame transmissions are referred to as Frames Offered. 673 Successfully delivered frames are referred to as Frames Delivered. These loads 674 may be further differentiated as being within the committed information rate or 675 as burst excess. 677 Frame Delivery Ratio (FDR): 679 (FramesDelivered_c + FramesDelivered_e) FramesDelivered_e+c 680 FDR = ------------------------------------- = ------------------- 681 (FramesOffered_c + FramesOffered_e) FramesOffered_e+c 683 Frame Delivery Ratio (FDR_c) for load consisting of frames within the committed 684 information rate: 686 FramesDelivered_c 687 FDR_c = ----------------- 688 FramesOffered_c 690 Frame Delivery Ratio (FDR_c) for load in excess of the committed information 691 rate: 693 FramesDelivered_e 694 FDR_e = ----------------- 695 FramesOffered_e 697 where 699 FramesDelivered_c: Successfully delivered frames within committed information rate, 701 FramesDelivered_e: Successfully delivered frames in excess of CIR, 703 FramesDelivered_e+c: Successfully delivered total frames, including those within committed information rate and those in excess of CIR, 705 FramesOffered_c: Attempted frame transmissions within committed information rate, 707 FramesOffered_e: Attempted frame transmissions in excess of CIR 709 and 711 FramesOffered_e+c: Attempted total frame transmissions, including those within committed information rate and those in excess of CIR. 713 An independent set of frame delivery ratios exists for each direction of a full 714 duplex connection. 716 Discussion: Frame delivery ratio measurements may not be representative of frame 717 delivery effectiveness for a given application. For example, the discarding of 718 a small frame containing an acknowledgement message may result in the 719 retransmission of a large number of data frames. In such an event, a good data 720 delivery ratio would be reported while the user 722 Measurement units: dimensionless. 724 2.2.2.3. Frame Discard Ratio (FDR) 726 Definition: The number of received frames that are discarded because of a frame 727 error divided by the total number of transmitted frames in one direction of a 728 single virtual connection. Frame errors are defined as follows: 730 1) frames that are too long or too short, 731 2) frames that are not a multiple of 8 bits in length, 732 3) frames with an invalid or unrecognized DLCI, 733 4) frames with an abort sequence, 734 5) frames with improper flag delimitation, 735 6) frames that fail FCS. 737 The formal definition of frame discard ratio is as follows: 739 sum {i=1 to N} fr_i 740 FDR = ------------------- 741 sum {i=1 to N} ft_i, 743 where 745 fr_i is the number of successfully delivered frames for a particular DLCI at second i 747 and 749 ft_i is the total number of attempted frame transmissions within the committed plus extended information rate for a particular DLCI at second i. 751 Discussion: Frame discards can adversely effect applications running on IP over 752 FR. In general, frame discards will negatively impact TCP throughput; however, 753 in the case of frame discard due to frame error, frame discard will improve 754 performance by dropping errored frames. As a result, these frames will not 755 adversely effect the forwarding of retransmitted frames 757 Measurement units: dimensionless. 759 2.2.2.4. Frame Error Ratio (FER) 761 Definition: The number of received frames that contain an error in the frame 762 payload divided by the total number of transmitted frames in one direction of a 763 single virtual connection. 765 The formal definition of frame error ratio is as follows: 767 sum {i=1 to N} fe_i 768 FER = ------------------- 769 sum {i=1 to N} ft_i, 771 where 773 fe_i is the number of frames containing a payload error for a particular DLCI at second i 775 and 777 ft_i is the total number of attempted frame transmissions within the committed plus the extended information rate for a particular DLCI at second i. This statistic includes those frames which have an error in the Frame Check Sequence (FCS). Frame errors in the absence of FCS errors can be detected by sending frames containing a known pattern; however, this indicates an equipment defect. 779 Discussion: The delivery of frames containing errors will adversely effect 780 applications running on IP over FR. Typically, these errors are caused by 781 transmission errors and flagged as failed FCS frames; however, when Frame Relay 782 to ATM Network interworking is used, an error may be injected in the frame 783 payload which, in turn, is encapsulated into an AAL5 PDU (see RFC 2761 for a 784 discussion of AAL5 related metrics). 786 Measurement units: dimensionless. 788 2.2.2.5. Frame Excess Ratio (FXR) 790 Definition: The number of frames received by the network and treated as excess 791 traffic divided by the total number of transmitted frames in one direction of a 792 single virtual connection. Frames which are sent to the network with DE set to 793 zero are treated as excess when more than Bc bits are submitted to the network 794 during the Committed Information Rate Measurement Interval (Tc). Excess traffic 795 may or may not be discarded at the ingress if more than Bc + Be bits are 796 submitted to the network during Tc. Traffic discarded at the ingress is not 797 recorded in this measurement. Frames which are sent to the network with DE set 798 to one are also treated as excess traffic. 800 The formal definition of frame excess ratio is as follows: 802 sum {i=1 to N} fc_i 803 FXR = 1 - ------------------- 804 sum {i=1 to N} ft_i, 806 where 808 fc_i is the total number of frames which were submitted within the traffic 809 contract for a particular DLCI at second i 811 and 813 ft_i is the total number of attempted frame transmissions for a particular DLCI at second i. 815 Discussion: Frame discards can adversely effect applications running on IP over 816 FR. Specifically, frame discards will negatively impact TCP throughput. 818 Measurement units: dimensionless. 820 2.2.2.6. Frame Loss Ratio (FLR) 822 Definition: The FLR is a ratio of successful frame receptions to attempted frame 823 transmissions at the committed information rate, in one direction of a single 824 virtual connection. Attempted frame transmissions are referred to as Frames 825 Offered. Successfully delivered frames are referred to as Frames Delivered. 827 The formal definition of frame loss ratio is as follows: 829 FramesDelivered_c 830 FLR = 1- ----------------- 831 FramesOffered_c, 833 where 835 FramesDelivered_c is the successfully delivered frames within committed 836 information rate for a given DLCI 838 and 840 FramesOffered_c is the attempted frame transmissions within committed 841 information rate for a given DLCI 843 An independent set of frame delivery ratios exists for each direction of a full 844 duplex connection. 846 Discussion: Frame delivery loss measurements may not be representative of frame 847 delivery effectiveness for a given application. For example, the loss of a 848 small frame containing an acknowledgement message may result in the 849 retransmission of a large number of data frames. In such an event, a good data 850 delivery ratio would be reported while the user 852 Measurement units: dimensionless. 854 2.2.2.7. Frame Policing Ratio (FPR) 856 Definition: The number of frames received by the network and treated as excess 857 traffic and dropped divided by the total number of received frames, in one 858 direction of a single virtual connection. Frames which are sent to the network 859 with DE set to zero are treated as excess when more than Bc bits are submitted 860 to the network during the Committed Information Rate Measurement Interval (Tc). 861 Excess traffic may or may not be discarded at the ingress if more than Bc + Be 862 bits are submitted to the network during Tc. Traffic discarded at the ingress 863 is recorded in this measurement. Frames which are sent to the network with DE 864 set to one are also treated as excess traffic. 866 The formal definition of frame excess ratio is as follows: 868 sum {i=1 to N} fr_i 869 FPR = 1- ------------------- 870 sum {i=1 to N} ft_i, 872 where 874 fr_i is the successfully delivered frames for a particular DLCI at second i 876 and 878 ft_i is the total number of attempted frame transmissions for a particular DLCI 879 at second i. 881 Discussion: Frame discards can adversely effect applications running on IP over 882 FR. Specifically, frame discards will negatively impact TCP throughput. 884 2.2.2.8. Frame Transfer Delay (FTD) 885 Definition: The time required to transport frame relay data from measurement 886 point 1 to measurement point 2. The frame transfer delay is the difference in 887 seconds between the time a frame exits measurement point 1 and the time the same 888 frame enters measurement point 2, in one direction of a single virtual 889 connection. The formal definition of frame transfer delay is as follows: 891 FTD = 1/N * sum {i=1 to N} t2_i - t1_i, 893 where 895 t1_i is the time in seconds when the ith frame leaves measurement point 1 (i.e., frame exit event), 897 t2 is the time in seconds when the ith frame arrives at measurement point 2 (i.e., frame entry event) 899 and 901 N is the number of frames received during a measurement interval T. 903 FTD is computed for a specific DLCI and a specified integration period of T seconds. The computation does not include frames which are transmitted during the measurement period but not received. 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 923 FTD and N are defined as above. 925 Discussion: Large values of FTDV can adversely effect TCP round trip time 926 calculation and, thus, TCP throughput. 928 Measurement units: seconds. 930 3. Security Considerations. 932 As this document is solely for providing terminology and describes 933 neither a protocol nor an implementation, there are no security 934 considerations associated with this document. 936 4. Notices 938 Internet Engineering Task Force 940 The IETF takes no position regarding the validity or scope of any 941 intellectual property or other rights that might be claimed to pertain 942 to the implementation or use of the technology described in this 943 document or the extent to which any license under such rights might or 944 might not be available; neither does it represent that it has made any 945 effort to identify any such rights. Information on the IETFs procedures 946 with respect to rights in standards-track and standards- related 947 documentation can be found in BCP-11. Copies of claims of rights made 948 available for publication and any assurances of licenses to be made 949 available, or the result of an attempt made to obtain a general license 950 or permission for the use of such proprietary rights by implementors or 951 users of this specification can be obtained from the IETF Secretariat. 953 The IETF invites any interested party to bring to its attention any 954 copyrights, patents or patent applications, or other proprietary rights, 955 which may cover technology that may be required to practice this 956 standard. Please address the information to the IETF Executive 957 Director. 959 Frame Relay Forum 961 Copyright Frame Relay Forum 1998. All Rights Reserved. References FRF, 962 FRF.5, FRF.8 and FRF.13 and translations of them may be copied and 963 furnished to others, and works that comment on or otherwise explain it 964 or assist in their implementation may be prepared, copied, published and 965 distributed, in whole or in part, without restriction of any kind, 966 provided that the above copyright notice and this paragraph are included 967 on all such copies and derivative works. However, these documents 968 themselves may not be modified in any way, such as by removing the 969 copyright notice or references to the Frame Relay Forum, except as 970 needed for the purpose of developing Frame Relay standards (in which 971 case the procedures for copyrights defined by the Frame Relay Forum must 972 be followed), or as required to translate it into languages other than 973 English. 975 5. Disclaimer 977 Copyright (C) The Internet Society (1999). All Rights Reserved. 979 This document and translations of it may be copied and furnished to 980 others, and derivative works that comment on or otherwise explain it or 981 assist in its implementation may be prepared, copied, published and 982 distributed, in whole or in part, without restriction of any kind, 983 provided that the above copyright notice and this paragraph are included 984 on all such copies and derivative works. However, this document itself 985 may not be modified in any way, such as by removing the copyright notice 986 or references to the Internet Society or other Internet organizations, 987 except as needed for the purpose of developing Internet standards in 988 which case the procedures for copyrights defined in the Internet 989 Standards process must be followed, or as required to translate it into 990 languages other than English. 992 The limited permissions granted above are perpetual and will not be 993 revoked by the Internet Society or its successors or assigns. This 994 document and the information contained herein is provided on an "AS IS" 995 basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 996 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 997 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 998 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 999 PARTICULAR PURPOSE. 1001 6. References 1003 [DN] Private communication from David Newman, Network Test, Inc. 1005 [FRF] Frame Relay Forum Glossary, http://www.frforum.com, 1999. 1007 [FRF.5] Frame Relay Forum, Frame Relay/ATM PVC Network Interworking 1008 Implementation Agreement, December 1994. 1010 [FRF.8] Frame Relay Forum, Frame Relay/ATM PVC Service Interworking 1011 Implementation Agreement, April 1995. 1013 [FRF.13] Frame Relay Forum, Service Level Definitions Implementation 1014 Agreement, August 1998. 1016 [FRMIB] Definitions of Managed Objects for Frame Relay Service, draft- 1017 ietf-frnetmib-frs-mib-09.txt, November, 1999. 1019 7. Editors Addresses 1021 Jeffrey Dunn 1022 Advanced Network Consultants, Inc. 1023 4214 Crest Place, Ellicott City, MD 21043 USA 1024 Phone: +1 (410) 750-1700, E-mail: Jeffrey.Dunn@worldnet.att.net 1026 Cynthia Martin 1027 Advanced Network Consultants, Inc. 1028 4214 Crest Place, Ellicott City, MD 21043 USA 1029 Phone: +1 (410) 750-1700, E-mail: Cynthia.E.Martin@worldnet.att.net