****************************************************************** ATM Forum Document Number: ATM Forum/98-0153 ****************************************************************** Title: Frame-Level Performance Management ****************************************************************** Abstract: Counters for cell loss due to frame level discard 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 Juha Heinanen Telia AB Finland Tel: +358 303 994 808 Email: jh@telia.fi The presentation of this contribution at the ATM Forum is sponsored by NASA Lewis Research Center. ****************************************************************** Date: February 1998 ****************************************************************** 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 contribution requests that the MIBs for frame level discards be standardized. This is useful if a frame level service is offered by a switch. Since frame level discard is required for any reasonable TCP/IP performance, most switches implement frame level discard options, such as, early packet discard (EPD). However, currently there is no standard way to determine how many cells were dropped due to frame discard. This particularly important for service providers since cells dropped due to EPD should not be part of normal CLR and should be counted separately. In the July 1997 ATM Forum meeting, a case was made for ATM switches to provide information about frame-level performance [1]. In September 1997 [2], as indicated in the AF-NM meeting minutes for the September meeting, a goal to count Early Packet Discard on a per-VC basis on a selectable number of VCs was agreed to. It was also proposed that the modularity of congestion be moved from the VC-level to the equipment level. In December 1997 meeting, we brought in a contribution to fulfill that agreement [4]. This contribution is a revision of our December contribution and incorporates feedback received in that meeting. In particular, the counter for frames discarded due to UPC/NPC disagreement has been removed. The counters that we propose here apply only to a selectable number of VCs. Section 2.3.6 VP and VC layer performance monitoring of M4 NE View Interface Requirements (BTD-NM-M4NE-REQ-02.06d) already contains a list of three other counts (User Cells, Lost Cells, Misinserted Cells) that apply to a selectable number of VCs. So the goal regarding frame level discards can be attained simply by adding "Cells Dropped due to Frame Level Discard" and "Frames Dropped due to Frame Level Discard" to the list. The following clarifying paragraph should also be appended to the list: "The frame level discard counts apply only when frame-level services are offered and when the frame boundary is visible in the ATM layer as in AAL5. The frame considered here is the AAL5 PDU." Our purpose in adding these two counters to the list is to avoid replicating the eight requirements (PM-49 through PM-55) that currently follow the list and which also apply to the proposed new counters. Motion 1: Add "Cells dropped due to Frame Level Discard" and "Frames dropped due to Frame Level Discard" to the list in Section 2.3.6 along with the above paragraph. The following text requests the addition of the remaining frame-level counters at the interface level. This section is modeled after section 2.3.2 of the M4 NE View Interface Requirements [3]. The requirements have been numbered starting from PM-58 since the previous version of the document ended with PM-57 in Section 2.3.7. 2.3.8 Frame-Level Performance Monitoring Requirements Frame-Level performance monitoring is a measure of the ability of an ATM NE to provide frame-level handling of user data. The frame considered here is the AAL5 PDU. It must be noted that frame-Level performance monitoring can only be implemented where frame-level service is implemented. (O) PM-58 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: 1) Frames Received This parameter keeps a separate count of the total number of incoming ATM frames received. 2) Frames Successfully Passed This parameter keeps a count of the number of ATM frames that have been passed (i.e. not dropped). 3) Frames Dropped due to Congestion This parameter keeps a count of the number of ATM frames dropped due to congestion. Discard counts are incremented only if the switch implements frame level discard. Based on the above three counts, a fourth count Other Dropped Frames can be calculated (see Figure 1) by subtracting Frames Successfully Passed, Frames Dropped due to Congestion, (parameters 2 and 3) from Frames Received (parameter 1). ____________________________________________________ | | | | | | | Frames --------------------------------> Frames | | Received | | Passed | | | | | | V V | | | | Other Frames | | Dropped Dropped | | Frames due to | | Congestion | | | | | | | |____________________________________________________| Figure 1 (O) PM-59 The M4 interface should support the ability to set threshold values for parameter 3 listed in PM-58 to one or more interfaces terminating on the ATM NE. (O) PM-60 The M4 interface should allow modification of the threshold value for parameter 3 listed in PM-58. (O) PM-61 The M4 interface should support autonomous notifications by the ATM NE indicating threshold crossings for parameter 3 in requirement PM-58. (O) PM-62 The M4 interface should provide the ability to reset to zero each count of the performance parameters identified in requirement PM-58. (O) PM-63 The M4 interface should allow retrieval of history counts (thirty-two 15 minute counts) of the performance parameters listed in requirement PM-58. (O) PM-64 If the collection of data identified in requirement PM-58 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 PM-58 are suspect. Motion 2: It is moved that the three frame-level counts and requirements indicated above be added to the M4 NE View Interface requirements as Section 2.3.8 References 1) Suba Varadarajan, Raj Jain, Aditya Sehgal, "Performance Management Requirements of ATM Networks," ATM Forum/97-0610, July 1997. 2) Suba Varadarajan, Raj Jain, Aditya Sehgal, "Frame-Level Performance Management Requirements of ATM Networks," ATM Forum/97-0610r1, September 1997. 3) ATM Forum, "M4 Interface Requirements and Logical MIB: ATM Network Element View," Document Number, BTD-NM-M4NE-REQ-02.06d, December 1997. 4) Suba Varadarajan, Raj Jain, Aditya Sehgal, "Frame-Level Performance Management at the M4 Interface," ATM Forum/97-1090, December 1997.