FCAPS: A Model For VOIP/IPT Management

By Audin, Gary; Lodge, Fiona

Correctly handling five key management elements can make converged voice systems run more smoothly.

Managing IT and telecom resources can be like fixing a home. The more you take apart, the more work you see that has to be accomplished. The demolition people don’t fix the plumbing, heating or electrical work. Others are needed for finishing the walls and painting. You really should have a general contactor to oversee and manage the project.

The same is true for the IT organization whose data network, with desktops and servers, will also be used to carry voice traffic (VOIP/ IP-telephony). There should be a general contractor/supervisor that covers all the management functions.

There is such a general contractor-or at least a concept for such a general contractor to follow-and it is called the FCAPS model. Fault, Configuration, Accounting, Performance and Security are all part of the management responsibilities. FCAPS can be implemented in one or more tools that are available on the market today. Following the FCAPS model moves management from the reactive to the proactive state.

Managing VOIP/IPT Resources

There is a difference between IP network management and IP- telephony (IPT) management. Most data network managers are concerned about the status and configuration of their network. The data network is a transportation system that traditionally does not know or care about the applications that use the network.

Data network management is also separate from server or desktop management. Performance and accounting management, oriented toward the server or desktop, have not been part of the data network manager’s responsibilities. Finally, network security is part of the network manager’s responsibility-but not endpoint, desktop and server security.

Managing an application is not the same as managing the network. Application performance is dependent on the network’s performance. Because VOIP/IPT is an application, not a network, it has its own set of unique problems that are affected by the behavior of the network, users and applications that are running concurrently with IPT.

IP-telephony problems manifest themselves in two ways:

* Performance-affecting user satisfaction factors (voice quality, reliability, etc.).

* Opex budget impacts for the network itself and the management systems and staff.

FCAPS: The Standard Model

FCAPS is a model, not a product, developed by the International Telecommunications Union (ITU). The fundamental idea is straightforward. FCAPS categorizes the numerous pieces of information about the health and operation of a network and its associated devices into five key areas that can be applied to the management of enterprise networks. The five areas are:

* Fault Management (FM)-Fault management is the collection and analysis of alarms and faults in the network. These faults can be either transient or persistent.

Transient conditions (packet loss and erroneous packets) do not need to be alarmed (i.e., do not need to trigger an alarm report to the network manager) if they do not exceed a threshold. These events do, however, have to be logged. The network administrator can correct device and resource faults.

Other transient problems can be automatically corrected at the device level without any administrator intervention. Faults can be determined from unsolicited alarm messages or by polling devices. In either case, the FM function analyzes and filters the fault messages and coordinates the messages so that the number of actual events reflects the real conditions of the devices. The root cause should be reported, while suppressing other related fault messages.

FM merges with the trouble ticket system for issuing repair orders. In VOIP/IPT systems, FM will include servers, gateways, IP phones and softphones, in addition to the network devices.

* Configuration Management (CM)-Configuration management provides the location, setup, inventory and maintenance of network component (hardware and software) configurations. Information on the managed resources is collected regularly, tracking the types of resources and their details. When changes occur, the CM can collect the changes by using unsolicited messages such as traps.

CM is used to standardize the activation and deactivation of resources in a regulated and controlled manner. CM also includes change management to keep track of modifications to the network and its resources. In VOIP/IPT systems, this will include servers, gateways, IP phones and softphones.

* Accounting Management (AM)-Accounting management collects information and prepares reports and analysis on usage, billing, invoicing and other parameters that must be tracked. AM is used to inform the relevant authorities and users about the consumption of resources. When the resources approach their capacity, corrective action will need to be taken to limit usage, thus preventing a pre- set threshold from being exceeded. The cost of resource usage can also be collected, such as VOIP calls going through the gateway to the PSTN. Examples in VOIP would be traffic information, user billing for calls and voice mailbox capacity and utilization.

