Service-level management in a switched network - RMON2 standard is inadequate - Special Focus: Network Management - Technology Information - Cover Story

Communications News, Sept, 1997 by Paul Farr

Caution: Reduced visibility ahead! The migration from routed to switched networks has reduce your visibility of networked application response time and with it, your ability to assess and report end-user service levels.

Service level management requires a 7x24 source of application performance data that can detect application outages and directly measure end-to-end application response time down to the desktop.

To maintain optimum service levels, this key measure of the client experience must be correlated with existing network management functions such as capacity planning, network troubleshooting, and policy management to ensure that the network is meeting the business goals of the organization.

IS RMON2 THE ANSWER?

Many users assume that the application monitoring features of RMON2 will provide the data required to drive service level management monitoring and reporting. This assumption is incorrect whether the RMON2 is embedded in switches or in external probes. Here's why:

* The RMON2 standard does not provide any application-level client request and server reply matching to calculate application response times. RMON2's primary strength is providing monitoring and capacity planning data for measuring segment-level utilization and trending application traffic patterns.

* The processor and memory requirements for the added functionality of RMON2 will exceed the capabilities of the instrumentation deployed, causing either measurement inaccuracy or degradation of device performance.

However, RMON2 is a valuable source of data which can be used to help you understand some of the reasons why applications are not meeting service levels. it is a key part of the overall solution to provide optimum service levels to your users.

IF NOT RMON2, THEN WHAT?

There are other sources of data which measure application response times: * Network analyzers * Server instrumentation * End-node (client) instrumentation

Server analyzers can measure application response time within the server, but do not take into account network latency and are not able to detect most client-side application failures. Because of the problems that can occur between client and server in larger networks, it is imperative that service levels be based on the total round-trip time for application-level transactions.

Network analyzers can be placed anywhere between the client and the server and do an excellent job of measuring response time. They are absolutely required to isolate the cause of application and network problems, but may not be a cost-effective solution for 7x24 reporting coverage of your switched LAN.

End-node instrumentation can provide a consistent measure of end-to-end response time and is independent of the network architecture. However, it must be augmented with on-demand tools, such as network and server analyzers, which can be used to isolate and diagnose the problem once identified.

Finally, there's another source of data: router and switch configuration files, which control the policies for security and access to the network that connects the clients and servers. They cannot directly measure client service levels, but can cause application availability problems if not configured properly.

TYING IT ALL TOGETHER

The table shows that by augmenting today's deployed network instrumentation (SNMP MIBs, RMON, RMON2, and network analyzers) with end node response time monitoring instrumentation, network managers can have the visibility they need in switched LANs to both report and maintain optimum service levels.

Finally, by correlating service-level data with established network management functions such as capacity planning, network troubleshooting, proactive network analysis, and policy management, the manager can ensure that the network is meeting the business goals of the organization.