This chapter describes architectures, standards
definitions, and protocols related to performance and accounting.
Starting with the big picture, this chapter drills down into definitions
and specifications for data collection, data representation, and
service notions. This chapter is also an overview of the different
standards bodies and architectures, along with the concepts and
principles of each protocol. This chapter also includes references for
further investigation.
Instead of following the "classic" book structure of
defining all standards in an introductory chapter, we decided to start
by defining the requirements, followed by the collection methodology.
With the use cases in mind, this is the right moment to introduce
standards. The question "Why are standards required?" leads toward two
answers:
- If you operate a single-vendor equipment environment, you might not see a big need for standards, because products are expected to interoperate as long as you stay with the same vendor. Interoperability between different products or versions from one vendor (such as a Cisco IOS version) is still an important requirement.
- In a multivendor environment, you expect vendors to agree on at least a minimum common denominator for functionality, which is what standards provide.
Which approach is better? Probably both have their
pros and cons; the answer mainly depends on your business requirements.
If you change your perspective slightly, the need for standards becomes
evident. For example, suppose you travel abroad and rent a car. You
expect the traffic rules to be similar to those in your home country.
Cars might drive on the "wrong" side of the road, but you expect a red
traffic light to mean "stop" and a green one to mean "go." If you stay
in a hotel on your trip, you expect warm water to be associated with a
red symbol, while blue stands for cold water. What is the conclusion?
Standards are helpful to provide a kind of "lingua franca" to ensure
that participants talk about the same subject.
Data normalization is another benefit of a standard.
Suppose you ask two people what the temperature is. One says 68, and the
other says 20. Who is right? Both are correct if the first person means
Fahrenheit and the second person means Celsius. The same applies to
metering data from network elements. Unless all devices apply the same
measurement and report the same information with the same unit,
normalization is required to turn raw data into information. For
example, in a networking scenario, an ISP offers SLAs to an enterprise
customer, and both parties measure the service with different tools. In
the worst case, the results are completely different, leading to
finger-pointing and misapprehension. As another example, two service
providers collect accounting data for a peering agreement but use
accounting measurement techniques that collect records with different
data units. At the end of the month, different collection results lead
to misapprehension. Data normalization can help address these issues.
For this book, the authors applied the following
definition of a standard: "Obtaining common information across multiple
network elements by using common terminology, protocols, and measurement
units rather than each network element using its own syntax and
reporting scheme."
Bridging the gap to network management, one person
might interpret "management" to mean device monitoring, and someone else
might consider "management" to mean the active part of modifying device
configuration. When selecting the required Network Management System
(NMS) applications, operators are sometimes overwhelmed by the
functionality offered by applications. When asked what they are looking
for, the answer might be "Just something to manage my complete network."
In these cases, a helpful approach is to step back and ask, "Which
functionality is required?", "Which devices need to be managed?", "Which
services are planned?", and more. Afterwards, the answers can be mapped
to a standard model, such as Fault, Configuration, Accounting,
Performance, and Security (FCAPS)—as introduced in Chapter 1,
"Understanding the Need for Accounting and Performance Management"—to
categorize and prioritize the required functionality. As a last step,
potential NMS applications are also mapped against the selected model,
such as the Telecommunications Management Network (TMN) FCAPS model or
the TMF eTOM model, to identify which product addresses which
requirements.
Two types of standards need to be clearly distinguished:
- A de facto industry standard
- A formally committed standard from an official standards organization
When the majority of users or vendors accept and
implement the same technical specification defined outside a standards
body, it becomes a de facto standard. An example is IBM's Systems
Networking Architecture (SNA), which originally defined networking only
for IBM devices but was also implemented by other vendors. Formal
standards are defined by global, regional, or national standards bodies.
The International Telecommunications Union (ITU) is an international
organization within the United Nations System where governments and the
private sector coordinate global telecom networks and services. The ITU
Telecommunication Standardization Sector (ITU-T) was created on March 1,
1993, replacing the former International Telegraph and Telephone
Consultative Committee (CCITT), which originated in 1865.
In addition to the formal standard definitions and
vendor de facto standards, specifications are defined by consortia. If a
consortium's proposal is widely accepted, it becomes a de facto
standard. These consortia are groups where different vendors (and
sometimes also large customers, service providers, system integrators,
and others) agree on a common definition and implement it afterwards.
Examples are the TeleManagement Forum (TMF), the World Wide Web
Consortium (W3C), Internet Protocol Detail Record (IPDR), Distributed
Management Task Force (DMTF), and others. In all these cases,
interoperability is gained if different vendors implement the same
specification.
If you investigate a little further into standards
organizations, you will realize the variety of standards organizations,
some of which have overlapping focus areas and competing standards
definitions. Why are there so many standards? This is not a simple
question to answer; multiple answers are possible. One reason for the
existence of different standards organizations is history. After the
CCITT defined interoperability standards for Post, Telephone, and
Telegraph (PTT) organizations, a need for Internet standards evolved,
and the Internet Engineering Task Force (IETF) was founded. To meet the
need for enterprise management standards, the DMTF was founded. The
emerging web technologies required common standards, so the W3C was set
up. Another reason for diversity is political discussions and
disagreements within groups. Sometimes it is easier to define a new
standard than to come to an agreement across the industry. Introducing
competition by founding a new standards group can also increase the pace
of another group.
With several different standards groups and
organizations in place and a multitude of standards, the next question
is how to identify the "right" standard. This requires defining the
perspective first: a customer's request, a system integrator's offering,
or a vendor's implementation? From an end-user perspective, a simple
approach is to select the standard that you like the most; however,
there might be better selection criteria.
Best practice suggests starting with the
requirements. Why are you looking for standards that provide
interoperability in a multivendor environment? Do you want investment
protection to replace one vendor's network element with another
vendor's? In this case, your management software also needs to support
multiple vendors' equipment. Are you looking for operational
transparency, which means you want the same management and reporting
functionalities across vendors? This requires device instrumentation to
be standardized. How do you integrate different management applications?
If they use standard application programming interfaces (API),
integration takes less effort than different APIs for each application.
In summary, selecting the "right" standard depends on various criteria:
- Business requirements
- Single-vendor or multivendor strategy
- Device instrumentation
- Application interoperability
- Technical feasibility—identifying if implementing a function is technically achievable
- Common sense—requesting a standard just for the heck of it is not a wise decision
Taking a top-down approach to accounting and
performance management, mainly two specifications are relevant to the
big picture: the ITU-T TMN/FCAPS model and the TMF eTOM definition.
Information modeling also has two groups: the DMTF
and TMF with their information model definitions of the Common
Information Model (CIM; DMTF) and Shared Information/Data (SID; TMF).
From a protocol perspective the two relevant standards bodies are the
IETF (SNMP, AAA, IPFIX, PSAMP, and others) and the ITU (CMIP/CMISE and
GDMO). These protocols are discussed later.
A top-down approach to accounting and performance
management includes three components, which are discussed in detail in
subsequent chapters:
- Framework/architecture:
- - The ITU with the TMN/FCAPS model.
- - The TMF with the definition of eTOM. Note that ITU-T M.3050 recommends eTOM as well.
- Information modeling:
- - The DMTF with CIM.
- - The TMF with SID.
- Protocols:
- - The IETF with SNMP, AAA, IPFIX, PSAMP, and others.
- - The ITU with CMIP/CMISE and GDMO.