* Performance Management (PM)-Performance management measures and analyzes network and application performance. PM collects resource performance statistics and evaluates the statistics under normal and abnormal conditions. PM alerts the administrator to conditions that exceed performance thresholds. PM also performs trend analysis to predict and anticipate performance problems.

The statistics for data network operation are expanded for VOIP/ IPT, and PM becomes much more critical when supporting real-time applications such as voice and video. How quickly a dial tone is provided, whether the voice quality is acceptable, and how often the user encounters a busy signal are examples of the expanded nature of PM when VOIP/IPT services are added to the data network.

* Security Management (SM)-Security Management provides network and application level security to control access and utilization. SM is designed to protect the resources and prevent malicious, negligent and abusive behavior by those within, as well as outside, the enterprise.

SM ensures the legitimate use of the resources, maintains privacy, confidentiality and information integrity while performing an auditing function. SM must use access codes, recordings, personal records and call logs to identify, mitigate and manage security problems such as snooping, hijacking and illegal recording of IPT sessions. Enabling and disabling access rights are also the responsibility of SM.

In VOIP/IPT, SM will look for rogue phones, illegitimate tampering with the feature usage, unauthorized PSTN traffic and eavesdropping. The original concept for SM has expanded with the growth in security problems and the advent of auditing legislation and regulations such as HIPAA and Sarbanes-Oxley.

FCAPS Business Value

In practice, some elements of the FCAPS model have been implemented more widely than others in coordinated management schemes. Generally, enterprises apply FCAPS to fault and configuration issues. The security function has depended on other tools that are not integrated into the overall FCAPS model.

This is unfortunate, because fault, configuration and performance problems may actually be a security problem in disguise. Likewise, unusual traffic patterns captured by accounting management may indicate a security problem.

The bottom line is that, although there are five elements to FCAPS, one element can influence the success of another element.

The business values of employing FCAPS are:

* Increased productivity for the IT and telecom staffs.

* The ability to manage more remote resources with little or no on-site IT staff.

* Greater user satisfaction with voice services.

* The ability to predict, and therefore prevent, performance problems.

* Potential reduction in trouble tickets returned because of faulty referral to the incorrect problem solver.

* Improved visibility into all the network resources.

* Discovery of underutilized resources that can be reduced or eliminated, resulting in cost reduction.

* Determining what resources are over-utilized and modifying their operation before users complain about the resource performance.

FCAPS In The VOIP/IPT Enterprise

When does FCAPS apply? How large does the number of endpoints have to be-hundreds? thousands?-to use the FCAPS model effectively in the enterprise?

FCAPS may seem to be overkill for the small enterprise. The small enterprise budget may not be able to afford a series of management tools that fully supports FCAPS. However, the FCAPS model does provide a checklist of functions that apply to small enterprises. The model can be used as an analysis tool to evaluate the responsibilities inherent in VOIP/IPT management for the smaller enterprise IT organization.

Once an enterprise has remote locations and/or hundreds of endpoints to manage, then FCAPS becomes a useful and pragmatic approach to accomplishing and satisfying the responsibilities for management. Organizations such as banks and retail chains with many remote locations; financial institutions that depend on reliable and stable services; distributed manufacturing and warehouse sites; a\nd multiple government agency sites are all candidates for implementing the FCAPS model.

The FCAPS model covers a range of capabilities (Table 1). The enterprise’s management team can use the FCAPS model as a checklist to determine what the existing and owned management tools can accomplish. The model can be used to determine what gaps remain in the management products already being used by the enterprise.

One example of a process enhanced by FCAPS is discovering and locating rogue IP and softphones. IP phones register to a call server and not a data server, and there is the possibility of illegitimate phones operating on the network.

TABLE 1 FCAPS Elements Defined

