ATM Remote Monitoring:

i. ATM-RMON is the remote monitoring standard created for ATM networks. ATM network is more recent technology and its connection oriented feature requires a different set of standards to be developed.

ii. ATM-RMON is developed by the ATM forum. It is the equivalent of RMON and RMON2 developed by IETF.

iii. ATM-RMON is designed based on RMON because of several reasons. First, it is compatible with RMON so that existing RMON applications can run on ATM and reduces the cost of developing new monitoring applications.

iv. Second, many protocols currently monitored by RMON are emulated over ATM, and RMON is already used to monitor those data.

v. Third, RMON2 has been added to upgrade RMON and ATM should anticipate compatibility issues with RMON2.

RMON MIB:

i. There is a similarity in the use of remote probes for RMON on an ATM network. RMON and its advantages for gathering statistics on Ethernet and token-ring LANs.

ii. RMON 1 dealt with the data link layer and RMON2 with higher-level layers. IETF RMON MIBs have been extended to perform traffic monitoring and analysis for ATM networks

iii. Figure3 shows an RMON MIB framework for the extensions, as portrayed by the ATM Forum. Switch extensions for RMON and ATM RMON define RMON objects at the "base" layer, which is the ATM sub layer level.

iv. ATM protocol IDs for RMON: define additional objects needed at the higher-level layers.

Diagram of RMON MIB

v. There are several differences between RMON of Ethernet and token ring and monitoring of ATM devices.

vi. Extending RMON to ATM requires design changes and new functionality. Particular attention needs to be paid to the following issues: high speed, cell vs. frames.

vii. Remote Monitoring Provide an automated means to monitor and manage ATM network Communicate important messages that may indicate the tampering with a machine Provides improved ATM availability and reduces risk Quick identification of problem – remotely and centrally.

viii. There are several issues being addressed since the beginning of ATM-RMON's development. First, it must provide compatible functions with existing RMON.

ix. Second, new functions specific for ATM networks are added. Third, data collection from source is taken into account.

x. Fourth, resource allocation should be flexible. Fifth, data reduction mechanism is incorporated. These issues are addressed in order to make ATM-RMON a more powerful and yet compatible network monitoring standard.

xi. As a result, the basic MIB for ATM-RMON is created and it is called ATOM MIB.

xii. One difference between ATM-RMON and RMON is that ATM-RMON does not implement the hostTopN function and instead, a matrixTopN is implemented.

xiii. The matrixTopN is a collection of hostTopN in a table. Thus ATM-RMON is more complex in this function.

xiv. Another difference between ATM-RMON and RMON is that ATM-RMON does not use data source index to identify data source. Instead, it uses global tables to define circuit selection groups.

xv. Even though ATM-RMON is based on RMON, it has incorporated many new features in RMON2 to stay compatible in the future. For example, it has included new TopN functions such as 'last-create-time’ counters are used instead of table size; and Protocol Directory selects which protocol to monitor is also included.

xvi. ATM-RMON has added basic statistics non-existent in RMON to monitoring ATM specific statistics such as cells-sent count, cells-received count, number of successful call setups, number of attempted call setups, and total connection time.

xvii. ATM-RMON has just been standardized. There are still many insufficiencies in this version.

xviii. First, ATM network is designed to carry data traffic, voice, video and other traffic. But only frame-base traffic is monitored by ATM-RMON.

xix. Second, no cell filter nor capture group is specified in ATM-RMON. This is a design decision to hurry the standardization of ATM-RMON. No standard exists for monitoring cells.

xx. Thus monitoring guideline has been suggested to vendors and let the vendors to choose which way to implement. This will allow future standardization easier.

xxi. There are two options which can vary. The RMON device can be either internal or external. Also, it can allow copy function to copy traffic to another port or disallow it. By the combination of these two options, four methods are suggested to vendors for implementation.

xxii. The ATM RMON agent can report cell traffic statistics by monitoring connection management activity.

xxiii. At connection setup and release time, some ATM-RMON bookkeeping code is executed. The amount of information varies, depending on the ATM RMON configuration.

xxiv. The ATM-RMON counter uses the per-VC counters already maintained in the hardware and polled by the software.

xxv. The ATM RMON provides high-level per-host and per-conversation statistics in a standards-track MIB.

xxvi. The ATM RMON feature allows you to monitor network traffic for

1. Fault monitoring or 2. Capacity planning

xxvii. The ATM-RMON agent uses the 64-bit version of each cell counter, if 64-bit counter support is present in the SNMP master- agent library.