****************************************************************** ATM Forum Document Number: ATM Forum/97-0610R1 ****************************************************************** Title: Frame-Level Performance Management Requirements for ATM Networks ****************************************************************** Abstract: Requirements for the performance management of the M4 interface are proposed. ****************************************************************** Source: Suba Varadarajan, Raj Jain The Ohio State University (and NASA) Department of Computer and Information Science Columbus, OH 43210 Phone: 614-292-3989, Fax: 614-292-2911, Email: jain@cse.wustl.edu Aditya Sehgal Southwestern Bell Communications (SBC) Austin, Texas Phone: 512-372-5747 Fax: 512-372-5791 Email: sehgal@tri.sbc.com ****************************************************************** Date: September 1997 ****************************************************************** Distribution: ATM Forum Technical Working Group members (AF-TM and AF-NM) ****************************************************************** Notice: This contribution has been prepared to assist the ATM Forum. It is offered to the Forum as a basis for discussion and is not a binding proposal on the part of any of the contributing organizations. The statements are subject to change in form and content after further study. Specifically, the contributors reserve the right to add to, amend or modify the statements contained herein. ****************************************************************** This is a revised version of atm97-0610 that was presented to AF- NM in the July meeting. The network management group indicated that this and related contributions should be discussed in AF-TM first or jointly in AF-TM and AF-NM. Therefore, this revised version of atm97-0610 and an associated contribution atm97-0860 are being distributed to both groups. 1 Introduction Performance management of ATM networks is useful to determine the current performance of the networks as well as planning for future capacity of the networks. In many ATM data services including ABR and UBR, a user can request frame-level treatment of data. For example, a user can signal its preference for early packet discard (EPD) indicating that the network discards whole frames rather than individual cells. Frame- level performance (and conformance) is emphasized further in the upcoming "Guaranteed Frame Rate" (GFR) service. In that service, the loss rates are guaranteed for frames. When a frame is dropped all cells of the frame are dropped (without any additional harm to the user). Unfortunately, ATM network management information bases (MIBs) as currently defined do not provide any frame-level information. It is not possible for a network manager to monitor how many cells were dropped due to EPD. This contribution proposes that we include a minimal set of optional counters in the MIB that can be used by product manufacturers and network managers interested in frame-level service. Note that in this contribution, the term "frame" refers to AAL5 protocol data unit (PDU). ATM switches can identify beginning and end of frames by looking at the "End of Frame" (EOF) code in the PTI field of the ATM cell header. All frame-level counts discussed in this contribution apply only to frame-level services using AAL5. This can apply to all data services: UBR, ABR, and GFR. To measure the performance of ATM networks, certain performance metrics (1) need to be calculated for both permanent (PVP or PVC) and switched (SVP or SVC) connections. These metrics should be calculated with reference to a i) switch ii) port iii) link iv) connection (VP or VC) In other words, the performance metrics should be applied to all the permanent and switched connections passing through the switch Similarly, the metrics should be applied for each port as well as each link. [It is necessary to collect metrics for a switch and link separately. Aggregates will not work. For example, for a 1->N multicast, the counts for the links will be different from the counts for connections. For a switch, loss of cells (frames) from any queue in the switch that does not belong to any links would have to be accounted for separately for the switch.] In section 2, we define additional requirements needed to monitor performance on a cell based level and frame based level for the M4 Network Element View Interface. In section 3, we define additional requirements needed for performance management of the M4 Network View (4). 2 Performance Management for Network Element View 2.1 Cell Level Monitoring Requirements (R1) The M4 interface should support the ability to retrieve current (15 minute) counts of cells discarded due to frame discard for each connection from each ATM interface terminating on the ATM NE. If a cell is dropped by a switch for any reason, the remaining cells in that frame are also dropped by the switch. This is called frame discard. This parameter is required where frame discard is practiced. This parameter keeps a separate count of the total number of ATM cells dropped due to frame discard for each permanent connection and each switched connection. (R2) The M4 interface should support the ability to set threshold values for "Cells discarded due to frame discard" for each connection as given in R1 to one or more interfaces terminating on the ATM NE on which frame discard is applicable. (R3) The M4 interface should allow modification of the threshold values for the "Cells discarded due to frame discard" for each connection as given in R1. (R4) The M4 interface should support autonomous notifications by the ATM NE indicating threshold crossings for the parameter "Cells discarded due to frame discard" for each connection as given in R1. (R5) The M4 interface should provide the ability to reset each count of the performance parameters listed in requirement R1 to zero. (R6) The M4 interface should allow retrieval of history counts (thirty-two 15 minute counts] of the parameters listed in R1. (R7) If the collection of data listed in R1 becomes suspect due to failures, testing routines, and reconfigurations of UNIs, BISSIs, and BICIs, the ATM NE should mark such data as "suspect". It should also be possible to retrieve information regarding whether the counts of parameters in R1 are suspect. [This is already being done for the other counts currently defined in the MIB, for example, (R) PM-11, (R) PM-22 in NE view(2).] 2.2 Frame-Level Monitoring Requirements (R8) The M4 interface should support the ability to retrieve current (15 minute) counts of the following data from each ATM interface (UNI, InterNNI, IntraNNI) terminating on the ATM NE as well as for each VP/VC connection: 1) Frames received on each connection This parameter keeps a separate count of the total number of incoming ATM frames received on each permanent connection and each switched connection. 2) Frames successfully passed on each connection This parameter keeps a count of the number of ATM frames that have been passed (i.e. not discarded) on each permanent and each switched connection. 3) Discarded frames due to UPC/NPC disagreements This parameter keeps a count of the number of ATM frames discarded due to traffic descriptor violations detected by the combined CLP=0 and CLP=1 UPC/NPC policing function. 4) Discarded frames due to congestion This parameter keeps a count of the number of ATM frames discarded due to congestion in the switch. Discard counts are incremented only if the switch implements frame-level discard. 5) Successfully passed frames due to UPC/NPC disagreements This parameter keeps a count of the number of ATM frames that have been passed (i.e. not discarded) by the combined CLP=0 and CLP=1 UPC/NPC policing function. Based on the above five counts, a sixth count Other Discarded Frames can be calculated (see Figure 1) by subtracting UPC/NPC Discarded Frames, Congestion Discarded Frames, and Frames Passed (parameters 3, 4, and 2) from Frames Received (parameter 1). Other Discarded Frames is a count of all frames discarded for any other reason other than parameters 3 and 4. __________________________________________________________________ | | | | | | | Frames ---------------> UPC/NPC Passed ----------------> Frames | | Received | | Frames | | Passed | | | | | | | | V V V V | | | | Other UPC/NPC Congestion Other | | Discarded Discarded Discarded Discarded | | Frames Frames Frames Frames | | | | | |__________________________________________________________________| Figure 1 (R9) The M4 interface should support the ability to set threshold values for parameters 3 and 4 listed in R8 to one or more interfaces terminating on the ATM NE. (R10) The M4 interface should allow modification of the threshold value for parameters 3 and 4 listed in R8. (R11) The M4 interface should support autonomous notifications by the ATM NE indicating threshold crossings for the parameters 3 and 4 listed in R8. (R12) The M4 interface should provide the ability to reset to zero each count of the performance parameters listed in R8. (R13) The M4 interface should allow retrieval of history counts (thirty-two 15 minute counts) of the parameters listed in R8. (R14) If the collection of data listed in R8 becomes suspect due to failures, testing routines, and reconfigurations of VPCs and/or VCCs, the ATM NE should mark such data as "suspect". It should also be possible to retrieve information regarding whether the counts of parameters in R8 are suspect. [This is already being done for the other counts currently defined in the MIB, for example, (R) PM-11, (R) PM-22 in NE view(2).] 3 Performance Management for M4 Network View (R15) The M4 network view interface should support management requests for the performance information (specified in section 2) about the entire subnetwork. The element manager should in turn retrieve this information from the network elements, then aggregate this information and communicate it to the network manager. (R16) The M4 network view interface should support management requests for performance information (specified in section 2) about a specific part of the subnetwork. The subnetwork should in turn retrieve this information from the network elements, aggregate it and communicate it to the network manager. 4 Motion It is moved that the ATM Forum adds section 2 of this contribution to the current M4 Interface Requirements and Logical MIB: ATM Network Element View and section 3 to the current M4 Interface Requirements and Logical MIB: ATM Network View. The portion of the text within square brackets need not be added and has been included in this contribution by way of explanation only. 5 References 1) ATM Forum, ATM Forum Performance Testing Specification, February 1997. 2) ATM Forum, M4 Interface Requirements and Logical MIB: ATM Network Element View, October 1994. 3) J. Kenney, "Open Issues on GFR Frame Discard and Frame Tagging," contribution 97-0385, April 1997. 4) ATM Forum, M4 Interface Requirements and Logical MIB: ATM Network View, March 1996.