Chapter 3. Accounting and Performance Standards and Definitions

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.