Network Management Systems

Transcription

NETWORK
MANAGEMENT
MATTI PUSKA
ESPOO-VANTAA
INSTITUTE OF TECHNOLOGY
2005-2006
SYSTEMS
ESPOO–VANTAA INSTITUTE OF TECHNOLOGY
Network Management Systems - Table of Contents
Network Diagram Symbols
iii
1 Network Management Significance and Tasks
1.1 Significance of Network Management
1.2 Network Management Functional Areas and Layers
1.3 Network Management Systems
1.4 Summary
5
5
8
11
14
2 Network Management Components
2.1 NMS Elements
2.2 NMS Protocols
2.3 Summary
16
16
17
19
3 TCP/IP Network Management
3.1 Simple Network Management Protocol Versions
20
20
3.1.1 SNMP v.1
3.1.2 SNMP v.2c
3.1.3 SNMP v.3
20
23
26
3.2 SNMP Data Model: Management Information Base
3.3 Device Management Systems
3.4 Remote Monitoring
3.4.1 System Components
3.4.2 Proactive Monitoring
3.4.3 Reactive Measurements
3.4.4 Interpreting Monitoring Results
3.5 System Management
3.6 Summary
4 OSI Network Management
4.1 Telecommunications Management Network
4.1.1 NMS Environment and Management Tasks
4.1.2 The TMN Framework
4.2 CMIS and CMIP
4.2.1 CMIS Services and CMIP Messages
4.2.2 TMN Protocol Stack
4.3 TMN Data Model
4.4 Management Systems for Telecommunication Networks
4.4.1 Public Telecommunication Networks
4.4.2 Private Corporate Networks
4.4.3 Example Products
4.5 Summary
VANHA MAANTIE 6
02650 ESPOO
[email protected]
29
34
39
39
42
43
44
51
53
56
56
56
59
61
61
62
64
67
67
71
71
73
NETWORK MANAGEMENT SYSTEMS
TABLE OF CONTENTS
i
MATTI PUSKA
5 Distributed Management Task Force
5.1 General
5.2 Web Based Enterprise Management
5.3 Directory Enabled Network Initiative
76
76
77
81
5.3.1 DEN Motivation and Overview
5.3.2 DEN Schema
5.3.3 Directories
81
82
83
5.4 Desktop Management Initiative
5.5 Common Information Model
85
87
5.5.1 Overview
5.5.2 Classes, Properties and Methods
5.5.3 Aggregations and Associations
5.5.4 Common Models
5.5.5 Extensions
5.6 Summary
87
87
88
89
90
92
6 List of Acronyms
95
Appendices
A Protocol Data Units
B ASN.1 Basic Encoding Rules
100
100
104
List of References
108
VANHA MAANTIE 6
02650 ESPOO
[email protected]
TABLE OF CONTENTS
ii
MATTI PUSKA
Network Diagram Symbols
Hub
ATM
Switch
Router
LAN
Switch
LAN
Hub
Uplink
HLR VLR AC
EIR
Downlink
Base
Transmitter
Station
Base
Station
Controller
Mobile
Switching
Center
Operations &
Maintenance
Center
Telephone
Exhange
Telephone
Set
Mobile
System
Cellular
Network
DB
Server
Workstation
Ethernet
Local Area Network
VANHA MAANTIE 6
02650 ESPOO
[email protected]
Network
Management
Station
Hard
Disk
Network
NETWORK DIAGRAM SYMBOLS
Database
User
iii
MATTI PUSKA
1
Network Management
Significance and Tasks
This chapter covers:
• Financial and technical significance of
Network Management
• Different Functional Areas and Functional
Layers on Network Management
• Device management, system management
and remote monitoring
1.1 Significance of Network Management
Traditionally Telecommunication Networks are run by network operators
(teleoperators), that provide voice and data services to their customers. The operator
builds and runs the basic network and uses the capacity for telephone, mobile and data
networks and for various value added services. Customers can often buy service from
many sources (Finnet, Elisa Communication, TeliaSonera, Saunalahti, Song Networks,
foreign carriers...) based on the pricing, service and personal preferences. The basic
network is an enourmously complex system, consisting of the infrastructure (local loops,
trunks, links), transmission and switching systems. On top of the basic network the
operators build and run telephone, cellular and data networks to provide sophisticated
services.
Computer networks used to be separate data networks. Local Area Networks connect
workstations, peripherals and servers on a building, and Wide Area Networks are used
to interconnect separate LANs to corporate wide intranets. The corporate intranets are
often connected to the public Internet. Also computer networks are complex
multivendor systems, that consist of thousands of pieces of equipment (cables, wall
outlets, patch panels, Personal Computers, Network Interface Cards, switches, routers,
firewalls, protocols, Client and Server software components) from tens of different
manufacturers. The development points towards (data and voice) integration and
(terminal) convergence.
Companies use voice and data networks to achieve savings on operative costs (system
administration, travelling...) and to provide better service (financial control, reachability,
logistics...). Private customers use networks for personal matters and for fun (bank
balances, net surfing, leasure time activities). Often the whole operation of a (large)
company is dependent on the distributed EDP system. If production planning,
manufacturing recepieces, logistics information, pricing, customer information, even
customer service and order intake are only available on-line, the network fault means a
VANHA MAANTIE 6
02650 ESPOO
[email protected]
NETWORK MANAGEMENT SYSTEM
MANAGEMENT SIGNIFICANCE AND TASKS
5
MATTI PUSKA
total halt of the operations. The pure labor costs of one hour downtime on a 1 000employer organisation can be estimated as follows:
1000 * 2400
• 1,4 = 19.760 Euros
170
The business losses are often higher (*. On global market service must be provided 24
hours a day. If the U.S. customer cannot get necessary product information or place an
order on the Internet server at 5 p.m. local time (because of a network fault in Finland),
he will take his money to the worst competitor. Odds are that he will place the tender or
the order to that competitor also next time, although our server is already accepting
connections. The problem may be dependent on the server, a network component or a
person inside the company, on the carrier or on the Internet Service Provider (ISP). If
the fault is repeatedly identified to the same partner, the company in question might
consider an alternative service provider.
The same applies to voice services as well. We take it for granted, that we get a good
quality free line, when making a call. If the network is repeatedly busy, chances are that
next time we select a different network operator or the company looks for other
possibilities.
Network faults can be caused by various reasons. A big source of fault is human errors
(users, system administrators). Other sources include technical systems (cabling,
hardware components) or software (bugs, faulty settings, incompatible software
components, power feed...). Reliability can be improved with proper network design
practices and fault tolerant solutions for business critical applications and systems. The
reliability is measured as availability, that is the propability of the service in question
being available, if needed. This can be estimated in the following way (**:
MTBF
Availability =
MTBF + MTTR
Another matter is network performance. Workstation user notices response time, i.e. the
time from hitting <Enter> until he/she gets the desired service (***. Long response times
might depend on several matters: PC performance, LAN loading, slow WAN links, high
server loading, improper protocol parameters...
*) Researches show that Fortune 1000 companies value the average cost of downtime for their ERP applications
worth 10 000 - 13 000 dollars per minute, making 31 - 41 Euros an hour per employer /26/.
**) 99% availability of a service is achievable with proper design, tools, attitude and good skills. Availability rates
well over 99% need also fault tolerant systems.
***) Our expectations mean a lot of the experienced response times. Normally a person can wait only a few seconds
without any indication or prediction of the service. On the other hand every Internet user understands, that
downloading a graphical page from a foreign site tends to take a LONG time.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
6
MATTI PUSKA
On circuit switched telecommunication networks, the availability is measured in block
percentage. Early network design rules stated that the daily call blocking ratio on long
distance services should not exeed 1 % or 3 %, depending on the place of the trunk.
Propably the current situation with several carrier providers promotes lower call
blocking ratios.
Network engineering tasks include end user support (helpdesk), administrative functions
(system administrator) and responsibility for the health of the network infrastructure.
Network Management System (NMS) is defined as a set of technical solutions,
which help network engineers to improve and ensure network availability and
usability, offering monitoring and configuration capabilities. Device management
systems often include an early warning service, that makes it possible to start fixing the
problem earlier. Maybe the fault can be found and fixed before the users notice it.
Hierarchical network views and Artificial Intelligence (AI) systems help operators to
locate the root cause quickly. Trouble ticket system gives some tools to analyse
reliability of various network components and to keep statistics of the network
availability and performance. Network load monitoring might give valuable information
for capacity planning, even prevent network faults caused by excessive loading.
The time to repair is the sum of the following time components (Figure 1):
• Detection time, which is the time from a service fault until it is detected by
the network engineers. Device or service monitoring tools often make
detection time significally shorter.
• Response time, the time from detection untill problem resolution is started.
Often only the response time is listed in the service contract. Response time is
mostly dependent on service person workload, priorities and contracts.
• Repair time, which includes fault findind, correction and component
replacement times. Proper fault finding tools may help making repair time
shorter.
• Recovery time, that is spend from fault correction until the network or the
service is again on. Often this is determined by technical issues, like data
recovery or Spanning-Tree recalculation.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
7
MATTI PUSKA
Time to Repair
Uptime
Resolution time
Detection Resonse Repair
time
time
time
Service on
Recovery
time
Service off
Service on
Service off
Figure 1: Repair time components.
1.2 Network Management Functional Areas and Layers
Many problems and tasks when running a network are alike, regardles of the network
type. The former CCITT (today ITU-T) has divided the tasks of a network management
system into five Functional Areas, as specified in the standard X.700 and ITU-T
M.3010. These are:
• Fault Management, which includes proactive prevention or reactive detection,
isolation and correction of abnormal behavior of the network. Fault
Managements helps in problem detection, fault finding, isolation and correction.
Often a device management system polls critical network nodes and fires up an
alarm, when a target component continuously fails answering the polls. User
interface is often based on hierarchical network maps with colour coded device
symbols, to provide easy problem detection. A device management system often
saves an event or a trouble ticket and can generate an automatic alarm (to a
mobile phone or a pager). Trouble tickets can be used later for reliability
analysis, reporting, and as input data for expert system development.
• Configuration Management, which includes network (capacity) and device
configuration. Configuration management keeps track of configuration data of
various network components. In a simple case configuration management system
displays device configuration and provides remote boot facitity. Often several
configurations can be saved for a single component, and configuration files can
be downloaded to the device in question, even automatically. File transfer
protocols (TFTP, Trivial File Tranfer Protocol and FTAM, File Transfer and
Access Method) are used for configuration file downloads. A bit more
sophisticated systems include early implementations of automated configuration
(DHCP, DDNS and SNMP autodiscovery).
VANHA MAANTIE 6
02650 ESPOO
[email protected]
8
MATTI PUSKA
• Accounting Management, measuring the usage of network resources, is an
important issue in telecommunication networks, but often omitted in LAN based
systems. In telephone systems switches interchange counting information, the
access switch of the A subscriber gathers the information and sends it
periodically to the billing computer. In computer networks, accounting
information can be used for network planning and fine tuning, but traffic
amounts are seldom used for billing.
• Performance Management ensures the network ability to satisfy the needs of
multiple users. It gathers information of network loads, like WAN link capacity
usage and telephone trunk utilization and displays (tabular or graphical)
statistics. This information is used for capacity planning, so exactly the suitable
amount of trunk capacity can be allocated. An RMON system (Remote
Monitoring) provides information about the most active stations on the LAN (top
talkers) that (might) need high capacity dedicated switch ports. The user is most
interested in application performance, but this data is only available in certain
system management tools.
• Security Management includes controlling access to network resources. In the
simplest form, it includes password protection and log files for the security
critical network components (firewalls, routers, telephone switches) or black
listing of stolen Mobile Systems on a GSM network. Some LAN equipment can
generate an alarm if an unknown end system is attached, but normally this needs
a single hardware vendor for active devices. Security issues on LAN
environment are often dealt separately, not by network management system.
As shown in Figure 2, network management tasks may also be grouped based on the
view level. Different Functional Layers include the following:
• Network Element Management, which is the lowest level, concentrates on
hardware modules and network components. It includes device specific data
only.
• Network Management concentrates on physical and logical topology of the
network elements, and provides a central view of all network devices.
• Service Management provides information about services, that are provided to
internal or external customers by the network.
• Business Management offers views from the business management perspective
to business processes and their availability.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
9
MATTI PUSKA
Business
Management
Service
Management
Network
Management
Network Element
Management
Security Management
Fault Management
Configuration Management
Performance Management
Accounting Management
Figure 2: Functional Layers and Functional Areas of Network Management.
Technical NMS components are used by humans. In large organisations network
administration (* is often implemented as a hierarchical model where local systems
management and network problem curing are handled by local personnel. The global
Network Operations Center (NOC) looks for the big picture, handles problem detection,
fault finding and advices the local managers (Figure 3). The level of centralisation
depends on organisation and skill of the local administrators.
*) To avoid confusion, we try to use the work Network Management while referring to technical systems, while
Network Administration and Network Engineers are used for human resources.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
10
MATTI PUSKA
Network
Management
Center
Figure 3: Network Operations Center
1.3 Network Management Systems
As seen before, the tasks of network administration are wide. Also the emphasis
depends on the implementation: when running a stable telecommunication network the
emphasis is on accounting and performance, but on computer network fault and
configuration management are more important issues. There is no single technical
system that can handle all the aspects in different networks.
Typically a network management system implementation consists of special software
that is run in a multiuser platform. The management station communicates with agents
on the managed devices. The spectrum of different management tools is broad, but
could (perhaps) be categorised in the following way:
• Device Management solutions concentrate on element and network
management layers and provide status information about different hardware
components on the network, their topology and status. The user interface is often
based on network diagrams drawn over maps or floorplans. These systems give
VANHA MAANTIE 6
02650 ESPOO
[email protected]
11
MATTI PUSKA
valuable help in fault finding. Figure 4 presents a hierarchical network map for
Castle Rock SNMPc, which is a good example of device managemet system.
Figure 4: Castle Rock SNMPc screen.
• System Management takes a system approach and is concentrated on
Client/Server systems, providing service or business management views. This tool
gathers a full database of IT hardware and software components. Network is often
modelled as business processes, giving answers to questions like "can we perform
stock inventory service now?". System management tools can also give
accounting information about usage of server capacity, even network bandwidth.
The user interface might take a more abstract approach. Figure 5 presents an
example of the system management tools: CA Unicenter TNG Business Process
View.
• Monitoring tools prepare statistics about traffic details and errors in important
parts of the network. The emphasize is on performance monitoring and often the
information is used for capacity planning. For users, information is presented in
tabular form and in graphical charts. Figure 6 presents Netscout, an example of
remote monitoring tool. Monitoring tools can perhaps best be described as
network management layer views.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
12
MATTI PUSKA
Figure 5: CA Unicenter TNG service management view.
Figure 6: Remote Monitoring with NETscout /1/
VANHA MAANTIE 6
02650 ESPOO
[email protected]
13
MATTI PUSKA
Planning and simulating tools are used for network planning before implementation.
An example is to prepare a plan of the cell structure and antennas, based on a
topological model, coverage and desired capacity, on a new GSM cellular network.
Documentation tools are used for preparing network documents. Besides manual
inputs, they might import system management inventory database or generate simple
PING-tests to discover all network nodes on a given subnet. However, they are passive
tools that produce static documents and do not directly interfere with the network.
Stricly speaking planning and documentation tools are not part of the network
management, only the border is vague.
1.4 Summary
At the end of each chapter, I will provide a summary figure about the chapter, in mind
map format. My map start from the northeast corner and circles the subject
counterclockwise (Figure 7). I started the chapter with a list and examples of
significance of network management. Then I proceeded with the five functional areas of
NMS, defined in the CCITT standard X.700: Fault, Configuration, Accounting,
Performance and Security Management. The chapter ended with categories of network
management systems, with screen shots of some practical software implementations.
Figure 7: Summary of Chapter 1.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
14
MATTI PUSKA
Review
Today, networks are essential for operation of any organisation, and a network fault
may prevent using distributed IT resources or handling contacts. Chapter 1 defined
network management being technical solutions to improve network availability and
useability. The CCITT X.700 defines five functional areas of network management:
fault, configuration, accounting, performance and security management. These are
common to all networks, but the importance of these areas differ from network to
network. There is no single product to solve all network management needs, but often
an NMS product can be positioned as a device management, a system management or a
monitoring tool.
Quiz
You can test your knowledge by answering the following questions with a single
sentence.
• List the functional areas of network management, according to CCITT X.700.
• How is network management defined in the course material?
• How can you calculate network availability, if you know Mean Time Between Failures
and Mean Time To Repair?
• Estimate the cost of lost labor time for one hour network downtime for 1 000 users.
• Give an example of an NMS service, which offers help to fault management.
• Give an example of an NMS service, which offers help to performance management.
• What is the main purpose of a device management system?
• List the most important challenges for network management in computer networks.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
15
MATTI PUSKA
2
Network Management
Components
• Network management elements: Manager,
Agent, Protocol and Data Structure for the
properties of the managed device
• ISO and TCP/IP management protocols
2.1 NMS Elements
(All) network management systems operate using Client/Server architecture, as shown
in Figure 7. The system has the following components:
• The manager is the system component which provides network engineer with
information about network status, performance and events. To be able to do that,
manager issues requests (based on administrator's interventions) to intelligent
network devices. According to the responses, manager displays desired
information on the user interface. Besides the request/response sequence, it can
also receive unsolicited notifications from network devices. Normally the manager
function is implemented as a special software on a powerful graphical workstation
running a multitasking operating system. As the manager offers user interface, it
may be regarded as a Client.
• An agent is a software component on network device (Managed System). It acts
on behalf of the device by receiving manager requests, getting desired information
from the device and sending responses, through an abstract Managed Object
interface to device hardware and software. Normally, the agent is a piece of
special embedded software on a network device. Because the agent must perform
additional functions and gather statistics, it consumes some additional processing
power and memory. Additional end-user price of a management agent starts from
about 50 Euros for bulk LAN hubs and switches. As the agent holds information,
that is accessable by the manager, it is the Server component.
• Manager and agents communicate either with the data carrying network (in-band
management) or through a separate network (out-of-band management) using a
special application protocol. On ISO (International Standardization
Organisation) networks, CMIP (Common Management Information Protocol) is
used, and SNMP (Simple Network Management Protocol) is the TCP/IP
protocol. Both define application layer request and response types,
communicating parties (who can issue the request), message formats (syntax and
VANHA MAANTIE 6
02650 ESPOO
[email protected]
NETWORK MANAGEMENT COMPONENTS
16
MATTI PUSKA
encoding) and the transport and network layer protocol stack needed to carry
network management messages (TCP/IP or ISO). Both SNMP and CMIP use
ASN.1 (Abstract Syntax Notation One) notation for message encoding.
• Data Structure describes the management properties (data attributes, agent
operations, behaviour of the agent and notifications) of the managed device.
Both manager and agent has the same data describtion. SNMP MIBs
(Management Information Base) are encoded using ASN.1. For common device
categories, standard MIBs exist, which also include the possibility to expand the
standard definition with the enterprise branch.
Managed System
Manager System
GUI
Manager
MIB
Requests
Replys
Protocol
Operations
Agent Notif’s
MIB
HW
MO
Managed
Object
Figure 7: Network Management Client/Server Architecture: The management system acting as a
Client and the Agent as a Server.
2.2 NMS Protocols
TCP/IP is the most popular protocol today. The application layer protocol for network
management is SNMP, which was developed in late 80's for temporary solution for
vendor independent router management. As other TCP/IP protocols, it is very simple
(this is one strength of TCP/IP). Application layer protocol uses ASN.1 syntax for
message and MIB encoding. For simplicity, SNMP uses unreliable UDP transport (*. On
the Internet layer connectionless IP is used. SNMP/UDP/IP messages can be carried in
almost any interface (LANs, circuit and packet switched networks). The TCP/IP
network management protocol stack is shown in Figure 8.
*) If an SNMP message is lost by the network, no retransmission is done. But the lost UDP datagram is an example
of network unreliability and thus gives valuable information to the manager application. On top of this, the
connectionless UDP transport is much easier (and cheaper) to implement.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
17
MATTI PUSKA
SNMP
ASN.1
UDP
IP
Figure 8: TCP/IP network management protocol stack.
CMIP, as other ISO protocols, were meant to replace the TCP/IP solution. When the
CMIP standardisation work was postphoned, equipment vendors began to support
SNMP. Today, CMIP is mostly used in (complex) telecommunication networks, but
quite rarely in (simpler) computer networks. It needs an ISO compliant protocol stack.
Also ISO protocols can be carried in many different networks. As shown in Figure 9, in
LANs, ISO IP network layer and TP 4 transport with error recovery is used.
CMIP
Application
Presentation ISO 8823, 8825, X.226
Session
ISO 8327, X.225
TP 4
Transport
Network
Data Link
Physical
X.225
ISO IP
LLC1
LAPB
8802.3
V.24
V.35
V.11
X.21
8802.5
TP 0
X.25
X.25
LAPB
LAPB
V.24
V.35
V.11
X.21
V.24
V.35
V.11
X.21
Figure 9: OSI network management protocol stack.
The third possibility is to use ISO CMIP management application protocol over a
TCP/IP network. This concept is called CMOT (CMIP over TCP/IP) and was
developed to make use of the popular DoD IP networks. Some LAN equipment vendors
support CMOT.
SNMP and CMIP protocols will be covered more detailed in chapters 3 and 4.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
18
MATTI PUSKA
2.3 Summary
Figure 10: Summary of chapter 2.
Review
Network management systems are based on Client/Server architecture, and consisting
of a Manager (offering user interface for the network administrator), Agents (on
managed network devices), a protocol (in between the Manager and the Agents) and a
Management Information Base (describing the properties of the managed device). The
same MIB description must reside both at the Manager and the Agent.
On TCP/IP networks, application layer SNMP protocol is used. SNMP messages are
transported using unreliable connectionless UDP, and UDP datagrams are carried in
IP packets. CMIP is the application layer protocol for ISO, which uses the complex
seven layer ISO protocol stack.
Quiz
• List various components of a Client/Server based Network Management System.
• What is the application protocol for network management in the TCP/IP stack?
• What does MIB describe?
• Where does MIB reside?
• What is the transport protocol used by SNMP?
• Which is simpler, CMIP protocol stack or SNMP protocol stack?
• List the protocols, from bottom up, on the SNMP protocol stack.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
19
MATTI PUSKA
3
• SNMP v.1, v.2c and v.3 protocols
• Management Information Base definitions
• Device and system management solutions
• Traffic monitoring solutions
• Monitoring result interpretetion
TCP/IP Network
Management
3.1 Simple Network Management Protocol Versions
3.1.1 SNMP v.1
Computer networks are multi-vendor systems (consisting of OSes, NOSes, protocol,
networking and application software, cables, NICs, hubs, switches, bridges, routers,
firewalls, modems, hosts, servers, proxies, interconnection services etc), and the
management of the network devices from different manufacturers must be based on
standards. The first SNMP version is a simple application standard protocol for
management messages interchange, based on the former SGMP (Simple Gateway
Management Protocol). Messaging is based on the Client/Server model. All messages
consist of a version number, a community name and a data field (Figure 11). Version
number indicates the SNMP version in use (0 for SNMP v.1). The community name is
an ASCII string that realises a simple authentication (*. Both manager and agent must
use the same community, otherwise the message will be discarded. The intention of the
community name was to make it possible to partition the network into separate access
environments (separately managed parts). The data field contains any of the five types of
Protocol Data Units (PDUs).
IP Packet
IP header
UDP Datagram
UDP header
SNMP Message
Version
Community
SNMP Data
GetRequest
GetNextRequest
SetRequest
GetResponse
Trap
Figure 11: SNMP v.1 message format.
*) In most cases, public is used for community name, at least for read-only operations. This is
also the default for most systems.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
TCP/IP NETWORK MANAGEMENT
20
MATTI PUSKA
The SNMP message can also be defined using ASN.1 in this way:
SNMP-Message ::= SEQUENCE
{
version INTEGER { version-1 (0) },
community OCTET STRING,
data ANY
}
Compare this definition with the protocol analyser snapshot shown in Figure 12.
Figure 12: SNMP v.1 GetRequest message.
The manager can send the followingPDU types:
• GetRequest-PDU is used by the manager to request an object value from an
agent. The request contains object identifier. The community name on the SNMP
message identifies the manager, and an IP number on the IP packet header
identifies the target agent. Normally, the agent responses with a GetResponse
message.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
21
MATTI PUSKA
• GetNextRequest-PDU is used by the manager to request sequentical object
information, for example for the agent to read through the rows in an interface
table. The agent responses with a GetResponse message, containing the requested
information.
• SetRequest-PDU is used by the manager to the agent to request to set the
mentionned attribute to a value specified in the request. The agent replies with a
GetResponse message.
As a reply, the agent sends a GetResponse-PDU, containing the requested data or
acknowledment to the SetRequest. The agent can also send an unsolicited Trap-PDU to
notify the manager about an unexpected circumstance, for example notifying the
manager about the managed device booting. To be able to send the Trap message to a
right destination, the IP address(es) of the manager(s) must be configured to the agent.
The SNMP PDU types are shown in the next figure.
Management
Station
Management
application
MIB
Manager
GetRequest
GetResponse
Managed device
Object
Object
GetNextReq.
GetResponse
Agent
UDP
SetRequest
UDP
IP
GetResponse
Trap
IP
NIC
MIB
NIC
Figure 13: SNMP PDU types.
GetRequest-, GetNextRequest-, SetRequest- and GetResponse-PDUs (inside the SNMP
header) include the following parts (see Figure 12 (*):
*) The SNMP header includes version number and community string.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
22
MATTI PUSKA
(• PDU Type, indicating the SNMP message type in question)
• Request ID, which is used to associate requests with the corresponding
responses. With UDP, either the request or the response may get lost.
• Error Status, indicating a possible error and the error type
• Error Index, which associates the error with the variable in question
• Variable bindings, associating each variable with its value. /3/
Format of a Trap-PDU is different from the previous, because of its function. The trap
PDU indicates object type, agent address, trap type and code, time stamp and variable
bindings.
SNMP-message formats are defined in ASN.1, as in our previous example, and encoded
using ASN.1 Basic Encoding Rules (BER). A tag, presenting the data type, and length in
bytes, are added in all variables. As shown in Figure 14, BER encoding starts from the
SNMP message by adding a tag and length on the message. Then various message fields
(Version, Community, PDU) are processed similarly, then various fields in the PDU
(Request Id, Error Status, Error Index, Variable Bindings) and finally Object Ids and
values, by adding a tag and length on each field. For values, clear text numerical or
ASCII coding is used, including the Community string(*.
SNMP Msg SNMP Msg
Tag
Length
SNMP Message Value
Version Community
Version Version Version
Tag
Length
Value
PDU Value
...
Figure 14: ASN.1 BER Encoding of an SNMP Message.
3.1.2 SNMP v.2c
SNMP v.2 evolved from the initial TCP/IP network management protocol version to
overcome the obvious shortcomings regarding security, flexibility and scalability. The
basis of the new version was Simple Management Protocol (SMP) development work,
with Secure SNMP additions. The SNMP v.2 was published as an IETF Proposed
standard (Internet Engineering Task Force Request for Comment) in the spring of
*) Clear text coding is clearly a security risk. This issue will be addressed in the SNMPv.3.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
23
MATTI PUSKA
1993, but it never reached the Standard status. Unfortunately there arouse various
security and remote configuration issues, so these were left out from the RFC 1905
SNMP v2c year 1996 document for community based version 2 protocol.
SNMP v.2c supports several new data types, information modules and new message
types. The version 2c PDU types are:
• GetRequest-PDU,
• GetNextRequest-PDU,
• GetBulkRequest-PDU, that allows the manager to retrieve large blocks of data
effectively
• SetRequest-PDU
• Response-PDU, that is equivalent to version one GetResponse, used by the
Agent to answer a Get or Set message
• InformRequest-PDU, that enables one manager to ask for a trap type
information from another manager. This message may also be used for reliable
notice by an SNMP Agent, because the receiver acknowledges it with a
Resoponse-PDU.
• SNMP v2Trap-PDU
• Report-PDU, for reporting of an event.
The name of version 1 GetResponse-PDU was changed to Response-PDU, whitch
describes the role of the PDU better. Otherwise the old message types are used in the
same way as in SNMP v.1 to offer backward compatibility.
All messages expect the GetBulkRequest use the same PDU format, that is shown in
Figure 16. Request operations may omit error status and error index.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
24
MATTI PUSKA
(*
Figure 15: An example of an SNMP v.2c message and PDU .
PDU
Type
Version
Community
String
Request
ID
Error
Status
Error
Index
Variable bindings
SNMP Data
Figure 16: SNMP v.2 PDU format (except the GetBulkRequest-PDU).
Other SNMP v.2 enhanchements include the following:
• Support for distributed management strategies, by introducing the Manager-toManager MIB and the InformRequest-PDU, as introduced earlier. An SNMP v.2
system can act both as an agent and a manager. As an agent, it accepts requests
from the superior manager to offer summary information. /4/
*) Although figures 11 and figure 13 refer to the same OID, the latter cannot be a reply of the former. A pure SNMP
v.2c agent cannot reply on a version 1 request.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
25
MATTI PUSKA
• 64-bit data type, which is useful with byte counters for high capacity interfaces.
For example the value for ifInOctets for a fully loaded Full-Duplex Gigabit
Ethernet interface would wrap around in 34 seconds with the previous Counter32
data type. If the value is read once a minute, the results would be meaningless.
• Improved error handling by introducing new Error Status codes, and the
possibility to include an exception on a Response-PDU. If multiple OID values
are requested on a single GetRequest and one is not available, the agent that
supports v.2c may return the values of the available OIDs and a value of
noSuchObject for the errornous variable
• Context, which is a collection of management information that are accessible by
an SNMP entity, and a single item (=OID for an object) may exist in more than
one context. An example may clarify: instead of asking a series of ifType and
ifNumber requests, the manager may simply ask for ifNumber.0 value in the
Ethernet context.
• A new kind of SNMP Proxy, which is capable of packet forwarding (for local
caching and obtaining information from a different network) and protocol
translations (between SNMP v.1 and v.2c).
• New version of the data model: SMI v.2 (Structure of Management Information)
and User-based Security model, which will be covered later.
3.1.3 SNMP v.3
SNMP v.3, as defined in Internet Standards RFC 3410 - 3418, approved finally at the
end of 2002, addresses the security issues that were postphoned from SNMPv.2.
Generally speaking, there are the following four potential threads for a network
management system:
1: Possibility for a third party to masquerade network management messages, and
to be able to perform unauthorized management operations (like accessing or
altering device configuration)
2: Possibility to modify SNMP PDU payload content, thus being able to perform a
management operation that is different from the original one. The outcome
would be the same as with masquerading, but an authorized message is now
used as a "template".
VANHA MAANTIE 6
02650 ESPOO
[email protected]
26
MATTI PUSKA
3: Possibility to modify the stream of SNMP messages, for example a cracker to
save a SetRequest for resetting a device and reuse that at a later time.
4: Possibility to access unauthorized information by breaking the non-disclosure
relationship between the Manager and the Agent. When SNMP v.1 and v.2c
messages are send in clear text, the cracker may for example access RMON
packet capturing data transmitted in SNMP messages.
SNMP v.3 includes authentication and privacy for secure management systems. Version
3 messages have three alternative formats. These are:
• Nonsecure format (noAuthNoPriv), containing destination (twice), source and
context information. This message is sent as clear text without encryption and
doesn't offer privacy or authentication (Figure 17). Because it doesn't provide
solution to any of the above-mentionned threads, it should't be used.
• Authenticated but not private (AuthNoPriv), which adds a digest and
destination and source timestamps on the message. The digest contains a
checksum, calculated from the original message with one-way hashing algoritm by
a secret value (Authentication passphrase) only known to the sender and the
receiver. If the message is changed by a third party, the digest value doesn't match,
leading discarding of the message. Any reusage trials will be detected with the
timestamp. Two hasing algoritms are supported, namely MD5 (Message Digest 5)
and SHA-1 (Secure Hashing Algoritm 1). This message format protects network
management traffic against threads 1 - 3.
• Private and authenticated (AuthPriv), which adds a digest and timestamps and
encrypts the whole message (excluding the first destination field). This format
offers also privacy against eavesdropping, protecting the system against all four
threads mentionned above. For authentication, MD5 and SHA1 are supported, for
encryption reversable 56-bit DES (Data Encryption Standard) is used. While
SNMP v.3 is designed to offer extension possibilities for the security subsystem,
additional stronger encryption schemes may be introduced, when needed.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
27
MATTI PUSKA
(*
Figure 17: An SNMP v.3 message .
SNMP v.3 includes User-based Security model and View-based Access Control Model,
so certain parts of the MIB tree can be exposed only to a defined class of authenticated
users /5/. As shown in Figure 18, the View-based Access Control allows or denies the
access based on answers to questions who, where, how, why, what and which. From the
first four, a view is formed. The object-type and object-instance are combined with the
viewName for the final decision.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
28
MATTI PUSKA
who?
securityModel
(ver/usm/Ent)
groupName
securityName
(user)
where?
contextName (deviceName/IP)
securityModel (version/usm/Ent)
viewName
yes/
no
how?
securityLevel (Auth&Priv)
why?
what?
which?
viewType (read/write/notify)
object-type (type)
object-instance (oid)
Figure 18: View-based Access Control Model.
3.2 SNMP Data Model: Management Information Base
MIB describes the properties of the managed device, encoded in ASN.1. Concise
MIB provides a set of macros, which are used to define SNMP v.1 management
information. SNMP Agents can define a MIB, using the concise MIB, which describes
the information and service they provide to the SNMP manager. The current version
MIB II, RFC 1213 from 1991, was rerived from the first MIB version, while SNMPv.2
was still under development.
All the MIB objects (including the MIB itself) are part of a tree, coded in ASN.1. As
shown in Figure 19, the MIB tree starts from the root (.) and includes a set of branches,
identified with a name and a number. A managed object parameter (presented in Figure
20 with a leave) is identified with an Object Id (OID), that is added by the Manager in
the SNMP request, when requsting for a value of a given parameter. The agent decodes
the OID to be able to return the value of the correct parameter.
*) Compare the contents of the version field with Figures 12 and 15.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
29
MATTI PUSKA
Root
CCITT
ISO (1)
Joint ISO-CCITT
Org (3)
Member-body
Us
DoD (6)
Ieee802dot11
Internet (1)
Directory (1) Mgmt (2) Experimental (3) Private (4)
SNMP v.2 (6)
Dot11mac
Mib-2 (1)
System (1) Interfaces (2) AT (3) IP (4) ICMP (5) TCP (6) UDP (7) EGP (8) Host (9) Transmission (10) SNMP (11)
sysDescr (1) sysObjectId (2) sysUpTime (3) sysContact (4) sysContact (4) sysName (5) sysLocation (6) sysServices (47
Figure 19: SNMP SMI (Structure of Management Information).
The Object Identifier enlists branch identifiers in order. It may be presented in:
• absolute textual format, starting from the root. For example, the Object Identifier
of a MIB variable, describing the System Contact is
{ .iso.org.dod.internet.mgmt.mib-2.system.sysContact.0 }
• absolute format, starting from the root, using the numerical identifiers, like
{ .1.3.6.1.2.1.1.4.0 }
• relative textual format, starting from a known place on the MIB tree. For
example, the System Contact in MIB II is { system.sysContact.0 }. Pay attention
to the fact that a relative OID doesn't have a period in the beginning.
• relative format using numerical identifiers, like { 1.4.0 }
• absolute or relative format, using a combination of textual and numerical
identifiers, like for example { .1.3.6.1.2.1.system.sysContact.0 }
Both a table entry and a single parameter value must be identified by an instance Id, that
is why a trailing .0 is added in an OID for a single parameter value.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
30
MATTI PUSKA
Figure 20: Browsing the MIB tree with a MIB Browser.
As shown, MIB II (.iso.org.dod.internet.mgmt.mib-2) includes the following essential(*
groups, that are mandatory for a compliant implementation:
• system (1) (**, including for example system description, vendor given device
type, contact person, location data, system name, uptime, service count
• interfaces (2), including SNMP interface numbers, interface table entries for
interface type, speed, MTU (Message Transmission Unit) size, addresses,
administrative and operational status, various transmit and receive counters and
transmit queue status data
• at (3), address translation table, mapping local physical (MAC) addresses to
network (IP) addresses. This is included only for compatibility reasons.
* If the protocol in question is not implemented on the managed device, the branch may be omitted
**) Absolute object identifiers (starting from the root of the tree) always start with a period (.). Relative MIB specific
identifiers start without the period.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
31
MATTI PUSKA
• ip (4), including IP parameters, packet counters and routing and ARP table
information
• icmp (5), including entries for transmitted and received Internet Control and
Message Protocol statistics
• tcp (6), which contains transmission protocol parameters and statistics, open
ports and detailed data of open connections
• udp (7), containing statistical information about connectionless transmission
protocol and open UDP ports
• egp (8), containing EGP routing protocol message statistics and EGP neighbor
table. While EGP routing is not included in all IP devices, this group may be
omitted.
• transmission (10), including transmission related information for 802.3, FDDI,
Frame Relay, RS-232, PPP and other interfaces.
• snmp (11), including a place for (future) network statistics about network
management messages, PDUs and errors.
Besides the listed essential MIB-II groups, there is a growing selection of standard
optional groups for various purposes. Some of the most important include the following:
• ospf (14), bgp (15) and rip2 (23) for other (more popular) routing protocols
• rmon (16) for Remote Monitoring
• dot1qBridge (17) for address table and Spanning Tree data for 802.1D bridges
and switches
• host (25) for host related system, storage, device, software and performance data
• application (27) and dns (32) for application layer data
• ifMIB (31) for detailed interface spacific data
• upsMIB (33) for Uninterruptable Power Source status, battery and
configurations
• etherMIB (35)
• atmMIB (37) for ATM (Asynchronous Transfer Mode) related interface, virtual
circuit, AAL5 (ATM Adaptation Layer 5) and ATM traffic data
• ipMIB (48), tcpMIB (49) and udpMIB (50) for IP, TCP and UDP compliance
data
and many more.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
32
MATTI PUSKA
The MIB scheme may be extended by introducing new standard objects (there is
additional idenfifications available), by using the experimental group during testing and
by using the private group. Private MIB extensions are stored with a vendor name under
{ .iso.org.dod.internet.private.enterprises }. To prevent any conflict, the vendor name
must be registered by ICANN (Internet Corporation for Assigned Names and Numbers).
Enclosed you'll find an example of a short-form ASN.1 definition of the uppermost
layer of the Linux private MIB { .iso.org.dod.private.enterprises.ucdavis } /6/.
ucdavis
OBJECT IDENTIFIER ::= { enterprises 2021 }
procTable OBJECT-TYPE
SYNTAX SEQUENCE OF PrEntry
::= { ucdavis 2 }
memory OBJECT IDENTIFIER ::= { ucdavis 4 }
diskTable OBJECT-TYPE
SYNTAX SEQUENCE OF DskEntry
::= { ucdavis 9 }
loadTable OBJECT-TYPE
SYNTAX SEQUENCE OF LaEntry
::= { ucdavis 10 }
systemStats OBJECT IDENTIFIER ::= { ucdavis 11 }
fileTable OBJECT-TYPE
SYNTAX SEQUENCE OF FileEntry
::= { ucdavis 15 }
version OBJECT IDENTIDIER ::= { ucdavis 100 }
snmperrs OBJECT IDENTIFIER ::= { ucdavis 101 }
mibRegistryTable OBJECT-TYPE
SYNTAX SEQUENCE OF MrEntry
::= { ucdavis 102 }
ucdTraps OBJECT IDENTIFIER ::= { ucdavis 251 }
The manager includes the object identifier in a request and the agent returns or sets the
value of this object. Normally MIB identifiers are abstracted by the network
management software and a user does not have to deal with object identifiers. An NMS
software often includes a MIB browser, which enables queries to MIB identifiers and
entries. An example is the UNIX CMU package, which enables SNMP GetRequests,
GetNextRequests, GetBulkRequests, SetRequests, Traps and MIB walking using
absolute or relative MIB identifiers (see the manual pages for additional information).
Enclosed are two examples of MIB walking and GetRequest (*.
*) Computer printouts are shown using Courier 10 font. User input is shown in boldface.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
33
MATTI PUSKA
[matti@matti matti]$ snmpwalk -f localhost public .1.3.6.1.2.1
.iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0 = "Linux
matti.puska.fi 2.2.5-15 #1 Mon Apr 19 22:21:09 EDT 1999 i586"
.iso.org.dod.internet.mgmt.mib-2.system.sysObjectID.0 = OID:
.iso.org.dod.intern
et.private.enterprises.ucdavis.ucdSnmpAgent.linux
.iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.0 = Timeticks:
(71222) 0:11:52.22
.iso.org.dod.internet.mgmt.mib-2.system.sysContact.0 =
"[email protected]"
.iso.org.dod.internet.mgmt.mib-2.system.sysName.0 = "matti.puska.fi"
.iso.org.dod.internet.mgmt.mib-2.system.sysLocation.0 = "Veikkola
Finland"
.iso.org.dod.internet.mgmt.mib-2.system.sysServices.0 = 72
...
[matti@matti matti]$ snmpget -f localhost public .1.3.6.1.2.1.1.1.0
.iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0 = "Linux
matti.puska.fi 2.2.5-15 #1 Mon Apr 19 22:21:09 EDT 1999 i586"
3.3 Device Management Systems
In mid-size and large computer networks, an SNMP based device management system is
often used. This offers status information about manageable network devices (hubs,
switches, routers), network layout and traffic statistics. The network layout offers a
universal view and launch pad for most network maintenance operations.
The first step in device management implementation is a policy decision about network
management direction (what it needed, what protocol, version, organisatio). After the
policy is clear, the network infrastructure capabilities are explored and updated by
purchasing only manageable devices. Modern workgroup and backbone layer 2/3
switches, MAN and WAN routers, ATM and Frame Relay switches nowadays include
an SNMP agent, but for hubs (cheapest well under 50 Euros) the SNMP agent costs a
lot. But hubs do not play an important role in modern LANs, so relocating them or
leaving them away from the management concept doesn't make a great harm. Many
operating systems (Windows XP, 200x, NT, Win 9x, UNIX, Linux...) offer a software
based SNMP agent, which uses processor capacity for agent functions.
According to the chosen management concept, we'll need one or more device
management station (Figure 21). This is a powerful graphical workstation, running a
multitasking operating system and a special software. Today, HP OpenView, Sun
Microsystem SunNet Manager, Aprisma Spectrum, IBM Tivoli, CA Unicenter TNG and
CiscoWorks 2000 hold the leading positions wordwide. OpenView and Unicenter have
taken steps towards general purpose management platform, which includes also systems
management features. SunNet Manager is clearly concentrated in device status and
configuration usage (specially for Sun hosts), forming a professional tool with perhaps
not so fancy graphics. Aprisma Spectrum, on the other hand, has very attractive
graphical outlook and Artificial Intelligent based experts system for automating fault
finding. Other products are available for small and mid size networks.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
34
MATTI PUSKA
SNMP
Agent
SNMP Agents
SNMP
Agent
SNMP
Agent
SNMP Agent
SNMP
Agent
SNMP
SNMP
Agent
SNMP
Agent
Hub
SNMP
Agent
Management
Station
Figure 21: SNMP device management system components.
To offer full features, the management software also needs proprietory MIB
descriptions, GUI symbols and clickable panel drawings for the managed objects. The
trend has been, that the management interfaces for new devices has been first developed
for the most popular management software which makes them even more popular.
For device management, IP and SNMP parameters (IP address, subnet mask, default
gateway, SNMP version, community name, trap destination, SNMPv.3 parameters if
applicable, location and contact information, allowed management stations) must be
configured to all manageable objects. If a community name other than the default
public is used, the same configuration must also be made on the management station.
SNMP agent configuration details depend on the implementation. Windows-hosts offer
a graphical applet for agent configuration and the Linux snmpd daemon uses text files
on /etc/snmp directory. General daemon configuration is done in the
/etc/snmp/snmpd.conf file, including comprehensive commenting. The (short form)
default access control and system contact information sections include the following:
# Access Control
#
com2sec
com2sec
sec.name
source
localhost
127.0.0.0/8
mgmtstation 192.168.123.159/32
#
group.name
VANHA MAANTIE 6
02650 ESPOO
[email protected]
sec.model
community
public
public
sec.name
35
MATTI PUSKA
#group
group
group
group
nms
nms
local
local
v1
v2c
v1
v2c
mgmtstation
mgmtstation
localhost
localhost
#
view
name
all
incl/excl
included
subtree
.1
#
access
access
group context sec.model sec.level prefix
nms
""
any
noauth
exact
local ""
any
noauth
exact
mask
read
all
all
write notif
none all
none all
# System contact information
syslocation
syscontact
trapcommunity
Veikkola Finland
[email protected]
public
In cisco IOS switches and router's SNMP agent configuration are done on global
configuration mode. Setting the community string enables the SNMP agent (*. If Trap
messages are enabled, also the destination host must be specified. Also the sysContact
and sysLocation contents can be configured:
MyRouter>enable
MyRouter#conf term
Enter configuration commands, one per line.
MyRouter(config)#snmp community public ro
End with CNTL/Z.
MyRouter(config)#snmp enable traps snmp
MyRouter(config)#snmp host 195.148.151.107 traps public
MyRouter(config)#snmp contact Matti Puska
MyRouter(config)#snmp location Evitech Espoo cisco-laboratory
MyRouter(config)#exit
*) SNMP Write capabilities should be enabled only if absolutely necessary. In this case, I recommend to
limit the SNMP management messages from a specific host/hosts, using an Access Contol List.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
36
MATTI PUSKA
Because network management systems are often used in large and complex networks,
the device management station discovers network nodes automatically (Autodiscovery),
as shown in Figure 22. The management station first reads the local ARP table, then
contacts the default gateway (hoping to get the ARP table, routing table and neighbor
table, if any, from a manageable router) and finally sends ICMP Echo Requests to all
local nodes. If an ARP entry is found or an Echo Reply is received, the NMS station
then sends an SNMP GetRequest to discover the target SNMP status. If an SNMP Reply
is received, the management station then requests for additional information about the
device type, manufacturer and model, even MAC address table information. The routing
table should include all (at least most) IP subnets on the Autonomous System, together
with the next hop IP addresses. The remote routers are then contacted with SNMP for
additional information. All manageable and nonmanageable network nodes are added to
the discovery database on the NMS station. Finally, all IP nodes, device, interface and
vendor types for SNMP devices, STP and IP subnet topology are discovered
automatically.
192.168.123.1
195.148.158.151
GetRequest {system.sysDescr.0}
GetResponse = cisco router
GetRequest {at.atTable}
GetResponse = 195.148.158.151
GetRequest {ip.ipRouteTable}
GetResponse = 192.168.123.1
Echo Request
Echo Request
GetRequest {system.sysDescr.0}
GetResponse = cisco router
Figure 22: Autodiscovering network nodes.
Based on the discovery database and address information, the management software
builds network maps automatically (Automapping). Normally hierarchical maps are
used (based on bridges/switches and IP subnets). With manual intervention we can
manipulate the network hierarchy. Often the top-level hierarchy includes countries or
places of operations and is drawn on top of a geographical map. The next level might be
towns, then IP subnets, down to broadcast domains formed by switches.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
37
MATTI PUSKA
Manageable objects are categorized based on device types. Important network
components (like hubs, switches, routers and servers) are polled with suitable time
intervals to make sure that they are operational. If a target fails to answer the
GetRequest a few times successively, an event is risen. For critical components this
means an alarm, leading to a visual trouble ticket and an audible sound, even a pager
call. Anyway, the color of the icon of the device in question will be changed (yellow for
warnings, red for alarms) and an entry to the event log will be written. Normally all
instances of a device failing to reply will not cause an event (if the component is a
workstation, we will not want an alarm every time a workstation user goes home after a
working day!).
SNMP is a poll/response system, and the polling intervals must be chosen with care. If
we have 5 000 workstations and 1 000 network devices, and we configure the polling
interval as 5 s for each node, this will generate:
2 • 6000 • 80 B • 8b / B
= 1,54 Mbit / s
5s
traffic to the segment of the management station. If 80 % of this is destined to remote
LANs, we need a total of 1,2 Mbit/s capacity for SNMP polls only. On the other hand,
19,9 second interval from a fault on a backbone switch to an alarm might in some case
be a long time. Also the discovery process generates some traffic and loading, so, after
the initial autodiscovery, it is normally run automatically only after local business hours.
The user interface, based on device symbols and network maps, not just gives
information about network and device status, but also enables the manager (person) to
point a device and issue data link or network layer test from a remote node to another or
order a remote device to gather traffic and error statistics to be displayed on the
management station. Double-clicking a node opens a device-specific management
session (Telnet, WWW Browser, vendor application) to the manageable object in
question. Common set of views, tools and operations may be customized as working
sets.
Device management systems are often concentrated in a Network Operations Center or
centers and used by experts. On global organisations, the NOC must operate 24 hours a
day. The centralisation also promotes the growth of the expertise needed for effective
operation of network management. Device management may also be outsourced to one
of the service providers offering NMS services.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
38
MATTI PUSKA
3.4 Remote Monitoring
3.4.1 System Components
The SNMP request/reply protocol is unefficient in collecting information about network
traffic, because the NMS station must retrieve values of necessary MIB objects at fixed
time intervals. For traffic monitoring purposes, RMON MIB was developed. An RMON
management station receives administrator interventions and issues commands to
RMON probes. These are attached on various segments of the network, and they hear
all the traffic on their segment (in promiscuous mode), collect the desired statistics and
send the summary information to the management station. The RMON management
station then forms graphs of the requested statistics to be displayed.
RMON I is an SNMP MIB definition and SNMP protocol is used between the
management station and the agent. RMON I (.iso.org.dod.internet.mgmt.mib-2.rmon)
covers OSI layers 1 - 2 (Physical and Data Link). RFC 1757 defines ten RMON groups
for Ethernet and Token Ring traffic. These are (Figure 23):
• rmon-Traps (0) for a risingAlarm, fallingAlarm and packetMatch. Traps are
sent by a RMON Probe without a request from the monitoring station.
• statistics (1), including various traffic and error counters for Ethernet and Token
Ring LANs (sent, dropped and broadcast frames, CRC errors, runts, giants,
fragments, jabbers, collisions and frame size counters)
• history (2) information about defined sample frames during a sample period for
long term trending and averaging
• alarm (3) information to be set by the management station to activate on special
event or treshold. The agent then sends an alarm message, when the configured
event occurs.
• host (4) information (addresses, traffic, broadcast and error counters)
• hostTopN (5), stating the top talkers and their statistics for a given period and
rate base
• matrix (6), offering traffic matrix about who is talking to whom (sourcedestination table)
• filter (7), to filter only the interesting portion of the traffic before frame
capturing or event generation. Filtering can be based on source and/or destination
data link or network addresses, protocol, protocol event, elapsed time, data pattern
or an error, using the bit-filter expression and mask
• capture (8), to capture all or filtered frames to a frame buffer on the agent
• event (9), to monitor traffic or statistical events and to send indication to the
management station
• tokenRing (10) specific topology, configuration and source routing information.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
39
MATTI PUSKA
RMON II offers the same information about the full OSI stack. Because it includes also
the upper layers, it can provide information about end-to-end traffic, protocol and
application distribution, even application usability and response times. RMON II defines
additional nine new groups, namely:
• protocolDir (11), including the target protocol definitions
• protocolDist (12), including statistics about the target protocols
• addressMap (13) of data link to network layer address mapping (including ARP
tables)
• nlHosts (14), including statistical information for every network address
• nlMatrix (15), that holds traffic matrix for packets and errors of the network
layer address pairs
• alHosts (16), holding statistics and identification of the application layer
addresses and names
• alMatrix (17), which holds traffic matrix based on upper layer addresses
• usrHistory (18) information about trending and averiging of any user definable
MIB value
• probeConfig (19), holding information about RMON probe capabilities, settings
and functions
• rmonConformance (20), including information about RMON 2 compliance and
supported RMON 2 groups.
Figure 23: RMON groups.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
40
MATTI PUSKA
In shared media LANs (Ethernet repeaters/hubs, Token Ring MAUs) one RMON probe
is needed per collision domain. In fully switched networks, it is not possible (nor
practical) to attach a probe to the ports of the switches. Fortunately most high-end
switches also include a limited RMON support, so the switches (located in central parts
of the network) can gather RMON statistics from the attached hosts (Figure 24).
Another possibility is to use port mirroring ablility, where all the traffic of the
configured port is doubled to an analysis port with the RMON probe.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
41
MATTI PUSKA
Probe
Probe
R
R
Probe
Probe
R
Probe
R
Port
Mirroring
Figure 24: Remote Monitoring system.
3.4.2 Proactive Monitoring
RMON systems offer both proactive and reactive monitoring. Proactive tasks are often
based on baseline measurement of a working network. Figure 25 shows an example of
proactive RMON measurements. The baseline answers the question "How should our
network be?". The baseline measurement should include a useful set of the following
measurements from important parts of the network:
• daily and weekly trends for traffic amount
• traffic matrix, consisting of the top talkers and listeners
• portion of broadcasts and multicast PDUs
• network and application layer protocol distribution
• packet size distribution.
Baseline information is used for network trending, for capacity planning and directing,
network tuning and as a comparision point in fault finding.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
42
MATTI PUSKA
Figure 25: Observer RMON application.
3.4.3 Reactive Measurements
RMON systems also offer troubleshooting help as reactive analysis. The packet filter,
capture and decode capabilities can be used for solving protocol based problems from a
central place. The challenge in protocol analysis is, however, not the use of the
instruments, but the need of deep protocol knowledge to make use of the vast
information.
Some RMON products also include packet generation and response time monitoring
capabilities, as shown in Figure 26. Packet generation, however, is not part of the
RMON standard. /7/ /29/
VANHA MAANTIE 6
02650 ESPOO
[email protected]
43
MATTI PUSKA
Figure 26: Generating LAN traffic includes defining the frame, packet and segment/datagram
details.
3.4.4 Interpreting Monitoring Results
Total Capacity Utilization
Data and voice networks are dimensioned to give good enough performance at
reasonable costs. Overdimensioning brings unnecessary investment and running costs,
while underdimensioning cuts some of the savings by lowering the network application
performance. Especially while dimensioning WAN links, monetary costs for network
connection services should be considered.
During baseline measurements, capacity usage figures and time histograms for the
critical network connections are ackquired. The time histogram for bandwidth
utilization gives additional information, and peak-to-average ratios and peak times
should be also considered. In Figure 27 we see frequent peaks at about 250 kbit/s per
direction. If this is the line capacity, we have an underdimensioning, but if we pay for a
512 kbit/s Frame Relay CIR (Committed Information Rate), we should check if we
really get 512 k end-to-end. Table 1 gives some guidelines when interpreting bandwidth
utilization results.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
44
MATTI PUSKA
Table 1: Guidelines for interpreting bandwidth utilization charts.
Symptom
Possible cause
Possible remedy
High peak rate with
low average
Bursty applications
Control the traffic patterns
to smoothen the bursts
Low peak and low average,
good applic. performance
Overdimensioning
Consider lower capacity links
Frequent constant rate
peaks but not on the line
capacity
Are you getting what
you are paying for?
Checking the service capacity,
consider control features
High average, constant
peaks near the line capacity.
Poor applic. performance
Underdimensioning
Add control features to use the
capacity effectively. If this does
not solve the problem, buy more
capacity
Figure 27: Capacity utilization graph for a Frame Relay WAN link. Often 5 minute sampling rate
is used, as in this example.
Bandwidth Usage Breakout
The total bandwidth usage may be divided into hosts, applications and traffic classes.
For capacity, QoS and performance planning bandwidth utilization per applications and
per hosts gives valuable information. Concerning the application distribution, we should
understand that the TCP/UDP port doesn't always indicate the correct application, as is
the fact with KaZa peer-to-peer file sharing, that rides on TCP port 80, the HTTP port
VANHA MAANTIE 6
02650 ESPOO
[email protected]
45
MATTI PUSKA
(*. For reliable application distribution, monitoring systems that are capable of encoding
application layer messages should be used. These can also identify applications that use
dynamic ports, like for example RTP.
When bandwidth utilization per protocol is known, network administrator can make
sure, that network resources are distributed based on application needs and good enough
performance is given to business critical applications. The other side of the coin is the
fact that bandwidth utilization of the less important applications will be truncated.
Bandwidth utilization per sender and per receiver (Top N, Host Matrix) can be used for
network dimensioning and fine tuning, even for contents planning. If the biggest
transmitter of bytes (Top Talker) is the intranet Web server, we may consider decoding
the intranet pages using less graphics. If the biggest receiver (Top Listener) of the
Internet access appears to be a music download or streaming video workstation, network
administrator should have tools to correct this situation as well.
Broadcast Traffic
Today's network protocols and applications create broadcasts (like ARP address
resolution, NetBIOS name resolution and routing updates) and multicasts (like Ghost
hard drive cloning and IPTV). Layer 2 Ethernet switches don't keep an address table
entry for the broadcast address, but flood the frame to all ports but the original one.
Layer 3 routers forward only directed layer 3 broadcasts, but not the flooded by default.
Broadcast propagation may be controlled by VLANs and layer 3 switches or routers.
A thorough baseline measurement should include determining the broadcast level on
critical places on the network. There is no single well-defined warning level for amount
of broadcasts, but the result always depends on existing protocol, application and
network environment. While the result of a broadcast on an end system is dependent on
the device hardware and software, it is hard to estimate the effect on broadcast traffic on
application performance.
If broadcasting is suspected for performance degradation, a more detailed examination
is needed. Excessive broadcasts may depend on the following problems:
• Too large broadcast domain. This may be divided with VLANs, by introducing
layer 3 network devices or by redesigning the network.
*) This property is clearly planned to make it difficult to filter out KaZa with simple access-lists in firewalls and
traffic policers. Another feature of KaZa is that is using multiple source ports for a single host, to give multiple WFQ
(Weighted Fair Queuing) queues, and better performance, for a single session.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
46
MATTI PUSKA
• Application operation or configuration. For example Windows hosts should not
be configured as B or M Nodes, because this makes them to always use
broadcasting for Windows name resolution.
• Network problem, that causes excessive broadcasts. This kind of problems
include Spanning Tree loops and flapping routes with an event triggered routing
protocol. The cure is to eliminate the original problem or to minimise the impact.
For multicasts, possible remedies include allocating the multicast application on a
separate VLAN, configuring switches as multicast aware or scheduling multicast
applications to low-volume periods.
Ethernet Errors
Distributed Network Monitoring systems or portable monitoring devices are often used
for getting additional information for fault finding. RMON includes information of
Ethernet errors, as well as limited statistics of other interfaces.
The RMON Ethernet Statistics (.1.3.6.2.1.16.1.1) includes the following entries (see
Figure 28) (*:
● Statistics Index and Data Source (ethernetStatsIndex, etherStatsDataSource),
which uniquelly identify entries and the source, i.e. the interface of the data.
● Number of events of packet dropping by the probe (etherStatsDropEvents). If
RMON statistics is gathered by a heavily loaded network element, some frames
may be dropped due to lack of resources. Dropping lowers the reliability of the
results, and should be taken into account.
● Byte counter for total volume of data (etherStatsOctets) of the selected interface.
As stated by the MIB description, this gives a reasonable estimate of the Ethernet
utilization.
● Total number of Ethernet frames (etherStatsPkts), including unicast, multicast
and broadcast frames, as well as corrupted frames.
● Number of broadcast frames (etherStatsBroadcastPkts), excluding multicasts.
● Number of multicast frames (etherStatsMulticastPkts).
*) The RMON RFC refers to packets, although layer 2 PDUs are normally called frames.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
47
MATTI PUSKA
● Number of frames of the correct size but with an uncorrect FCS value or with an
alignment error (etherStatsCRCAlignErrors). A frame with a non-integral
number of bytes, like 64,5 Bytes or 516 bits, is counted as an alignment error.
● Number of frames shorter than 64 Bytes (etherStatsUndresizePkts) but with
otherwise correct Ethernet format. These are sometimes called Runts.
● Number of frames longer than 1 518 Bytes, but with otherwise correct Ethernet
format, sometimes called Giants. For 802.1Q tagging, the size limit is extended
to
1 522 Bytes.
● Number of fragments, i.e. frames shorter than 64 Bytes with a bad FCS. These
are caused by CSMA/CD collisions on a shared media network or by frame
corruption due to excessive noise.
● Jabbers, i.e. too long "frames with a corrupted FCS from a single host
transmitting continuously.
● The best estimate for the number of collisions, determined by the RMON probe.
On 10Base2 and 10Base5 segments, an occation of two or more stations sending
simultaneously is interpreted as a collision. On a 10/100BaseT twisted pair port,
a collision is detected when DO and RD signals are present simultaneously.
● Number of frames of the size 64, 65 - 127, 128 - 255, 256 - 511, 512 - 1023 and
1024 - 1518 Bytes.
● Owner or the configurator of the probe, and the status of the etherStats entry.
For all interfaces, Ethernet or not, OIDs on the interface branch may be used. This
includes counters for input and output multicasts, broadcasts, octets and frames.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
48
MATTI PUSKA
Figure 28: RMON Statistics group.
For different Ethernet errors, the following guidelines may be used, while interpreting
the results:
● Collisions are part of the normal operation of CSMA/CD in shared media
networks (10Base2 and 10BaseT and 100BaseT hubs). Collisions cause
fragments and some runts. In a shared medium 10 Mbit/s networks, the collision
rate should be kept under 10 collisions a second or under 5% in average. If the
collision rate is high also during a low utilization period, a faulty Ethernet device
may be the fault.
Collision volume should be low on fully switched network segments. Collisions
on a switched LAN may be caused by Half Duplex/Full Duplex or speed
mismatches. Especially a maltfunctioning 10/100 Mbit/s speed autosensing
causes 33 % or 100 % collision rate. Sometimes external noise causes errors that
are interpreted as collisions.
● The most propable cause for numerous CRC (often presented as FCS error) or
alignment errors on correct-sized frames is extesive noise level. This may be
caused by a noisy environment, too poor noise immunity of the cable, too long
cable segment or otherwise faulty cable or duplex mismatch. If you find
excessive CRC or alignment errors, you should find the place and test the cable
VANHA MAANTIE 6
02650 ESPOO
[email protected]
49
MATTI PUSKA
segment in question. Beware of the fact that faults causing CRC errors often
include phenomenons that are interpreted as late collisions as well.
● No undersized (except caused by collisions) and oversized packets should exist.
If they do, the most propable cause is a faulty NIC driver, networking software
or network adapter hardware. Always find the sender of these frames, perhaps
with a network analysator or frame capturing, and correct the fault. Some old
versions of the monitoring software may interprete 802.1Q tagged frames as
baby giants, but this will be corrected by upgrading the monitoring software.
● Fragments are caused by collisions, faulty network hardware or noise. In a fully
switched network no collisions should exist, but noise is more or less always
present. If excessive fragments are sourced from a single host, you should test
the NIC.
● On a Jabber situation a network device is sending continuously, violating
Ethernet timing rules. A hub or a switch should close such a port after 20.000 50.000 bit time for awhile, and reopen it to check if the fault still exists. Jabber
faults are normally caused by a faulty network adapter. Other possible sources of
jabber faults include NIC driver, bad cable or groungind problems. Find the
sending station and replace the NIC, so jabbers should disappear.
● Excessive broadcasts or broadcast to frame ratio indicates too large broadcast
domains, poor network design or protocol misfunctioning. Broadcasts are an
essential part of modern network protocols, but excessive broadcasts consume
network capacity and cause unnecessary interrupts on hosts. Segmenting the
network with VLANs or routers will offer means to make broadcast domains
smaller. Broadcast rate should be kept under 40 broadcasts a second on a 10
Mbit/s Ethernet, but this rate should be compared to the total number of frames a
second. If broadcasts are sourced from a single host, you should check the reason
for broadcasts and correct any misconfigured network parameter.
Performance
Network usability includes both reliability and performance aspects. End-user
performance could be measured by response time, i.e. time from mouse click until, but
this would need measurement software on workstations. As shown in Figure 29, a
normal TCP based data application traffic includes the following phases:
● TCP connection setup using the three-way handshake (SYN, SYN/ACK, ACK)
for setting the initial sequence numbers. The exchange of these three TCP
segments forms the connection setup time.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
50
MATTI PUSKA
● Sending the request by the client workstation, transferring this message by the
network and processing the request by the server The latter (Application
Response Time) may be easily monitored by the server.
● Total data transfer time, including processing time for data frames and
acknowledgement segments. For a single data/acknowledgement pair, the Round
Trip Time describes the two-way network delay.
● Connection teardown with double Fin/Ack messages. This time doesnä't have
affect on user response time.
TCP SYN
TCP SYN/ACK
TCP ACK
Request
Time to
First
Byte
Connection Setup Time
Application Response Time
Data
Ack
Data
Connection
Duration Transfer
Time
Data
Ack
Round Trip Time (RTT)
FIN
ACK
FIN
ACK
t
t
Figure 29: TCP application traffic and some performance parameters.
Because, as said, performance from the end-user perspective is hard to measure,
secondary parameters are used instead. Round Trip Time may be measured either by
monitoring the network traffic or by generating additional probe packets for monitoring.
For server performance, local application response times may be recorded on the server.
3.5 System Management
System solutions for IT, like Unicenter TNG from Computer Associates and Tivoli
TME from IBM, cover network infrastructure, Windows, Win NT/2000/XP and UNIX
workstations, servers, software components and service networks. For example, the user
interface in Unicenter is based on application sceneries, providing information about
systems serving business processes (Figure 30). Also the HP OpenView has developed a
general concept in system management, covering network devices, workstations,
printers, servers and client/server systems.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
51
MATTI PUSKA
Figure 30: Service view from CA Unicenter TNG system management tool.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
52
MATTI PUSKA
3.6 Summary
Figure 31: Summary of the chapter 3.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
53
MATTI PUSKA
Review
SNMP v.1 is a simple application layer TCP/IP protocol. Version 1 PDUs include
GetRequest, GetNextRequest, SetRequest (all send by the manager), GetResponse
answer and unsolicited Trap by the agent. V.1 security is based only on clear text
Community string. Version 2c includes some new PDUs and a concept for distributed
management, but the security improvements were cancelled from this version. These
were introduced in version 3, which has Nonsecure, Authenticated (digest and
timestams) and Private&Authenticated (also encrypted) message formats. Version 3
also includes security and access control models.
MIB describes device properties by using MIB categories for different device types and
an Object Identifier tree, also including a place for private extensions. The OID is
present in every SNMP request and response and it uniquely describes the parameter in
question.
SNMP based device management systems offer status information about manageable
devices, network layout and traffic statistics, and include autodiscovery, status polling
and parameter retrieval. An RMON monitoring system includes RMON probes,
collecting data and sending summaries, and an RMON station which issues commands
and displays monitoring information. The RMON system can be used for proactive
(baseline) and reactive (troubleshooting) tasks. System Management tools offer a
common view of the whole IT infrastructure, maybe based on business processes.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
54
MATTI PUSKA
Quiz
• In SNMP v.1, what is the response to a SetRequest PDU?
• In SNMP, what is the purpose of MIB?
• List the five different SNMP v.1 PDU types.
• What is the SNMP v.1 PDU type that an agent can send without a request from
manager?
• What are the most important shortcomings of SNMP v.1 which were corrected by
version 2c?
• What is the purpose of Community name in SNMP v.1 and v.2c?
• List the three different message formats of SNMP v.3
• What is the purpose of OID?
• How can vendor specific data be presented in SNMP Structure of Management
Information?
• Give a few examples of data in the .iso.org.dod.internet.mgmt.mib2.system branch of
SMI.
• What parameters must be configured on an SNMP agent?
• What is Autodiscovery in the NMS context?
• What is polling in the NMS context?
• What factors should be considered when choosing polling interval for a device?
• Give an example of information provided by an RMON system.
• What is the function of an RMON probe?
• What is the main difference between RMON and RMON II?
• Give an example of proactive RMON measurement.
• Give an example of reactive RMON measurement.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
55
MATTI PUSKA
4
ISO Network Management
This chapter includes:
• Telecommunication Management Network
framework and management tasks
• Common Management Information
Services and Protocol
• Object oriented TMN information model
• Example Network Management System
implementations
4.1 Telecommunications Management Network
4.1.1 NMS Environment and Management Tasks
Public telecommunication services have been regulated by local laws and authorities.
Public networking services have evolved from fixed telephone networks, run by local
telephone operators which had national or local monopoly and offered services defined
by the operator to all customers at the same tariffs. Besides the passive local loops and
trunk cables, the network elemens consist(ed) of access devices, local exchanges,
hierarchical switching components and transmission systems, based on international
standards and supplied by different vendors. Network of the local teleoperators were
connected together by national and international switches. Today, telecommunication
networks are mainly digital, sometimes even down to the customer premises equipment.
Running and planning a stable (monopolistic) circuit switched telephone network used
to be a quite straight-forward task.
Today the basic network is also used to carry data, mobile communications and voice
from value added services. New services (data, mobile communication, the Internet,
value added services) have grown very rapidly (in industrial countries), making the trend
based capacity planning useless. Also the nature of the traffic is changing from constant
bit rate to variable bit rate and bursty (the traffic profile of LAN interconnections, the
Internet access, video conferencing, MMS and GPRS data is far from constant).
The Open Network Provisioning by the European Union opened telecommunication
markets to national and international competition in 1995. An operator (excluding some
minor EU member countries, which have an adaptation period) must lease trunk and
access capacity to all service providers at a reasonable price. Even a more radical
deregulation development took place in the USA, where the new Telecommunications
Act in 1996 opened the US communication markets, including local, long distance and
international calls, Internet, data and value added services to various parties like Local
Exhange Carriers, Inter Exhange Carriers, Cable TV companies, broadcasting
VANHA MAANTIE 6
02650 ESPOO
[email protected]
ISO NETWORK MANAGEMENT
56
MATTI PUSKA
companies and Interner Service Providers (*. Competitors have developed a wide variety
of new services. One of the outcomings of the international deregulation is series of
merges, acquisitions and alliances. The technical aspect of the business development is
first, that new service providers (** use leased capacity (and network elements) from
various Local and Inter Exchange Carriers (formely managed by the owner), combined
with the central switches and billing systems run by the service provider itself. Second,
the merges rise problems to integrate network management systems from different
companies, developed separately. Third, heavy competition promotes costeffectiveness (taking advantadge of all the technical aids available), customer
satisfaction (based also on the technical quality of the service) and rapid development
of new services (needing new kinds of management information).
Network Management Systems for telecommunication networks can be divided into the
following categories (see Figure 30):
• Basic Customer Support systems provide monthly report generation and
Service Desk systems, receiving toll free calls from existing customers for service
orders and changes.
• Element Management Systems (EMSes) manage individual devices. These
include management of basic access devices, switching and transmission systems
and service specific EMSes, for example for Intelligent Networks (like x700/x800
services), leased data lines and Virtual Private Networks (VPNs). An EMS
typically offers fault management, trouble ticketing system, performance statistics
and problem resolution aids and provides mainly element layer views. Often an
Element Management System is vendor specific, relative inexpensive solution
which only needs a part time operator.
• Integrated Network Management System (INMS) integrates different vendor
specific EMSes into a single management interface. An EMS outputs its
information, which is received and handled by the INMS and coordinated with
data from other EMSes. The INMS also offers a standards based protocol
interface, at least upstream. An INMS provides mainly network layer views.
*) US Regional Bell Operating Companies are not allowed to offer inter LATA services until they open their Local
Access Transport Area for competition.
**) The old national monopolies tended to favour the local telecommunications industry (Siemens in Germany,
Alcatel in France...). New voice, mobile and value added operators do not have the historical burden, instead they
often tend to choose a supplier that is different from the worst national competitor. This has opened much business
opportunities to new (Finnish!) manufacturers like Nokia and Tellabs.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
57
MATTI PUSKA
• Multi vendor Ingegrated Network Management System is the manager of the
management systems, providing a single user interface and console for network
wide control and observation tasks. A multi vendor IMNS is an expensive system
(of the range of hundreds of thousands of Euros) which is normally situated in the
Network Control Center and operated by the specialists 24 hours a day, 7 days a
week. The system offers the big picture: status information and statistics of the
whole network and all services.
• Operations Support System (OSS) integrates network management with
business processes. Typically, the OSS system includes software tools for sales,
marketing, provisioning, product development and billing. High-quality support
systems make it possible to differentiate and customize services according to the
customer needs, although services are based on the same network infrastructure.
An OSS provides service and business management views to the network.
User Interface
OSS
Integrated Network
Management
System
DB
Element Management
System
Managed Objects
Transm.
system
Figure 30: Network management hierarchy in telecommunication networks.
Users of a public telecommunication network do not accept breaks. To provide full time
usability, redundant network design is used. Redundancy makes the network more
complex, and it is harder to get the full picture at a glance. Private corporate
telecommunication networks (consisting of Private area Branch Exhanges, multiplexers
and leased line trunks) are often more tolerant of faults, because the public telephone
network can often be used as a backup. Concerning the corporate networks, the problem
VANHA MAANTIE 6
02650 ESPOO
[email protected]
58
MATTI PUSKA
is to what extend the components of the public network should be included into the
private management concept.
Seconds
Milliseconds
Microseconds
Load Bal.
& Distr.
Minutes
Parameter
tuning
Hours
Billing
Days
Design
Weeks
Problem Determination
Trends
Analysis
Years
Capacity
Planning
Figure 31 presents some of the times required to accoplish a selected network
management task /9/. Services like trend analysis and capacity planning do not require
fast observations and responses, so they are best done with network management
systems. On the other hand, load balancing and distribution, as well as parameter tuning
require a second or faster response times. Broadband technologies like ATM and SDH
offer a rich set of functional and performance monitoring information, but the NMS
system must select only the relevant data for observation. Trivial routing, rerouting and
parameter tunig tasks are often done at the component level without NMS intervention.
Figure 31: Examples of service times requirements of some NMS services.
4.1.2 The TMN framework
Telecommunications Management Network is an ITU standard (ITU-T M.3010 in
1992), including ISO management components, and service and protocol specifications
for telecommunication networks. The functional areas for TMN management are the
same as presented previously (see chapter 1.2). The framework is based on the
management/agent concept, including the following building blocks (see Figure 32):
• Network Elements (NE) offer data carrying capacity and present management
needs. The network of NEs provides circuit and packet switching services for user
data.
• Data Communication Network (DCN) is a separate packet switching network
for NMS messages. It supports the ISO protocol stack and the application
protocols used in TMN.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
59
MATTI PUSKA
• TMN manageable NEs are connected directly to the data communication
network through a Q interface. A Q adapter (QA) is used to connect older
network elements which do not directly support TMN.
• Network management tasks are carried out by an Operations System (OS),
which normally is a combination of hardware and software. It offers fault,
configuration, accounting, performance and security management services.
• Network managers use the OS functions through a workstation (WS), which
offers the necessary user interface for network configuration, alarm logging etc.
• Mediation Device (MD, not shown in the figure) performs protocol conversion
between different management systems connected on the same DCN.
Telecommunications
Management Network
Operations Systems
Qx
Workstation
Data Communication
Network
F
X
Qx
Qx
Q3
Qx
QA Q Adapter
M
Transm.
system
Q3
QA
M
Transm.
system
Network Elements in the Telecommunication network
Figure 32: Telecommunications Management Network architecture.
The TMN architecture also defines the following interfaces:
• Q3 interface is a full OSI layer 1 - 7 interface between the DCN and the
management elements
• Qx interface is an interface between a TMN element and the Data
Communication Network, which doesn't provide a full OSI layer 7 TMN protocol
support.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
60
MATTI PUSKA
• F interface is the interface to a management workstation (which provides user
interface)
• X interface is the interface between two TMN systems
• M interface (actually outside the TMN scope) lies between a Q Adapter and the
non-TMN device.
Management services are defined in Common Management Information Services and
operations for network elements are send with Common Management Information
Protocol messages. These are covered in more detailed in the next chapter. /10/
4.2 CMIS and CMIP
4.2.1 CMIS Services and CMIP Messages
CMIS is a set of standard management services. It specifies types of requests,
responses and notificiations and what they can do. CMIP is the management protocol,
which defines how requests, responses and notifications are encoded, and operations
which are used to transport messages. A CMIP message usually specifies the target
managed object. CMIS services are encoded using ASN.1.
CMIS specifies the following services. All services support confirmed request
operations, which always requires a response (either a positive or a negative). Some
operations also support unconfirmed operations where a response is not expected. The
services specified by CMIS are:
• M-Get service, used by a manager to request for information from an agent. This
service uses M-Get Request and M-Get Response primitives which are mapped
into CMIP messages (m-Get request PDU, m-Linked-Reply response PDU and mGet response PDU). Messages caused by an M-Get service are always confirmed.
• M-Cancel-Get is used by the manager for cancellation of a previously assigned
request. Primitives are, accordingly, M-Cancel-Get Request and M-Cancel-Get
Response. Also M-Cancel-Get service uses only confirmed operations.
• M-Create, used by a manager for an object creation by an agent. Also the
creation service is always confirmed.
• M-Delete is used by a manager for one or multiple object deletion by an agent.
This service is always confirmed.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
61
MATTI PUSKA
• M-Set, which is used by the manager for an agent to set an attribute value of a
managed object to a specified value. This service can use confirmed or
unconfirmed operations.
• M-Action, used by a manager to request, that an agent invokes a specified
behavior supported by a managed object. This service can use both confirmed and
unconfirmed operations.
• M-Event-Report is issued by an agent to send a notification information to a
manager. These operations can be confirmed or unconfirmed. The agent uses MEvent-Report Request primitive and m-Event-Report request PDU or m-EventReport-Confirmed request PDU. In the latter case, the manager confirms the event
report with a m-Event-Report response PDU.
Manager and agent implementations are not required to support all CMIS defined
services. When an ISO manager and an ISO agent first establish communication, they
agree on the types of services (Functional Units) which can be used by them.
Functional Units include multipleObjectSelection, multipleReply, filter, kernel,
confirmedCancelGet and extendedService. The first two are used for scoping, i.e.
directing a single request to several managed objects. Before carrying the request, the
agent can use filtering to make sure that the request is intended to this specific agent.
The kernel unit defines a minimum set of services every ISO manager or agent must
support.
4.2.2 TMN Protocol Stack
As shown in Figure 33, the full Q3 protocol stack, used in TMN systems, includes the
following protocols from up to down:
• CMISE (Common Management Information Service Element) Application part,
that provides TMN services
• CMIP, that forms the application layer PDUs
• ROSE (Remote Operations Service Element) for application layer PDU delivery
and ACSE (Access Control Service Element) for application-to-application
communication
• ASN.1 encoding on the Presentation Layer
• X.225 on the Session Layer
• connection oriented ISO TP4 (Transport Protocol 4), also called Connection
Oriented Transport Protocol (COTP), or sometimes TP0 aka ConnectionlessMode Transport Protocol (CLTP) on OSI Layer 4
• ISO IP (Connectionless-Mode Network Protocol, CLNP) on the Network Layer
VANHA MAANTIE 6
02650 ESPOO
[email protected]
62
MATTI PUSKA
• any Layer 2 and Layer 1 interface, for example connectionless LLC Type 1 and
CSMA/CD on 802.3 LANs.
------------ MAC Header -----------MAC: Destination: 00-E0-29-15-67-D9
MAC: Source: 00-40-43-F7-D8-EA
MAC: Length: 101
MAC: FCS: 065FB4CD
------------ LLC Header -----------LLC: Dsap: 0xfe (254)
LLC: Ssap: 0xfe (254) Command
LLC: Unnumbered frame: UI
(3)
------------ CLNP Header -----------CLNP: Protocol Identifier = Full ISO8473 CLNP (0x81)
...
CLNP: Src Address length = 20
CLNP: Src Address format = ISO DCC (Binary) (0x39)
CLNP: Src Address = 0x246F00000116000000010001123456789ABC00
CLNP: Data Unit Identifier = 26100
CLNP: Segment Offset = 0
CLNP: Total Length = 98
------------ COTP Header -----------COTP: Length Indicator = 4
COTP: TPDU code = Data (0xF0)
COTP: DST-REF = 0efb
COTP: EOT = 1
COTP: TPDU-NR = 123
------------ SESS Header -----------SESS: SI = Give Tokens (1)
SESS: SI = Data Xfer (1)
SESS: User Data Length = 32
------------ PRES Header -----------PRES: PDV List [0]
PRES:
Context Identifier = 3
PRES:
Single-ASN.1-Type
------------ ROSE Header
ROSE: rors-apdu
ROSE: invokeID = 308
ROSE: operation-value = 3
------------
------------ CMIP Header
CMIP: Result = M-Get (3)
Figure 33: Q3 Protocol Stack.
------------
VANHA MAANTIE 6
02650 ESPOO
[email protected]
63
MATTI PUSKA
4.3 TMN Data Model
TMN specifies also an object oriented data model. The object oriented paradigm
provides more flexible, more intelligent and simpler modelling for complex objects than
tree structured OID tree used in SNMP. The TMN data model includes the following
concepts:
• A managed resource is a network device or a logical unit. We can think that a
managed resource is a real physical or logical device or piece of a device on the
managed network.
• A managed object class specifies the structure and behavior of a managed
resource. A class includes a name, attributes, behaviours, actions and
notifications. An attribute value may be read by M-Get and set by M-Set, an
action may be invoked by M-Action and the agent may send a notification by MEvent-Report service. Behaviours present the internal device operations, that are
directly invisible to the network managemen system.
• Inheritance is the relationship between the managed object classes. When a
derived class can inherit properties (attributes, behaviours, actions and
notifications) from its base class, inheritance forms a powerful means to define
class properties.
• A managed object or object instance is a view of a managed resource, which
presents the information needed to manage the resource. When we create an icon
for a managed resource on an NMS station, we create a named instance for a
given managed object class.
• Containment is a relationship between managed object instances. Containments
may present real world dependencies.
The CCITT X.721 Definition of Management Information (DMI) defines several
managed object classes, name bindings and support constructs. These classes are base
classes to be used for defining other classes. All start from the top which is the base
class for all other object classes. Top cannot be instantiated directly, but, for inheritance,
the objectClass and nameBindig attributes defined in top are supported by all classes.
All other classes are subclasses of the top. The Object Class Inheritance Tree represents
the inheritance relationships between managed object classes. The inheritance tree for
the managed object classes defined in the DMI is shown in Figure 34.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
64
MATTI PUSKA
top
discriminator
log
logRecord
eventForwardingDiscriminator
system
eventLogRecord
alarmRecord
attributeValueChangeRecord
relationshipChangeRecord
objectCreation- objectDeletionRecord
Record
securityAlarmReportRecord
stateChangeRecord
Figure 34: Object Class Inheritance Tree for DMI defined managed object classes.
The Object Identifier Tree contains node labels, using nonnegative integer values and
text labels. For example, the Object Identifier of the alarmRecord is:
{ top logRecord eventLogRecord alarmRecord }
The GDMO (Guidelines for the Definition of Managed Objects) guidelines provide
templates for defining managed object classes. The classes allow agents to describe
what information and services they provide and GDMO defines the format for this
information. For each managed object class, the following information is defined:
• attributes (types of data) supported by the (managed object) class
• operations (actions) supported by the class
• the behavior of the managed object
• notifications (types of unsolicited information) a managed object can send to a
manager.
GDMO follows the object oriented model. It includes two basic templates: the
MANAGED OBJECT CLASS (* and NAME BINDING, which are always
implemented. GDMO also defines several optional templates which may be referred by
the basic templates.The minimum MANAGED OBJECT CLASS template for our
example class is the following:
Router MANAGED OBJECT CLASS
REGISTERED AS { top system router }
VANHA MAANTIE 6
02650 ESPOO
[email protected]
65
MATTI PUSKA
GDMO definitions are recommended to be presented using UML (Unified Modeling
Language). The Class Diagram (Figure 35) presents the static structure of the system,
while the Object Diagram describes instances and their relationship. Figure 36 includes
an example of object diagram. /27/ /28/
Router
hostname
includes
1
defined_by
model
1
Chassis
chassisId
state
1...*
*
Psu
psuSerial
state
temp
*
ifType
state
inherits
*
1...*
1...*
CpuCard MemCard
processor
clockRate
load
*
EthCard AtmCard SerCard
slotId
speed
hd
1...*
includes
ram
rom
flash
defined_by
Config
runConfig
startConfig
show()
copy()
erase()
slotId
slotId
aalType
clockRate
qosParams encapsul
1...*
Sw
curConfig
1...*
IfCard
1
defined_by
Hw
1...*
Ios
version
size
show()
copy()
includes
1...*
Interface Interface Interface
intId
outOctets
intId
outOctets
intId
outOctets
shutdown() shutdown() shutdown()
Figure 35: UML Class Diagram presents class inheritange and associations.
Relationship between managed object classes and managed objects of the same and
different classes is called a containment, and it is defined by Management
Information Tree. The containment relationship is between the object instances, not
classes, and is capable of reflecting the real world hierarchy between resources. For
example, a router hardware contains chassis, a PSU, a CPU card, a memory card and
two interface cards, each of the latter containing two interfaces. The containment
relationship can also reflect the behaviour of the device, so when the router is off, we
cannot access an interface on an interface card in the router. In the ISO management, the
containment is not restricted to reflect physical containment of the managed resources.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
66
MATTI PUSKA
The containment relationship is used for naming managed object instances. A
subordinate object instance is named by an unambiguous combination of:
• the name of its superior object
• a pair of an identifier and a value of one of the subordinate object attributes (the
naming attribute).
Following the hierarchy, the superior object instance is named relative to its superior.
This hierarchy is called the Management Information Tree (MIT). Figure 36 shows an
example of a MIT. The figure also shows an example of an object instance name
(Distinguished name) { hostname=Evitech123. model=4006. ifType=eth. slotId=1.
intId=1/0 } /10/ /27/
hostname:
Evitech123
model:
4006
:1234567
:24680
intId:1/0
ifType:
eth
:ser
slotId:1
:2
:1/1
:2/0
:290702
:68030
:16777216
:290702
:V12R06
:2/1
Attribute Value=1/0
Attribute Identifier=intId
Object DN={hostname=Evitech123.model=4006.ifType=eth.slotId=1.intId=1/0}
Figure 36: A Management Information Tree example.
4.4 Management Systems for Telecommunication Networks
4.4.1 Public Telecommunication Networks
Element Management Systems by different equipment manufacturers offer fault,
performance, configuration, accounting and security management functions for mobile
networks, transmission and switching systems and broadband networks. Often all
management functions and applications for a network are integrated into a single
system, as shown in Figure 36.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
67
MATTI PUSKA
DB
Import
Export
CDB
access
Central
DB
SNMP
Proxy
PaBX
If.
Management Application Platform
Fault Perf. Conf. Acc. Phone
Mgmt Mgmt Mgmt Mgmt Dir.
etc.
Security Management
Figure 36: Element management platform for PaBX's. /12/
As device management systems for LANs, also the Element Management systems
provide autodiscovery, device inventory, cental database and hierarchical network maps,
down to the module level. Simple element managers might use an (effective!) character
oriented user interface, but more sophisticated systems use graphical icons and provide
the command shell only for device configuration.
Separate Element Management systems can be integrated with an umbrella management
system (Manager of Managers). This means that the element management systems
provide a standard based interface for the higher layer management. It receives and
evaluates alarm reports generated by the EMSes, performs status overview of the entire
public telephone network, and provides management functionality for simple agent
based network components (Figure 37). Also private packet switched data networks are
often integrated under the common umbrella.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
68
MATTI PUSKA
Umbrella manager function
Mux
Host
mgmt mgmt
function function
Proxy Agent
P r o x y A g e n t s
Mgmt for
mobile systems
Uplink
HLR VLR AC
ATM
manager
PaBX nw
manager
Data network
manager
EIR
mux
Downlink
Base
Transmitter
Station
SNMP
Agents
Base
Station
Controller
Mobile
Switching
Center
Operations &
Maintenance
Center
Mobile Systems
ATM
PaBXs
Mux and Hosts
Private Telecommunication Network
Private Data Networks
Figure 37: Manager for the Managers.
Networks managed by the Element Management and umbrella management systems are
used to offer, provide and invoice services. An Operations Support System (OSS)
widens the perspective of network management from technical aspects to business
processes. The OSS provides software tools for the following tasks:
• customer acquisition: information services for preparing offers and selling
existing and new services to existing and new customers. OSS services in this
field provide, for example, rough and detailed implementation plans for customer
specific services, including trunk and equipment capacity, realistic time table and
cost analysis.
• order management for order input and tracking, and project management tools.
The OSS interpretes customer orders into electonic work orders, and also links
data from and into project with labour cost bookkeeping.
• product development and service provisioning for designing new services,
including cost analysis and simulation.
• inventory management, providing usage, service history and reliability
information. The equipment inventory database is used for most of the above
mentionned tasks.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
69
MATTI PUSKA
• network management, providing views of network operation and performance,
from the customer/service perspective. The data originated from the technical
NMS system is further processed to provide business oriented information.
• trouble management, providing network surveillance, alarm handling and
trouble ticket processing. Again, technical NMS data is projected into service and
customer specific information.
• billing and customer care, to automatically generate periodic bills and reports to
the customer. Reports include statistics about network usage, availability and
other quality parameters. The data is also used for bookkeeping and further
processed into managerial reports, from account manager up to the CEO level.
• automated business processes, that synchronize all of the above, using an
electronic workflow management system.
Technically, the OSS operating environment is a heterogenous multi-platform multivendor system, including network elements, NMS systems and financial systems. The
user base is not only technical experts, but also sales persons, department managers,
directors, and also people from the customer and partner organisations. From the
business perspective, a state of the art OSS systems can help the operator to success in
the international competition, to cut down operational costs, to develop and implement
new customer oriented services and to offer premium customer satisfaction.
Today's deregulation and competitive environment sets up need for flexibility and
customer awareness of teleoperators. For service providers, this leads in seeking new
ways to differentiate service offerings, introducing new services rapidly and becoming
service oriented (providing different service level agreements instead of bulk capacity
leasing), and reducing operating costs (also for network management) at the same time.
One technical trend is the transition from circuit switched networks to packet switched
IP networks (Voice over IP, secure Virtual Private Networks, 3G mobile networks),
which offer a quaranteed (even differentiated) quality or service. From the technical
point of view, telecommunication networks become closer to computer networks and
TCP/IP LANs and intranets. Based on the IP network infrastructure, the service provider
will offer different services (like VPNs, eCommerce, cost-effective Internet telephony,
Internet Access, broadband services...) for different customers. This certainly brings new
demands for the network management: the NMS system must offer real time service
oriented data from new types of network devices. /12/
VANHA MAANTIE 6
02650 ESPOO
[email protected]
70
MATTI PUSKA
4.4.2 Private Corporate Networks
Medium- and large-sized companies have built their own PaBX networks, often using
leased lines or own fiber capacity (power, broadcasting and railroad companies).
Switching, transmission and multiplexing systems have been managed by system
specific element management systems. Often LANs are interconnected into corporate
intranets, allocating a part of the trunk capacity for data and managed by an SNMP
device management systems. Some larger companies have also put up higher layer
Integrated Network Management Systems.
The same trends of integration and mobility also apply to corporate networks. Some
companies have decided to oursource their data and voice networks and the network
management and use value added services and the expertese from the selected service
provider. Some companies decided to run and develop their own network themselves,
and clearly they also need sophisticated network management systems.
4.4.3 Example Products
Our first example of network management software for telecommunication networks is
Nokia NMS/2000 which is the management solution for network elements and systems
of cellular networks made by Nokia. As shown in Figure 38, the NMS/2000 is a
Client/Server system. Communication servers are gateways between the managed
objects and the management system, database servers store information about the
managed network elements and application servers run the terminal sessions for the
clients. Operators are sitting by a UNIX or a PC workstations or an X Terminal, and run
an X terminal session on the application server. The server components can be
combined for simplicity and dublicated for redundancy. The management elements are
connected together with a shared media or switched Ethernet LAN, using the TCP/IP
protocol stack. The managed objects are accessed through a DCN network, using either
TCP/IP or ISO protocols.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
71
MATTI PUSKA
Base
Station
Controller
Database Server
Application Server
Communication Server
DB
HLR VLR
AC
Base
Transmitter
Station
EIR
Mobile
Switching
Center
X.25 or LAN:
TCP/IP or ISO
LAN: TCP/IP
PC workstations
X Terminals
UNIX-workstations
Figure 35: Elements of a Nokia NMS/2000 network management system.
The NMS/2000 system provides the following management applications:
• An NMS Desktop, which is a collection of applications for viewing, locating
and handling managed objects and starting applications.
• Fault Management includes graphical tools for viewing active alarms and an
alarm manual and for searching the alarm database.
• With Performance Management, the cellular network can be monitored and
reported. Continuous monitoring looks at the quality of service of the network and
periodical reporting provides information for network planning, optimising and
dimensioning.
• Radio Network Management includes tools for integrating sites, modifying
the network configuration and setting the radio network parameters.
• Configuration Management includes applications for hardware and software
configuration.
• System Management includes tools for system administration tasks, like user
management, user profile configuration, granting specified management
authorities for managers and checking the status of the management database.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
72
MATTI PUSKA
• For a specific task, the operator can initiate a remote MML Session (ManMachine Language) to any network element. The vendor specific MML command
language is often the most effective user interface for an experienced operator.
4.5 Summary
Figure 39: Summary of chapter 4.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
73
MATTI PUSKA
Review
CMIP is a complex NMS protocol which is used in large and complex
telecommunication networks. Competition situation, service differentiation and merges
require technical means to gain customer satisfaction. Different categories of
telecommunication NMS include vendor specific enterprise NMS, integrated NMS with
standard interfaces, multi-vendor INMS, which consolidate NMS systems to a single
user interface and Operations Support System, which integrate NMS with business
applications.
The Telecommunication Management Network framework includes manageable
network elemets for user data, packet switched Data Communication Network,
Operations System, workstations and standard interfaces between building blocks. The
TMN data model is an object oriented model to describe managed devices, including
classes with inheritange and managed object instances with containment relationship.
The GDMO guidelines provide MANAGED OBJECT CLASS AND NAME
BINDINGS templates for defining managed object classes, and Management
Information Tree defines the hierarchy between superior and subordinate object
instances. CMIS defines a set of standard management services, while CMIP is the
management protocol, defining messages, message encoding and operations to transport
messages.
Element Management Systems, often vendor specific, provide a subset of fault,
performance, configuring, accounting and security management functions for
telecommunication networks. Separate Element Management Systems are integrated
with a standards based Integrated Network Management System. Operations Support
Systems integrate the technical NMS with business applications. OSS tools may include
tools for customer acquisition, order management, service development and
provisioning, billing and reporting and trouble management.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
74
MATTI PUSKA
Quiz
• What common trend for telecommunication service market in Western Europe and in
Northern America took place in 1990s?
• What is the purpose of Integrated Network Management System?
• What is the purpose of Operations Support System?
• In what kind of networks is the OSI NMS protocols normally used?
• Give an example of a service provided by OSS.
• Sketch a figure, showing relationship between various TMN (Telecommunication
Management Network) architecture components: DCN (Data Communication
Network), NEs (Network Elements), OS (Operations System), QA (Q Adapter), WS
(Workstation)
• What is the difference between the NE network and the DCN?
• Is the TMN data model object oriented?
• What is the difference between CMIP and CMIS?
• What is the purpose of GDMO (Guidelines for the Definion of Managed Objects)?
• What functions does an Element Management System offer?
VANHA MAANTIE 6
02650 ESPOO
[email protected]
75
MATTI PUSKA
5
Distributed Management
Task Force
This chapter includes:
• DMTF organisation and initiatives
• Web Based Enterprise Management
• Directory Enabled Network
• Desktop Management Initiative
• CIM information model
5.1 General
DMTF (Distributed Management Task Force) is an industry organisation for
promoting management standards for desktop, enterprise and Internet
environments. It was founded in 1992 by 3Com, Cisco, Hewlett-Packard, Microsoft,
Sun and others, and at the time of writing (6.5.2003) includes more than 150 companies
and public organisations. As other vendor forums, also DMTF promotes its goals by
guiding and coordinating standards development and ensuring compatibility between
implementations. DMTF works with close co-operation with IETF and other
standardisation bodies, IETF concentrating on protocol issues and DMTF on integration
of the management environment.
DMTF initiatives, standards and technologies form an architecture to enable business
operations and reduce IT operational consts. The DMTF initiatives include the
following:
• CIM (Common Information Model), an object oriented general and
implementation-neutral information model for management information.
• DMI (Desktop Management Initiative), including a framework for mobile,
desktop and server computer management and tracking.
• WBEM (Web Based Enterprise Management), standards for unifying network
management of enterprise IT environment.
• DEN (Directory Enabled Network), mapping CIM concepts to a directory and
integrating management information with other WBEM elements.
• SMBIOS (System Management BIOS), including BIOS extensions for Intel
based computers to provide low-level hardware information.
• ASF (Alert Standard Format), a system for collecting and sending system health
information during low-power and OS-absent states. ASF also accepts
commands, like remote power up, power down and reboot.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
DISTRIBUTED MANAGEMENT TASK FORCE
76
MATTI PUSKA
DMTF standards are widely approved and implemented by the industry. Examples of
DMTF technologies include CIM and WBEM in CiscoWorks2000, HP OpenView and
Oracle system management for integration with other management tools, DMI interfaces
for desktop management in Dell, HP and other leading PC vendors, Windows
Managemen Instrumentation (WMI) management interface and tools, based on CIM, by
Microsoft, and ZENworks by Novell, based on DMTF technologies like DMI, CIM,
SMBIOS and many others. /31/ /32/
5.2 Web Based Enterprise Management
WBEM (Web Based Enterprise Management) is a set of network management
technologies, which are developed to provide a unified method for NMS in large
complex enterprise networks. WBEM was published in 1999 by Interop Workgroup.
Although based on Client/Server model, WBEM realises the fact that modern network
components have a lot more processing power, more detailed information of their status
and better resources to take an active role on network management as a single NMS
station. As shown in Figure 40, WBEM includes the following system components:
• CIM NMS support in managed network devices (CIM Servers). The server
receives and processes CIM requests and returns response messages. It consists
of CIM Object Manager (CIMOM), responsible of communication with other
CIM system components, Providers, which instrument the CIM Schema and
provide interface to the real world network component, and CIM information
model.
• CIM Client, which issues CIM requests to servers and receives responses. The
client provides the User Interface for network engineers.
• HTTP protocol between the Client and the Server. CIM Operations over HTTP
defines a protocol independent way to transport XML/CIM messages inside
HTTP PDUs and perform CIM operations.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
77
MATTI PUSKA
Managed Network Elements
CIM Server
CIM
CIM Server
Providers
CIMOM
CIM
Providers
CIMOM
CIM Ops over HTTP
Network
Engineer
CIM Client
Figure 40: WBEM Client/Server system.
Practical WBEM implementations offer tools for management of a complete network,
consisting of different devices from different manufacturers. The user (=network
engineer) uses a Web browser to communicate with the manager system. The manager
system collects data from managed devices, using the standards based CIM or SNMP
protocols. The data is analyzed to produce network maps and statistical graphs. Network
element and configuration data is stored in a central database. The user issues HTML
requests to the Web server that requests data from the management database with user
information for data security (see Figure 41).
VANHA MAANTIE 6
02650 ESPOO
[email protected]
78
MATTI PUSKA
Manager System
Web Server
Manager
Information
Reposity
DB
Configurator
Collector
Analyzer
Security
Grapher
HTTP
Server
Reporter
HTTPS
Managed
Devices
CIM Server
CIM
Providers
CIMOM
CIM Operations over HTTPS
Browser
Figure 41: An example WBEM implementation.
The Client software on a management workstation is a Web browser, supporting user
authentication, forms and Java. The user interface is coded using HTML, including
requests to the database for network, configuration, statistical or report information. The
Web server then receives the data, parses the final HTML code and sends it to the
browser with the attachement files, to be displayed on the browser window. The security
system takes care of the user authentication and prevents unaccidental or illegal access
to confidential information (like router or firewall configurations!).
As shown in Figure 42, the CIM interface can be used between an NMS station and the
managed element, as well as between two NMS systems. The CIM data is encoded with
XML and transported with standard Internet protocols. A WBEM management system
can also communicate with legacy SNMP agents, using ASN.1 coded MIB structures, or
with propriatory management systems. The WBEM management system provides
standard browser interface, using HTML encoding and HTTP/HTTPS protocol.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
79
MATTI PUSKA
Common Browser Interface
UI
HTTP/HTTPS
(HTML)
NMS
SNMP/MIB
(ASN.1)
CIM
CIM
HTTPS/CIM
(XML)
Propriatory
protocols
Managed
Devices
and Systems
SNMP Agent
CIM Agent
Management Agent
Figure 42: WBEM standard interfaces, protocols and encoding.
WMI (Windows Management Instrumentation) is the Microsoft implementation of
WBEM, that includes providers, like registry provider and SNMP provider, between the
WMI and operating system, applications and other computer system components. WMI
is an integral part of modern Microsoft OSes, and it can be used by desktop
management tools, like Microsoft SMS and third party management software. Microsoft
also offers free tools, like the WMI Object Browser for Windows 2000, to access the
WMI data. As demonstrated in Figure 43, WMI offers very detailed information about
Windows 2000 settings. /33/ /34/ /35/
VANHA MAANTIE 6
02650 ESPOO
[email protected]
80
MATTI PUSKA
Figure 43: Accessing information about daylight saving time setting on a Windows 2000 host
using Windows Management Instrumentation.
5.3 Directory Enabled Network Initiative
5.3.1 DEN Motivation and Overview
Traditional device management systems for data networks provide information about
the status of network devices and a general-purpose launch pad for configuration tools
(Telnet, Web Browser, TFTP download). Device management systems are based on the
assumption that network management intelligence is concentrated on the NMS stations,
and the network devices only passively reply on requests. While a single network is
used for web surfing, Intranet pages, business critical data applications, real-time voice
and video and multicasting video distribution, more and more processing power,
intelligence and more complex configurations are needed in devices. Differentiated
VANHA MAANTIE 6
02650 ESPOO
[email protected]
81
MATTI PUSKA
services based on user and application data should be offered, and network
administrators need detailed access and service level control.
DEN (Directory Enabled Network) is DMTF initiative to provide building blocks for
more intelligent network management by integrating CIM technologies with a
directory to provide a unified system and service management infrastructure. The
directory is an excellent way to store all information about system components,
organisations, users, resources and management capabilities in a single reposity.
Common identities, stored in the directory, may be used for user authentication and
profiling, providing differentiated services and inventories. All data about users, user
authentication, resources, user rights, organisation structure and network devices may be
concentrated on a single directory, and network access devices, Client/Server systems
and network configuration could use this single directory information, at least in theory.
/36/ /37/
DEN is based on an ad-hoc Working Group document by Microsoft and Cisco in 1998.
It defines:
1: An extension schema of CIM information model for network elements and
services. The DEN information model is repository-independent.
2: Mapping of information to a format that can be stored in a directory using IETF
LDAP (Lightweight Directory Access Protocol) or ISO X.500.
5.3.2 DEN Schema
The DEN network schema extension specifies a CIM extension for describing static and
dynamic information about network elements and services. The DEN Schema includes
classes from CIM, X.500 and DEN. DEN integrates existing SNMP, X,500, DNS,
DHCP, RADIUS (Remote Authentication Dial-in User Service) and CIM data with
DEN extensions and provides an integrated a uniformed information model, shown in
Figure 44. Devices or systems managed by DEN don't have to support LDAP or other
new protocols.
Users, applications and services are abstracted through profiles, that tell the system what
should be done. Policies define what resources can be used by a user by an application
or a service. A policy instructs network nodes how to manage requests for network
resources. X.500 Person represents an employee or remote user, a client for a network
service or an owner of a network device or service. Users may be grouped and an
organisation is a business entity that includes devices and services. Altogether, DEN
Schema forms an extensible service oriented framework. /38/ /39/
VANHA MAANTIE 6
02650 ESPOO
[email protected]
82
MATTI PUSKA
X.500
Top
CIM
ManagedSystemElement
Configuration
Application
Person
Group
Software System
Location
Check
Action
Organization
Product
Service
FRU
Protocol
Profile
NetworkDevice
NetworkProtocol
NetworkMedia
Policy
LinkedContainer
NetworkElement
DEN
Figure 44: Classes in DEN base schema. (*
5.3.3 Directories
A directory is a general purpose data storage to hold information of groups of objects.
Objects on a directory are organised hierarchically on a Directory Information Tree.
Object has attributes, and each attribute has restrictions and value. Each attribute has at
least one Distinguished Name with a value and zero or more nondistinguished values.
Data may be retrieved from the directory either by specifying an exact set of criteria
(attribute = value) or by a general set of criteria, describing the characteristics of the
information. For example, my personal data could be found either by seeking for a
person with a familyname of Puska and firstname Matti or by seeking for an Evitech
employee working as a teacher in Information Technology study program, giving a
course of Network Management Systems.
*) Network Device is not an actual class, but an abstraction of changes to existing CIM classes to realize physical
characteristics of real world network devices.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
83
MATTI PUSKA
Directories have the following characteristics:
• Information is normally read more frequently than written, and performance may
be optimized for read and search operations.
• Information is stored in a hierarchical fashion. While directory stores objects,
the parent-child relationship is based on containments.
• Information is based on attributes, and directory schema defines class hierarchy,
attributes, attribute types, rules, restrictions and access rights.
• A directory provides a unified namespace, and Distinguished Name is used to
identify an object. A common namespace makes it possible to integrate different
type of information, like users, applications, servers and network devices.
• Directories may be distributed by replicating the single master data to multiple
physical storage components. On a properly designed distributed directory, data
integrity is quaranteed.
Currently directories are often used to store and search personal information in a
company: organisation hierarchy, empoyee data and contact information. Modern
network operating systems organise user base and network resources in directories, like
Active Directory (AD) for Microsoft Windows 2000/2003 server and Network Directory
Service (NDS) for Novell NetWare. When using standard protocols for the directory and
amending it with data about network devices, differentiated services may be offered for
users with a single logon. Figure 45 shows an example LDAP namespace hierarchy of
Evitech. /38/ /40/
VANHA MAANTIE 6
02650 ESPOO
[email protected]
84
MATTI PUSKA
LDAP
ROOT
o=
stadia
ou=
admin
uid=
Karhu
ou=
auto
ou=
bio
uid=
uid=
Komulainen Nuutinen
c=se
c=fi
c=de
c=n
o=
evitech
o=
ncp
o=
hamk
o=
oulu
ou=
chem
ou=
dip
ou=
it
ou=
media
ou=
survey
ou=
People
ou=
Services
ou=
Labs
ou=
Groups
uid=
Puska
uid=
Pätynen
uid=
Sauren
uid=
Rahkonen
Figure 45: LDAP Namespace example.
5.4 Desktop Management Initiative
PC workstations consist of many components from different vendors (motherboard,
BIOS, OS, RAM, processor, PSU, Bus controller, display adapter, hard drives, CDROM/DVD drive, NIC...) which are assembled either by giant multinational companies
or by small garage enterpreneurs. When hardware and software are often upgraded, it
becomes impossible to keep a manual inventory of the PC platform in a company.
However, up-to-date information about memory, hardware, partitions and BIOS
configuration is often needed during an operating system or application software
upgrade rollover.
Desktop Management Initiative (DMI) is a standard supported by large PC
manufacturers and System Management vendors. It defines Application Programming
Interfaces (API) which are used by the management software to find out hardware and
software component and version information. As shown in Figure 46, DMI is based on
distributed client/server architecture, consisting of the following software components
and APIs:
• Local or remote DMI Browsers provide access to the DMI data from a local
application or from a System Management station, providing vendor specific
user interface.
• Management Interface Client is the counterpart of the DMI Browser. It is used
by the management application to access the managed PC.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
85
MATTI PUSKA
• Remote Procedural Call (RPC) is a standard way to run remote procedures.
RPC Server acts as a translator between the MI Clients and the MI Server.
• Management Interface Server is an API, that enables communication between
the MIs and the DMI Service Provider.
• DMI Service Provider is the primary software interface from the system
management application and the hardware, software and firmware components.
• Procedural Component Interface is again an API, that provides communication
from the DMI Service Provider to the Procedural Component Instrumentation.
• Procedural Component Insrumentations are vendor specific descriptions for the
access to the management data of their components.
• Management Information Format (MIF) describes the manageable
characteristics (=attributes) of hardware, software and firmware components,
that make up the computer.
HW
SW
FW
DMI Agent
DMI
Browser
Proc.
Proc.
Proc.
C Instr. C Instr. C Instr.
Procedural C. Interface
DMI Service Provider
Mgmt Interface Server
RPC Support
MI
MI Client
Client
(Local)
MIF
DB
DMI
Browser
Figure 46: Desktop Management Interface.
System management software, like HP OpenView, IBM NetView and Microsoft
Systems Management Server offers support for DMI. Normally they save the
workstation details in a database. Other system management tools include Unicenter
TNG from Computer Associates and Tivoli TME from IBM. These are system solutions
for IT which cover the network infrastructure, Windows, Win NT/2000 and UNIX
workstations, servers, software components and service networks. For example, the user
interface in Unicenter is based on application sceneries, providing information about
systems serving business processes. Also the HP OpenView has developed as a general
concept in system management, covering network devices, workstations, printers,
servers and client/server systems. /31/
SNMP and CIM network management frameworks can be integrated by mapping the
DMI data to SNMP Object Id's.. This is done by external DMI Subagent, DPI interface
VANHA MAANTIE 6
02650 ESPOO
[email protected]
86
MATTI PUSKA
(Distributed Protocol Interface) to the SNMP Agent and mapping files on the PC. In this
way the DMI data may be accessed from an SNMP management console.
5.5 Common Information Model
5.5.1 Overview
CIM (Common Information Model) is a formal way of representing real world
hardware and software elements. It follows the principles of object oriented
modelling, including classes, that describe types of things, and instances, that are things
with a defined type. Normally CIM is presented graphically with UML (Unified
Modeling Language) and coded with Managed Object Format (MOF).
A CIM Schema is an abstract model of an existing thing. A schema consists of a group
of classes with a single owner, and it is used for administration and class naming. The
basic CIM schema consists of the following components:
• CIM Core Model, general information model for all domains of management.
The core model includes general purpose classes, like
CIM_ManagedSystemElement, CIM_PhysicalElement and
CIM_LogicalElement, CIM_LogicalDevice and CIM_System.
• CIM Common Models, seven information models common to particular
management domains, but independent of technology. The Common Models
include Systems, Applications, Devices, Users, Networks, Policies and
Databases, defining classes like CIM_OperatingSystem and CIM_Service.
• CIM Extension Models, representing technology specific extensions of the
Common Model. Extension models are specific to environments, like operating
systems or device vendors.
5.5.2 Classes, Properties and Methods
The root class on the CIM Core Model is CIM_ManagedElement. This abstract class
includes only a few properties, i.e. class characteristics, namely Caption and
Description, which are inherited by the subclass CIM_ManagedSystemElement, which
again has subclasses CIM_PhysicalElement and CIM_LogicalElement. Subclasses may
introduce new properties, like Name, Status and InstallDate for
CIM_ManagedSystemElement. Classes may also have methods, which describe the
behavior of a class. An example is the Reset() method of CIM_LogicalDevice, which
includes also other methods. Subclasses inherit properties and methods from their
VANHA MAANTIE 6
02650 ESPOO
[email protected]
87
MATTI PUSKA
superclasses, but they may override the superclass definition, if necessary. Class
inheritance hierarchy is normally presented in the UML diagram with blue lines with
arrows pointing to the superclass. Figure 47 presents the class hierarchy of the CIM
Core Model. In the UML, a class is presented with a rectangle with two or three regions,
the uppermost for the class name, the second for properties, if any, and the third for
methods, if any.
ManagedElement
Caption
Description
Collection
Product
Configuration
StatisticalInformation
Setting
ManagedSystemElement
Name: string
Status: string
InstallDate: datetime
PhysicalElement
LogicalElement
Manufacturer
…
LogicalDevice
DeviceID
Reset()
System
Roles
…
Figure 47: Class hierarchy of the CIM Core Model. CIM_ at the beginning of each class name is
omitted.
A property is named with a list of the Schema, the Class and the Property, like
CIM_LogicalDevice.DeviceID which may hold any string variable, for example an IP
address. CreationClassName property defines the class of an instance.
5.5.3 Aggregatations and Associations
A CIM entity may be made up of aggregation of one or more other entities. An
aggregation has a name, its participants have roles, and an aggregation may have
restrictions about the number of participants on a specific role. For example, a System
may consists of multiple LogicalDevices acting as SystemDevices. In UML, aggregation
is often presented with green lines with a square showing the end of the larger entity and
the aggregation name near the center of the line. The allowed number of entities on a
specific role is also presented (1 for a single system, * for multiple LogicalDevices in
case of the SystemDevice aggregation).
VANHA MAANTIE 6
02650 ESPOO
[email protected]
88
MATTI PUSKA
Another relation between entities is association, which presents a relationship between
two or more objects. In CIM, an association really is a class with references, but it
doesn't affect the related classes. A reference is a pointer to other instances, and it
defines the role of an object on an association. In UML associations are presented with
red lines with the association name in the center and number of entities indicated in both
ends of the reference. Examples of associations are zero or one default setting, multiple
element settings and multiple element configuration for a
CIM_ManagedSystemElement. Figure 48 presents the full CIM Core Model with
classes, class inheritance, aggregations and asociations. We should pay attention to the
separation of physical and logical elements of the CIM_ManagedSystemElement and to
the fact that statistics is an association between a ManagedElement and
StatisticalInformation.
*
ProductParentChild
Collection
Product
MbrOf
Coll.
Dependency *
ManagedElement
*
Statistics
*
Configuration
Setting
Context
*
Product
Physical
E´lements
StatisticalInformation
ManagedSystemElement * Component
*
*
*
Rel.
Stats.
Setting
Element
Config.
ElementSetting *
*
*
0...1
DefaultSetting
* LogicalElement *
Logical
Synchronized
Identity
*
*
PhysicalElement
*
Realizes *
SystemDevice
LogicalDevice
System
Figure 48: CIM Core Model.
5.5.4 Common Models
The CIM Common Models are information models for technology independent
elements common to a particular management area, and they can be used as a basis for
management application development. Common Models profide base classes for the
following management areas:
VANHA MAANTIE 6
02650 ESPOO
[email protected]
89
MATTI PUSKA
• Systems, describing top-level system objects for a management environment,
presenting computer, application and network systems. The Systems Model
expands the CIM_LogicalElement with CIM_LogicalDevice,
CIM_OperatingSystem, CIM_Service and CIM_System classes with subclasses.
• Devices model discrete logical units on a system, not physical. The Devices
Model introduces subclasses CIM_UserDevice, CIM_Controller,
CIM_MediaAccessDevice, CIM_StorageElement, CIM_PowerSupply,
CIM_NetworkAdapter and CIM_Processors for the CIM_LogicalDevice,
presented by the System Model.
• Applications model represents details for software products and applications.
The application model uses the idea of application life cycle from Deployable,
Installable, Executable to Executing stages. The applications model also includes
association between a CIM_LogicalElement and CIM_Product. Product is not a
subclass of ManagedSystemElement, but a unit of purchasing and licensing
emphasizing the commercial aspect.
• Networks model represents aspects of the network environment, like network
topology, connectivy, protocols and services.
• Physical model provides representations of the actual physical environment.
Physical parts are not directly instrumented, but manipulated by logical system
elements, so most of the management environment is presented in logical
objects.
5.5.5 Extensions
Technology and vendor specific extensions to CIM Common model are encouraged. For
an extension model, a schema and class definitions are needed. For example Microsoft
CIM studio makes it possible to examine and create CIM classes. As shown in Figure
49, the CIM Common Model includes class hierarchy of CIM_ManagedSystemElement,
CIM_LogicalElement, CIM_LogicalDevice and CIM_Battery. The Microsoft Win32
extension to this includes for example Win32_Battery with a subclass
Win32_PortableBattery, including properties, methods and associations. As shown in
the Figure, the methods of Win32_PortableBattery include Reset and SetPowerState,
which are reasonable functions for a battery of a laptop computer. /31/ /41/
VANHA MAANTIE 6
02650 ESPOO
[email protected]
90
MATTI PUSKA
Figure 49: Some Win32 extensions to CIM Common model by Microsoft.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
91
MATTI PUSKA
5.6 Summary
Figure 50: Summary of Chapter 5.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
92
MATTI PUSKA
Review
Distributed Managent Task Force is an industry organisation, founded in 1992, that
promotes advanced management standards for desktop, enterprise and Internet
environments. Some DMTF standards are widely approved and implemented, while
other are still in development phase.
Web Based Enterprise Management (WBEM) is a unified NMS method for large
complex enterprise networks, based on the idea that modern network components have
much processing power, detailed information of their status and possibility to take an
active role on network management. A WBEM system consists of a CIM Client with a
Web browser, making requests, and CIM servers, listening for requests and returning
replies. A CIM server is a software component on managed devices, and consists of
CIM Object Manager (responsible of communication), providers (providing interface to
the network component) and CIM information model. The CIM interface may be used
between a network management system and managed components or between two
network management systems. A real WBEM implementation includes a manager
system, a Web server with manager information reposity, a workstation with a Web
browser, and of course managed network elements with CIM Server.
Directory Enabled Network initiative looks networks as a whole, including resources,
services, users and service levels. The focal point is an LDAP directory, which stores
network related information. DEN schema includes classes from CIM, X.500 and DEN
and forms an extensible service oriented framework.
Desktop Management Initiative is a standard, that defines an API for finding detailed
information about hardware and software components and settings on PC workstations
and servers. DMI Service Layer and Component interface on a DMI supporting host
provides possibility to retrieve static information through Management Information
Files and dynamic information through component agents. Most system and desktop
management software implement DMI and many large PC manufacturers offer DMI
support on their devices.
Common Information Model is an object oriented way to represent real world hardware
and software components. The CIM Schema consists CIM Core Model, Common
Models and Extension Models, and defines a set of classes. A class has a name and
optional properties and methods, which are inherited by the subclasses. Relation
between entieties are called associations and entities may be aggregated of one or more
of other entities. The Core Model defines a general information model, and more
detailed information of a particulat management domain is defined in Common Models
for Systems, Applications, Devices, Users, Networks, Policies and Databases.
Technology or vendor specific extensions are encouraged.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
93
MATTI PUSKA
Quiz
• Name a few founders of Distributed Management Task Force.
• How are the roles of an industry organisation, like DMTF, and a standardisation
organisation, like IETF, different?
• List the six DMTF initiatives.
• What is the purpose of Web Based Enterprise Management?
• List the system components on a CIM server, which listens for requests from CIM
Clients and reply with the requested data.
• How is the CIM data encoded?
• List the two usage areas for CIM interface.
• From which standards does the DEN Schema include classes from?
• Can DEN be used for user authentication?
• Can DEN be used for providing different services for different user groups?
• How is static hardware information provided in Desktop Management Initiative?
• How is dynamic hardware and software information provided in DMI?
• What does Common Information Model represent?
• What do CIM Common Models cover?
• What does a Method of a class describe?
• What does a Property of a class describe?
• What is inheritance in the CIM context?
• What are the CIM Extension Models for?
VANHA MAANTIE 6
02650 ESPOO
[email protected]
94
MATTI PUSKA
6
List of Acronyms
A
AAL5
ACS
ACSE
AD
AI
API
ARP
ASCII
ASF
ASN.1
AT
ATM
ATM Adaptation Layer 5
Association Control Service
Access Control Service Environment
Active Directory
Artifical Intelligence
Application Programming Interface
Address Resolution Protocol
American Standard Code for Information Interchange
Alert Standard Format
Abstract Syntax Notation One
Address Translation
Asynchronous Transfer Mode
B
BIOS
Basic Input/Output System
C
c
CA
CCITT
CEO
CGI
CIM
CIMOM
CLNP
CLTP
CMIP
CMIS
CMISE
CMOT
CONP
COTP
CPU
Country
Certificate Authority
Comité Consultatif International Télégraphique et Téléphonique
Chief Executive Officer
Common Gateway Interface
Common Information Model
CIM Object Manager
Connectionless-Mode Network Protocol
Connectionless-Mode Transport Protocol
Common Management Information Base
Common Management Information Services
Common Management Information Service Element
CMIP over TCP/IP
Connection Oriented Netwrok Protocol
Connection Oriented Transport Protocol
Central Processing Unit
VANHA MAANTIE 6
02650 ESPOO
[email protected]
LIST OF ACRONYMS
95
MATTI PUSKA
CRC
Cyclic Redundancy Check
CSMA/CD Carrier Sense Multiple Access Collision Detect
D
DB
DCN
DDNS
DEN
DHCP
DMI
DMTF
DN
DNS
DoD
DPI
Database
Data Communication Network
Dynamic Domain Name System
Directory Enabled Network
Dynamic Host Configuration Protocol
Desktop Management Initiative, Definition of Management Information
Desktop Management Task Force
Distinguished Name
Domain Name System
Department of Defence
Distributed Protocol Interface
E
EDP
EGP
EMS
ETSI
Electronic Data Processing
Exterior Gateway Protocol
Element Management System
European Telecommunication Standards Institute
F
FCS
FTAM
Frame Chech Sequence
File Transfer and Access Method
G
GDMO
GMT
GPRS
GSM
GUI
Guidelines for the Definition of Managed Objects
Greenwitch Mean Time
Generalized Packet Radio System
Groupe Spécial Mobile
Graphical User Interface
H
HTML
HTTP
HTTPS
Hypertext Markup Language
Hypertext Transfer Protocol
Secure Hypertext Transfer Protocol
VANHA MAANTIE 6
02650 ESPOO
[email protected]
LIST OF ACRONYMS
96
MATTI PUSKA
I
ICANN
ICMP
ID
IDE
IETF
INMS
IP
ISO
ISP
ITU
Internet Corporation for Assigned Names and Numbers
Internet Control and Message Protocol
Identification
Integrated Development Environment
Internet Engineering Task Force
Integrated Network Management System
Internet Protocol
International Standardisation Organisation
Internet Service Provider
International Telecommunications Union
J
JMAPI
JTC1
Java Management Application Programming Interface
Joint Technical Committee 1
L
LAN
LATA
LDAP
LLC
Local Area Network
Local Access Transport Area
Lightweight Directory Access Protocol
Logical Link Control
M
MAC
MAU
MD
MIB
MIF
MIT
MML
MMS
MOF
MRTG
MSB
MTBF
MTTR
MTU
Medium Access Control
Multistation Access Unit
Mediation Device
Management Information Base
Management Information File
Management Information Tree
Man-Machine Language
Multimedia Message System
Managed Object Format
Multi Router Traffic Grapher
Most Significant Bit
Mean Time Between Failures
Mean Time To Repair
Maximum Transmission Unit
N
NDS
NE
NIC
NMC
Network Directory Service
Network Element
Network Interface Card
Network Management Center
VANHA MAANTIE 6
02650 ESPOO
[email protected]
LIST OF ACRONYMS
97
MATTI PUSKA
NMS
NOC
NOS
Network Management System
Network Operations Center
Network Operating System
O
o
OID
OS
OSI
OSS
ou
Organisation
Object Identifier
Operating System, Operations System
Open Systems Interconnection
Operations Support System
Organisation Unit
P
PaBX
PDU
PSU
Private area Branch Exhange
Protocol Data Unit
Power Supply Unit
Q
QA
Q Adapter
R
RADIUS
RAM
RFC
RMON
ROSE
RPC
Remote Authentication Dial-in User Service
Random Access Memory
Request for Comment
Remote Monitoring
Remote Operation Service
Remote Procedure Call
S
SDH
SMBIOS
SMI
SMP
SMS
SNMP
SSL
Synchronous Digital Hierarchy
System Management BIOS
Structure of Managemen Information
Simple Management Protocol
System Management Server
Simple Network Management Protocol
Secure Socket Layer
T
TCL
TCP
TCP/IP
TFTP
TMN
Tool Command Language
Transmission Control Protocol
Transmission Control Protocol/Internet Protocol
Trivial File Transfer Protocol
Telecommunication Management Network
VANHA MAANTIE 6
02650 ESPOO
[email protected]
LIST OF ACRONYMS
98
MATTI PUSKA
TO0
TP 4
Transport Protocol 0
Transport Protocol 4
U
UDP
uid
UML
UMTS
UPS
UTC
User Datagram Protocol
User Identification
Unified Modeling Language
Universal Mobile Telecommunication System
Uninterruptable Power Source
Universal Time Convention
V
VLAN
VoIP
VPN
Virtual LAN
Voice over IP
Virtual Private Networks
W
WAN
WBEM
WMI
Wide Area Network
Web-based Enterprise Management
Windows Managemen Instrumentation
X
XML
Extensible Markup Language
3
3G
3rd Generation
VANHA MAANTIE 6
02650 ESPOO
[email protected]
LIST OF ACRONYMS
99
MATTI PUSKA
App A
This appendix includes:
• The TCP/IP Protocol Stack
• SNMP Message and PDU Formats
• Other Central TCP/IP PDUs
• Ethernet and 802.3 Frame Formats
• LLC1 Frames
Protocol Data Units
TCP/IP Protocol Stack
TCP/IP Architecture divides communication tasks into three layers. Each layer
realisation on an End System or on an Intermediate System communicates with the peer
entity using a protocol. Figure 51 shows the central TCP/IP protocols.
The application layer protocols generate messages that are transported on the payload
field of transport layer segments or datagrams. The transport layer PDUs are then
enclosed to Internet layer packets. The packets are send to an Interface that is not part of
the TCP/IP architecture. The Interface can be a packet or a circuit switched network.
T
e
l
n
e
t
F
T
P
P
O
P
S
M
T
P
H
T
T
P
D
N
S
I
R
C
TCP
S
N
M
P
X
1
1
R
T
P
UDP
OSPF
RIP
IP
IGRP
ARP
Interface
Figure 51: TCP/IP Protocol Stack.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
PROTOCOL DATA UNITS
100
MATTI PUSKA
Both version 1 and 2c SNMP messages contain a version number, a Community string
and an SNMP PDU. The whole message, including the PDU, is coded using ASN.1.
The Protocol Data Unit contains ASN.1 tag description and value pairs, as shown in
Figure 52.
Version Community
PDU Request
Type
Id
Error
Status
Error
Index
Variable Bindings
Figure 52: SNMP Message is ASN.1 coded.
SNMP v.1 and v.2c messages are sent in clear text format, while version 3 messages can
be encrypted. An authenticated SNMP v.3 message contains, in a digest, a checksum
known only to the source and the destination. A private and authenticated format SNMP
v.3 message is encrypted with a secret key, known only to the parties.
SNMP Network Management messages are transported using the connectionless UDP
transport that offers unreliable transport services. UDP sessions are identified by source
and destination TCP port numbers. The SNMP agent listens to a well-known port (161
for SNMP), and issues a return port to the client application. The UDP header is
protected with a checksum, as shown in Figure 53.
1 Word = 4 B
2 Words
1B
Source TCP Port
Destination TCP Port
Length
Checksum
Payload
Figure 53: UDP Datagram Format.
As shown in this figure and in Figure 54, the TCP/IP protocols use 32 bit words. An IP
packet header is at least five words (20 bytes), containing an optional variable lenght
options field. The header includes also a protocol field which contains information
about the upper layer PDU, which is carried in the payload field.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
PROTOCOL DATA UNITS
101
MATTI PUSKA
1 Word = 4 B
1B
5 - n Words
Ver. IHL
Type
Total Length
Identification
TTL
Flags
Protocol
Sequence Nr.
Checksum
Source IP Address
Target IP Address
Options
Padding
Payload
Figure 54: IP Packet.
Ethernet V.2 and 802.3 Frames
In Ethernet LANs, upper layer PDUs are carried in either Ethernet V.2 or 802.3 frames.
An IP packet is directly encapsulated in an Ethernet frame which contains an EtherType
protocol identification, as shown in Figure 55. An 802.3 frame carries an 802.2 LLC
frame with a protocol identification for standard protocols, and the layer 3 packet is
placed in the payload field of the LLC frame. For non-standard protocols, a separate
SNAP frame with an EtherType protocol identification. 6 byte hardware coded MAC
addresses are used both in Ethernet and 802.3 frames.
In both cased the data field is 46 - 1500 bytes, so the contents of an 802.3 length field is
not more than 1 500. EtherType values are always more than 1 50010, so the two frame
types can be distinguished with the value of the third field.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
PROTOCOL DATA UNITS
102
MATTI PUSKA
Destination
Destination
Address
Address
Source
Source
Address
Address
Length
Length
Data
Data
==
L3
Packet
L3 Packet
Data
Data
==
LLC
LLCFrame
Frame
Padding
(if needed)
FCS
FCS
FCS
FCS
8b
8b
6B
2B 6B
Destination
Destination
Address
Address
Source
Source
Address
Address
EtherType
EtherType
46 - 1500 B
802.3
Frame
4B
Ethernet V.2
Frame
Figure 55: Ethernet and 802.3 Frames.
Logical Link Control Frames
Some network layer protocols, like ISO IP and NetBEUI, use 802.3 frames. In this case,
the Data Link Layer 802.3 frame includes a Data Link Layer LLC frame. For
connectionless services, LLC Type 1 is used. This provides a common interface for
various LAN technologies and upper layer protocol identification. LLC1 includes
unnumbered UI, XID and TEST PDUs. For network layer packets, the UI, shown in
Figure 56, is used.
Data
Data
==
LLC
LLCFrame
Frame
Padding
(if needed)
FCS
FCS
LLC UI
Frame
DSAP
DSAP
SSAP
SSAP
Control
Control
C/R BC
Destination
Destination
Address
Address
Source
Source
Address
Address
Length
Length
1 B1 B 1 B
802.3
Frame
Info
Info
==
L3
Packet
L3 Packet
8b
Figure 56: LLC1 UI Frame inside an 802.3 Frame.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
PROTOCOL DATA UNITS
103
MATTI PUSKA
App B
ASN.1 Basic Encoding
Rules
This appendix includes:
• ASN.1 BER Encoding Format
• Applying BER Encoding Rules
• Meaning of each bit in the Tag field
• Most important BER Tag Values
BER Encoding
Application Layer SNMP Messages are encoded using ASN.1 Basic Encoding Rules.
According to BER, all ASN.1 data items are encoded using the format of the following
three fields, as shown in Figure x:
• One byte Tag field, including information about the ASN.1 data type, class and
type format (simple or constructed).
• One byte Length field, indicating the length of the value field in octets.
• Variable length Value field, including either a single value (of the type indicated
by the tag field) or a structured array of multiple values.
1B
1B
Variable length
Tag
Length
Value
Figure 57: ASN Basic Encoding Format.
In case of structured SNMP messages, BER encoding is first applied to the whole
SNMP Message. Then the same encoding is applied to the three SNMP Message fields,
namely to Version, Community and PDU. On the next step, the BER encoding is
applied separately to all PDU fields (Request Id, Error Status, Error Index, Variable
Bindings), next to the Variable Bindings, then variables and finally to both the Object Id
field and the Value field of each of the Variables. The BER rules result to a nested
structure of Figure 57 formats, as shown in Figure 58.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
ASN.1 BASIC ENCODING RULES
104
MATTI PUSKA
SNMP Msg SNMP Msg
Tag
Length
SNMP Message Value
Version Community
Version Version Version
Tag
Length
Value
PDU Value
Community Community Community
Tag
Length
Value
PDU
Tag
PDU
Length
PDU
Value
Request Error Error
Id
Status Index
Tag Length Value
Tag Length Value
Tag Length Value
Variable Binding
Tag Length Value
Var Var
Variable
Tag Length
Oid Val
Tag Length Oid
Tag Length Val
Figure 58: Nested BER Encoding of an SNMP Message.
Tag Field Values
The two most significant bits of the Tag field, bits 8 and 7, indicate data classes, namely
Universal (00), Application wide (01), Context specific (10) and Private (11). For
SNMP Message and PDU field identifications as well as for simple data types the
Universal class is used. Context specific class is used for constructed data types, like
PDU value and PDU Types.
The next bit, bit 6 indicates simple (0) or constructed (1) format. Constructed format is
used for the SNMP Format, PDU, PDU type, Variable Binding List, Variables on the
list and for sequences, and the remaining values use simple type.
The remaining five least significant bits (bits 5, 4, 3, 2 and 1) indicate the data type in
question. Table 2 includes a summary of the most important tag values.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
105
MATTI PUSKA
Table 2: Some common BER Tag values.
MSB
Bits 8&7
Type
Bit 6
LSB
Bit 5, 4, 3, 2, 1
Hex
value
Message
GetRequest PDU
GetNextRequest PDU
GetResponse PDU
SetRequest PDU
Trap PDU
00
10
10
10
10
10
1
1
1
1
1
1
1 0000
0 0000
0 0001
0 0010
0 0011
0 0100
30
a0
a1
a2
a3
a4
Version
Community
PDU
Request Id
Error Status
Error Index
Variable Bindings
Variable
Object Identifier
Value
00
00
10
00
00
00
00
00
00
00
0
0
1
0
0
0
1
1
0
0
0 0010
0 0100
0 0010
0 0010
0 0010
0 0010
1 0000
1 0000
0 0110
0 0100
02
04
a2
02
02
02
30
30
06
04
Integer
Octet String
Null
Sequence, Sequence of
00
00
00
00
0
0
0
1
0 0010
0 0100
0 0101
1 0000
02
04
05
30
Example
Enclosed is a hex dump of an SNMP message. The total message length is 55 bytes.
30
04
07
01
35
40
2b
02
02
c2
06
01
01
f3
01
01
00
35
02
01
04
02
01
05
06 70
01 00
01 02
00
75 62 6c 69 63 a1 28 02
02 01 00 30 1a 30 0b 06
05 00 30 0b 06 07 2b 06
For decoding, we will first regroup the bytes to find out the BER Tags and Length
fields. Then we should use the information on Table 2 to identify BER Tags in question.
Decoding exposes the following details.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
106
MATTI PUSKA
30
02
04
a1
02
02
02
30
30
06
05
30
06
05
35
01
06
28
04
01
01
1a
0b
07
00
0b
07
00
00
70 75 62 6c 69 63
40 c2 f3 35
00
00
2b 06 01 02 01 01 02
2b 06 01 02 01 01 01
SNMP Message, 0x35 = 53 bytes
Version, 1 byte, = 0, indicating Version 1
Community, 6 bytes, = public
GetNextRequest PDU, 0x28 = 40 bytes
Request Id, 4 bytes, = 0x40c2f335
Error Status, 1 byte, = 0
Error Index, 1 byte, = 0
Variable Bindings, 0x1a = 26 bytes
Variable 1, 0x0b = 11 bytes
Object Identifier, 0x07 = 7 bytes
Null value, 0x00 = 0 bytes
Variable 2, 0x0b = 11 bytes
Object Identifier, 0x07 = 7 bytes
Null value, 0x00 = 0 bytes
Checking the length fields gives the following results:
• the SNMP message, excluding the Message Tag and Message Length is 53
bytes. This matches with the total message length of 55 - 2 bytes
• the version value is one byte long and the community string is six bytes long,
consuming the total of 2 + 1 + 2 + 6 B = 11 bytes
• the GetNextRequest PDU length is 40 bytes, which matches with the 53 - 11- 2
bytes = 40 bytes
• the variable bindings length is 26 bytes, consisting of two 11 byte variables, each
with a two byte header
• both variables are 11 bytes, consisting of a 7 + 2 byte OID and two byte Null
value
• the object identifier is 7 bytes long and the value is zero byte long.
For control, I enclose the protocol analyser printout for the SNMP message. You may
compare this with the above presented manual decode results.
------------ SNMP Header -----------SNMP: Version = 0
SNMP: Community = public
SNMP: PDU = GetNextRequest
SNMP: Request identifier = 0x40c2f335 (1086518069)
SNMP: Error status = noError (0)
SNMP: Error index = 0
SNMP: Object = 1.3.6.1.2.1.system.sysObjectID
SNMP: Object = 1.3.6.1.2.1.system.sysDescr
VANHA MAANTIE 6
02650 ESPOO
[email protected]
107
MATTI PUSKA
List of References
1. Matti Puska: Lähiverkkojen tekniikka. Suomen Atk-kustannus, 1999.
2. HP VantagePoint Demo Show. Hewlett-Packard, 2000.
3. J. Case et. al: A Simple Network Management Protocol, RFC 1157. IETF, 1990.
4. J. Case et. al: Protocol Operations for Version 2 of the Simple Network Management
Protocol (SNMPv2), RFC 1905. IETF, 1996.
5. U. Blumenthal, B. Wijnen: User-based Security Model (USM) for version 3 of the
Simple Network Management Protocol (SNMPv3), RFC 2574. IETF, 1999.
6. UCDAVIS MIB on Linux.
7. RMON Explained. Solcom Systems.
8. Matti Puska: Tietokoneverkkojen asennuksesta ja huollosta, C:18. Hamk, 1997.
9. Paul Hershey, Charles B. Silio: Intelligent Monitoring and Control for
Telecommunication Networks. Telecommunications International, August 1997
10. Network Management Concepts. cisco Systems, 1996. Internet, <URL: http://
www.dkrz.de/%7Ek202046/em/products/sem/Manuals/dev_guide/network.doc.html>
11. ICM TMN Platform. Internet, <URL: http://www.telecom.ntua.gr/activities/
projects/icm/platform.html>
12. Evolution of management for corporate networks. Siemens, Telcom Report
International. Internet, <URL: http://w2.siemens.de/telcom/articles/e0395/
395helb.htm>
13. M-L Karjalainen: Nokia NMS/2000 User's Guide. NTC TAN 0312/6 en. Nokia,
1998.
22. James W. Hong et.al.: Enterprise Network Traffic Monitoring, Analysis and
Reporting Using Web Technology. Journal of Network and Systems Management,
Plenum Press, 1999.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
LIST OF REFERENCES
108
MATTI PUSKA
23.Susan E. Aldrich, James Herman, Theodore Forbath: The Impact of the Web on the
IT Management Software Market. Patricia Seybold Group, 1999.
24. Tobias Oetiker: MRTG. Internet, <URL: http://ee.staff.ethx.ch/~oetiker/
webtools/mrtg/mrtg.html>
25. Tobias Oetiker: Multi Router Traffic Grapher - Configuration File Format. Internet,
<URL: http://ee.staff.ethx.ch/~oetiker/ webtools/mrtg/config.html>
26. ROI Constraint: The Impact of Network Underperformance on Return on Investment
for Enterprise-Class Applications. Infonet, 2002.
27. Opening Technologies: Network Management Based on International Standards.
Opening Technologies, 1992.
28. Kai Koskimies: Oliokirja. Satku - Kauppakaari, Jyväskylä 2000.
29. Remote Monitoring. Cisco Systems, 2002. Internet, <URL:
http://www.cisco.com/univercd/doc/cistwk/ito_doc/rmon.htm>
31. DMTF Web pages. Internet, <URL: http://www.dmtf.org>
32. Andrea Westerinen et. al.: DMTF Standards Overview. DMTF 2002 Developer's
Conference
33. Andrea Westerinen, Julie Schott: DMTF Standards Overview - WBEM and CIM,
September 18, 2002
34. Andrea Westerinen: DMTF Standards Overview - WBEM and CIM. DMTF, 2002.
35. Windows Management Instrumentation Overview. Microsoft TechNet, 2003.
Internet, <URL: http://www.microsoft.com>
36. Cisco Systems: Directory-Enabled Networking. Cisco Systems, 2002. Internet,
<URL: http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/diren.htm>
37. Andrea Westerinen: DEN and WBEM - Extending Web-Based Enterprise
Management. DMTF, 2002
38. Steven Judd, John Strassner: Directory Enabled Networks - Information Model and
Base Schema. Version 3c. Internet, <URL:
http://murchiso.com/den/specifications/directory-enabled-networks-v3-lastcall.pdf>
VANHA MAANTIE 6
02650 ESPOO
[email protected]
LIST OF REFERENCES
109
MATTI PUSKA
39. DEN-Based Object Modeling and Schema for Policy-Based Networking.. Cisco
Networkers, Paris 2000.
40. LDAP Namespace Design. Oswebo State University, 2000. Internet, <URL:
http://netwww.oswego.edu/ldap/namespace_design.html>
41. CIM Tutorial. DMTF Education
42. Keijo Tanskanen: Siirtoverkkojen hallintajärjestelmät. Insinöörityö, Evtek 2004
43. J. Richard Burke: Network Management, Concepts and Practice: A Hands-on
Approach. Pearson Education, New Jersey, 2004.
VANHA MAANTIE 6
02650 ESPOO
[email protected]
LIST OF REFERENCES
110
MATTI PUSKA

Network Management Systems

Transcription

Similar documents

smart living

scanway - Liikennelabra

Antenne Bayern Chooses 2wcom

ESPOON KESKUS

A true story about the unreal life of the world`s best

Tapiola - espoo.fi

keeping warm underground!

strong roots, a promising future

How did it go?