Public area IP phones, like lobby phones, can be disconnected at the LAN wall socket/outlet for unauthorized data network access, or the extra Ethernet port on the phone can be used for unauthorized access to the data network. There are also public access phones in training rooms, conference rooms, halls, cafeterias and kitchens that are vulnerable access points. There are phones near the outside entrances to the building that can be used to gain access to the building by calling the security personnel after work hours. These public area and outside phones are another location for VOIP network vulnerability, if an IP phone is located there.

Too many extra (illegitimate) phones can affect the voice quality of the VOIP calls of the legal phones and may even affect data application performance. Another security vulnerability example is the PSTN gateway. If it is not configured properly, then access may be limited and calls blocked to and from the PSTN. Toll fraud through the PSTN gateway is a security and accounting issue that may be created by configuration changes in the PSTN gateway or call manager server.

These examples show how security issues are intertwined with (at a minimum) configuration, accounting and performance management. Clearly, an overall FCAPS approach fits this problem well.

Where Does FCAPS FK?

FCAPS is applicable throughout the life cycle of a VOIP/IPT implementation. Do not assume that the FCAPS model will only be valuable after the VOIP/IPT systems and endpoints are operational. FCAPS is applicable during all four stages of the lifecycle: Planning, design, deployment and operation.

The tools that support FCAPS can be used to make an assessment of the data network, inventory the components and measure its operation and performance before the final decision is made to move to VOIP/ IPT. During the planning and design phase of the life cycle, the tools can be used to determine what changes, additions and modifications need to be implemented for the successful deployment of VOIP/IPT in the enterprise.

The FCAPS tools will be very useful during the implementation of VOIP, by ensuring that the components are installed in the correct location with the proper configuration of hardware, software, features and functions, thereby shortening the provisioning time for the project.

When the VOIP/IPT network is in operation, the tools become a daily part of the management team’s information. The tools will also be necessary when adding, deleting and moving endpoints, monitoring application installations, overseeing feature and traffic usage and for performance prediction.

The benefits of applying FCAPS management tools are:

* Reduce implementation costs.

* Reduce labor and staff size for the implementation.

* Better control of the component inventory.

* Shorter implementation schedules.

* Greater user satisfaction.

* Fewer help desk calls and trouble tickets.

* Faster location of performance problems.

* Feedback on the effectiveness of the design.

* The ability to manage more remote resources with the existing staff.

* Simplification of network operation center (NOC) procedure.

* Elimination of staff responsibility, overlap and competition.

* Optimization of resources, especially band-width and quality of service (QOS), on the WAN.

Conclusion

FCAPS is a series of principles that affects the network and application performance in its broadest sense. Enterprises should look for solutions that address and optimize multimedia and standards-based environments. Particular attention should be paid to maintaining performance standards across multiple networks, such as teleworkers communicating over the Internet to the enterprise network

IBM Global Services And FCAPS

For a real-world view of FCAPS in VOIP/IPT deployments, we turned to Dave Radcliffe, IPT/VOIP service manager of global IP-telephony services for IBM Integrated Technology Delivery. Dave said the IBM approach to supporting internal users and their enterprise customers closely follows the FCAPS model. He was interviewed by this author about IBM’s use of the FCAPS model.

GA: How did you decide that the FCAPS model would work for IBM?

DR: The FCAPS model brought to the surface a support solution already in existence; we just didn’t have a name for it, other than our DOM-Delivery Operational Model. Each of our Delivery “towers” already supported the individual layers of the voice and data environments. But, as form follows function, not until we converged the support towers to meet the technology did we recognize how our design matched the FCAPS model. It also identified where we had some gaps and overlaps between voice and data management.

GA: What did you use as a reference for the model?

DR: The model contents actually came from network services competency projects we initiated-not regarding VOIP or IPT, but in redefining how we delivered our standard commercial and internal voice services. These projects included collecting metrics, identifying best practices, maintaining industry knowledge, tools evaluations, centralizing services and identifying remote managed services. The project was to build a new delivery model for VOIP.

