****************************************************************** ATM Forum Document Number: ATM Forum/97-1090 ****************************************************************** Title: Frame-Level Performance Management at the M4 Interface ****************************************************************** Abstract: As directed in the September meeting, frame-level counters proposed earlier at the VC level have been moved to the equipment level. Also, again as directed, the EPD counters have been defined to be implemented for a selectable number of VCs. ****************************************************************** 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 The presentation of this contribution at the ATM Forum is sponsored by NASA Lewis Research Center. ****************************************************************** Date: December, 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. ****************************************************************** In the July 1997 and September 1997 ATM Forum meetings, we made a case for ATM switches to provide information about frame-level performance [1,2]. We had requested six optional counters: Number of Cells Dropped due to EPD, Frames received on each connection, Frames successfully passed on each connection, Frames dropped due to UPC and NPC disagreements, Frames successfully passed due to UPC and NPC disagreements, and Frames dropped due to congestion. 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. We were asked to bring a contribution to that effect in December. This contribution fulfills that request. We noticed that Section 2.3.6 VP and VC layer performance monitoring of M4 NE View Interface Requirements (BTD-NM-M4NE-REQ-02.05d) 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 EPD can be attained simply by adding "Cells Dropped due to Early Packet Discard" and "Frames Dropped due to Early Packet Discard" to the list. The following clarifying paragraph should also be appended to the list: "The EPD 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 Early Packet Discard" and "Frames dropped due to Early Packet 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. 4) Frames Dropped due to UPC/NPC disagreement This parameter keeps a count of the number of ATM frames dropped due to traffic descriptor violations detected by the combined CLP=0 and CLP=1 UPC/NPC policing function. Based on the above four counts, a fifth count Other Dropped Frames can be calculated (see Figure 1) by subtracting Frames Successfully Passed, Frames Dropped due to Congestion, and Frames Dropped due to UPC/NPC Disagreement (parameters 2, 3, and 4) from Frames Received (parameter 1). ____________________________________________________________ | | | | | | | Frames ----------------------------------------> Frames | | Received | | | Passed | | | | | | | V V V | | | | Other Frames Frames | | Dropped Dropped Dropped | | Frames due to due to | | Congestion UPC/NPC | | Disagreement | | | | | |____________________________________________________________| Figure 1 (O) PM-59 The M4 interface should support the ability to set threshold values for parameters 3 and 4 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 parameters 3 and 4 listed in PM-58. (O) PM-61 The M4 interface should support autonomous notifications by the ATM NE indicating threshold crossings for parameters 3 and 4 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 four 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.05d, September 1997.