Management models, like network models, provide a framework within which to think about the purpose and deployment of network management. The first model we’ll discuss is Fault, Configuration, Accounting, Performance, and Security (FCAPS), which is widely used and well understood. The second model we’ll discuss is one we’ve looked at before, in the context of security, the Observe, Orient, Decide, and Act (OODA) loop.
Fault, Configuration, Accounting, Performance, and Security FCAPS was first defined in ISO 10400 in the mid 1980s as a classification system for managing an entire IT infrastructure. It has, since then, been modified through various documents; the most recent version can be found in ITU-T M.3400, which deals with telecommunications network
management. The Enhanced Telecommunications Operations Map (ETOM) has incorporated the ideas behind FCAPS into the Fulfillment, Assurance, and Billing (FAB) model, with each function of FCAPS being mapped to one of the functions of the FAB model.
The focus in this model is on the various functions management provides, rather than on the methods, tools, or processes used to provide that functionality—so although this is a good structure to build a list of “what should I ask,” questions, it isn’t as useful for laying out what and how to measure. FCAPS approaches network management from the business, rather than operational, perspective, which means it can often provide a good
model for interfacing with corporate management.
FCAPS is a fairly straightforward model; what each section measures and manages is implied by the names themselves.
Fault management deals with the detection of faults and
notification of fault conditions to network operators for repair. If corrective action to restore a network to full operation is taken automatically, the FCAPS model still mandates the logging of fault data for future analysis. This area of FCAPS overlaps with the previous section “Decreasing the Mean Time to Repair.”
Configuration management gathers the analysis and modification of device configurations across a broad spectrum of devices into one management console, or one system. Although the ideal solution would be a single device or application managing the configuration of every device in a network, the reality is often multiple configuration management stations with overlapping spans of control. This area of FCAPS overlaps with the previous section “Increasing Mean Time Between Mistakes.”
Accounting is primarily focused on determining how much to bill specific users for specific services provided through the network.
Hence accounting, in a network management system, deals with things like total bandwidth used, peak versus non-peak usage, types of traffic offered to the network, and other measures of network utilization. This section of the FCAPS model is a superset of the previous section “Justifying the Cost of the Network.”
Performance management is focused on determining the current efficiency of the network and projecting the needs of the network in the future. This section of the FCAPS model overlaps with the previous section “Planning.”
Security, in the FCAPS model, is focused on system security, particularly at the level of authorizing individual users to access and use specific services available through the network. Network security tends to be more focused on infrastructure security than the security contained in the FCAPS model. This section of the FCAPS model is closely related to Authorization, Authentication, and Accounting (AAA) services, commonly implemented through RADIUS and other protocols and services.
Observe, Orient, Decide, and Act (OODA)
The OODA loop is described in Chapter 9 in some detail; rather than
examining the history and the theory at a general level, we’ll consider how it can be applied to management here. Rather than focusing on what needs to
be measured or managed, the OODA loop focuses on the management process itself—how does a network administrator determine what needs to be acted on, how to act on it, and what action needs to be taken? The OODA loop is complementary to the FCAPS model previously described—for
example:
In the realm of fault management, the network engineer must first observe the current state of the network (build a network baseline) and the fault (fault notification). After the fault has been observed, orientation is required by troubleshooting the problem and determining the root cause. When the fault has been
diagnosed, the correct form of action must be
determined (decide), and action must be taken to resolve the problem (act).
In the realm of configuration management, the network
engineer observes the configuration, policy, and policy dispersion within the network. Orientation requires the engineer to consider the commonality and differentials between the various policies and the configurations required to effect those policies. To decide, the network engineer must consider which of these policies can and should be gathered up into a centralized system, and how to divide the policies and configurations across a wide array of
equipment into a single unified (and possibly abstract) interface or system. Finally, action must be taken to implement these
decisions by building and/or deploying the appropriate configuration or network management software.
In the realm of network accounting, the network engineer must first observe a set of network capabilities or services, and
then orient to those services by determining what it costs to provide those services. Observation, in this realm, will also be required to determine where and how to measure the usage of the services offered, and orientation will be required to understand the limitations of the measurement, and how that will offset the value of the service as a service. Decide will require the network
engineer, in cooperation with the business, to determine how and what to measure, and how to bill. Act will require the actual
building and billing of the service in question.
In the realm of performance management, the network engineer must observe the normal state of the network, the current state of the network, and the historical differential between the two (or changes over time). Orientation takes place as the network engineer determines whether current differentials are likely to continue into the future by examining why these differentials are occurring and whether the conditions causing the differentials will continue.Orientation will also involve examining the business environment for incipient changes and other issues that may impact the performance of the network or applications running on the network—such as a new application being deployed. The network engineer must decide what to do about the difference
between the current performance, the ideal performance, and projected future changes to performance, and finally act by implementing the necessary changes to maintain network performance at some predetermined level.
The OODA loop can be used across a wider cross-section of the different processes within each area of the FCAPs model; these are just examples.
An interesting application of the OODA loop in network management is
change management. A fairly standard change management process includes the following steps:
Step 1. Define the requirement.
Step 2. Request the change.
Step 3. Review the change.
a. Examine the costs and benefits.
b. Examine the technical feasibility.
c. Analyze the impact of the change on existing systems.
Step 4. Plan the change.
Step 5. Execute the change.
Step 6. Review the change.
a. Verify change operation.
b. Verity change impacts.
Steps 1 and 2 in this process are observe; step 3 is orient; step 4 is decide;
step 5 is act; and step 6 returns to observe. Rephrasing the process in terms of an OODA loop may help clarify the steps involved in change management, including answering the question, “Why are we doing this?”