We didn’t have a reference model. We built our model from the ground up, by breaking our services into cost drivers, and then into work-products (about 200 work-products were defined). Our model was derived from a detailed evaluation of each of our deliverables, through the filtering of a dozen or more support requirements for each one and identifying the commonalties across the converged layers.

GA: How did you sell the FCAPS model to IBM?

DR: Voice applications now reside on PBXs, which are actually open systems server platforms, with a standard OS (at least in theory) versus the traditional proprietary electronic switching devices installed in damp dungeons and basements our voice resources know all so well. It was an easy sell in obtaining buy-in from the Server support tower. We didn’t ask them to perform anything outside of their existing responsibilities.

The other Delivery towers were just as easy to work with. End User Services already supported desktop PCs and printers. The IP phones became just another IP-addressable desktop endpoint, no change there. The Data Infrastructure tower, although now used for voice, has been supported by our NOCs (network operations centers) for years, no change there-except the addition of QOS. The Network Devices tower, even though now also used by voice services, are still standard switches and routers. No change for this team either.

GA: What were the benefits and resistance to the use of the FCAPS model?

DR: The benefits were clear. There was synergy between towers to converge our support model to meet the VOIP technology. The voice team still owns the voice applications. Those requirements don’t go away or change in the converged environment.

The resistance, however, came in the way the Voice towers had to give up responsibilities and therefore give up budget revenue to other towers to make this work. The phones now belong to End User Services; the PBX hardware now belongs to the Server team; the infrastructure now belongs to Network Operations. The network devices now typically belong to the LAN team.

The “What” does not change in the deliverables or work-products, just because voice packets now traverse the data network. It’s the “Who” that changes, in who now performs those services. [And] the dollars must follow the resources.

GA: IBM’s managed services include many elements/ responsibilities covered by the service agreement. What elements were and were not covered by the FCAPS model?

DR: We labeled our converged environment with five distinct layers:

* Infrastructure (LAN, WAN, wireless)

* Servers (PBX, ACD, voice mail, DNS)

* Network Components (routers, switches, gateways)

* IP Endpoints (IP phones, softphones, wireless, PDAs)

* Applications (Voice, Voice mail, CTI, Directories, 911)

Each of these layers requires Fault, Configuration, Accounting, Performance and Security management. The PBX voice application may reside on an EBM Server, for example. Our Server team monitors it for any alerts (Fault Management). It is also monitored for any shortage of disk space (Configuration Management). Licensing and version control is monitored (Accounting Management). Excessive CPU utilization is reported (Performance Management). Login attempts and passwords are monitored (Security Management).

The other layers of the end-to-end environment follow the same pattern: The WAN/LAN, the Network Devices, the

IP endpoints, and the Voice applications all conform to the FCAPS management model.

We did encounter other gaps and overlaps as well, primarily in the monitoring arena. We did not want to monitor the same devices by three distinct entities. Without the proper tools, the up/down monitoring capability by basic data tools does nothing for security breaches monitored by the firewall team. The data tool also won’t discover a memory leak monitored by the server team, which also won’t alert about a failed backup process monitored by the backup team. We may have three or more remote resources monitoring a single device, which increases the cost of supporting that product. This example is why the t\ools play such an important part of the FCAPS model, along with finding efficient tools that execute across layers and across management requirements

FCAPS elements are often Interrelated. For example, configuration or performance problems may be a security problem In disguise

FCAPS is applicable during planning, design, deployment and operation of the system

FCAPS can help maintain performance standards across diverse networks

Gary Audin and Dr. Fiona Lodge

Gary Audin has more than 40 years of networking experience. He writes for BCR, speaks at VoiceCon and blogs at www.voiploop.com. Fiona Lodge is product manager for Prognosis and can be reached at fiona.lodge@ pmgnosis.com.

Copyright CMP Media LLC Dec 2006

(c) 2006 Business Communications Review. Provided by ProQuest Information and Learning. All rights Reserved.