J.Schönwälder - L.Deri v. 1.4 Network Management / 1
Sistemi di Elaborazione dell’Informazione:Elementi di Gestione di Rete
Prima Parte:Paradigmi e Protocolli per la Gestione di Rete
Anno Accademico 2003/2004
Luca Deri <[email protected]>
J.Schönwälder - L.Deri v. 1.4 Network Management / 2
References
Books:
D. Mauro, K. Schmidt, Essential SNMP, O’Reilly & Associates, 2001.
W. Stallings: SNMP, SNMPv2 and CMIP - The Practical Guide to Network ManagementStandards, Addison Wesley, 1993
D. Zeltserman, A Practical Guide to SNMPv3 and Network Management, Prentice Hall,1999.
W. Stallings: SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, Addison Wesley, 1998.
M.T. Rose: The Simple Book - An Introduction to Management of TCP/IP basedInternets, Prentice Hall, 1996
M. Sloman: Network and Distributed Systems Management, Addison Wesley, 1994
D. Perkins, E. McGinnis: Understanding SNMP MIBs, Prentice Hall, 1997
D. Steedman: Abstract Syntax Notation One (ASN.1) - The Tutorial and Reference,Technology Appraisals, 1990
J.Schönwälder - L.Deri v. 1.4 Network Management / 3
Online Resources and Organisations
Online Resources: The Simple Times http://www.simple-times.org/
The Simple Web http://www.simpleweb.org/
CMIP Run! http://wwwsnmp.cs.utwente.nl/Docs/iso/cmip-run/
Organisations:
Internet Engineering Task Force (IETF) http://www.ietf.org/
Internet Research Task Force (IRTF) http://www.irtf.org/
International Organization for Standardisation (ISO) http://www.iso.ch/
International Telecommunication Union (ITU) http://www.itu.ch/
Tele Management Forum (TMF) http://www.tmforum.org/
Disributed Management Task Force (DMTF) http://www.dmtf.org/
Object Management Group (OMG) http://www.omg.org/
The Open Group http://www.opengroup.org/
Network Management Forum (NMF) http://www.nmf.org/
J.Schönwälder - L.Deri v. 1.4 Network Management / 4
Table of Contents
1. Introduction
(Motivation, History, Terminology,fundamental concepts)
2. Internet Management
(SMIv2, MIBs, SNMPv1/SNMPv3,AgentX)
3. OSI Management
(GDMO, CMIP/CMISE, SMFs)
4. Integrated SystemsManagement
(Concepts, Functions, Aspects ofIntegration, Comparison Criteria)
5. Distributed Internet Management
(Mib based, Remote Operations,Management by Delegation,Scripts, OSF DME)
6. Current Developments
(Managent with Corba, Web-basedManagement, Common InformationModel, Java Management, XML-RPC, Policy-Based Networks,Latest Developments)
J.Schönwälder - L.Deri v. 1.4 Network Management / 5
1. Introduction
1. Introduction
1.1 Motivation
1.2 Terminology and basic concepts
1.3 Networking Basics
1.4 Abstract Syntax Notation One
2. Internet Management
3. OSI Management
4. Integrated Systems Management
5. Distributed Internet Management
6. Current Developments
J.Schönwälder - L.Deri v. 1.4 Network Management / 6
1.1 Motivation: Why Do We Need Management ? Current situation:
increasing meaning of strategic resources "information”.
a computer network is no longer only a supporting item in an enterprise, but takes evenmore frequently a key position.
the number of interconnected computers rose dramatically in the past few years. Thisprocess will probably continue to persist.
Complexity and functionality of the components grows in correspondence with theperformance of the available hardware.
Demand:
Permanent availability of network services with optimal quality.
Cost reduction for the network infrastructure of the company.
Necessity:
computer-aided management of heterogeneous networks.
J.Schönwälder - L.Deri v. 1.4 Network Management / 7
Subject of this Lecture
Management implementation:
By humans (network administrators, operating surgeons), by special tools(hardware and software).
Hence network management is first of all an organisational problem.
Cost effective and flexible network guidelines and procedures need becompiled.
Tools and their technological bases are just aids to successful networkmanagement.
Subject of this lecture:
Network management basics.
Architecture and functionality of network management
Open standards issued by independent organisations.
J.Schönwälder - L.Deri v. 1.4 Network Management / 8
Network Management Dimensions
Security
Performance deduction
Performance evaluation
Anomaly management
Configuration management
Planning Installation Operation Migration
ComponentsSystems
UsersEnterprise
Functional Dimension
Object Dimension
Time Dimension
J.Schönwälder - L.Deri v. 1.4 Network Management / 9
Network Management Dimensions
Functional Dimension
The network tasks and operations are combined into group of functions calledfunctional areas.
Temporal Dimension
The temporal dimension gives a classification of the life cycle of a network(planning, installation, operation and migration).
The migration phase is transferred from a network technology to the next.(utilisation periods of local area networks are at present 5 years approximately)
Dimension of the object
The management can refer to individual components in the network, complexsystems, (distributed) applications or the entire network infrastructure of anenterprise.
The criteria is the quantity of information needed for a function.
J.Schönwälder - L.Deri v. 1.4 Network Management / 10
Time Horizons in the Operating Phase
The operating phase is divided into three time horizons:
Short term horizon:
Management functions, that must be provided within second or minutes.
Complete automatization is required.
Middle term horizon:
Management functions to be provided within an hour.
They are often handled semi-automatically with help of human experts.
Long term horizon:
Strategic functions to be provided within the range of weeks, months or years.
The planning aspect is the centre of attention (manufacturer selection[scouting], procurements, cost planning).
J.Schönwälder - L.Deri v. 1.4 Network Management / 11
System Management Requirements [1/2]
Guarantee the availability of the function on the net:
Service maintenance (availability, response time) need to face with technological changesand big quota increase.
Security of the services through the control of security components.
(Human) Mistake prevention and bottleneck identification/recovery.
Automatic or semiautomatic reaction on operation anomalies:
Real-time configuration modification in case of error.
Activation of redundant components in case of error.
Dynamic reactions to changes on the network and environment:
Changes regarding applications, users, components, services or fees.
Dynamic adaptation of the available transmission bandwidth according to requestsoriginated by the management system.
J.Schönwälder - L.Deri v. 1.4 Network Management / 12
System Management Requirements [2/2]
Network control:
Collection and (compressed) representation of relevant network information.
Definition and maintenance of a database of network configurations.
When applicable, centralisation of the control over peripherals andimplemented functions (central management console).
Integration of management procedures on heterogeneous environments
Improvement of system/network administrators work conditions :
Improvement and standardisation of the available tools
Identify and implement gradual automation of management functions.
Good integration of tools into the existing operational sequences.
Progress through standardisation :
Transition of existing, often proprietary, solutions in a standardisedenvironment.
J.Schönwälder - L.Deri v. 1.4 Network Management / 13
Current Situation Network Documentation:
Today large amount of data are handled manually with a big waste of time.
Inconsistent data produce problems with configuration modifications, error detection andlocalisation.
Error diagnosis:
Errors are often partially recognised.
Only the symptoms of an error are often observable.
Error situations can cause a lot of error messages difficult to correlate.
Detection of weak points:
Weak points and sporadically occurring errors can often be recognised with difficulty.
Correlation statistics:
Analysers enable power measurements for individual nodes, transmission circuits orlogs.
Interpretation of raw data is often possible just by experts.
User friendliness:
Outputs of the tools must be completed by the know-how of an expert.
Personnel training is a substantial factor within the operating cost of a network.
J.Schönwälder - L.Deri v. 1.4 Network Management / 14
Targets of the Current Developments
Implementation of integrated management systems which cover all therequirements for the management of heterogeneous networks and systems.
Good expandability and adaptability to the local network environment.
Good support during the automation of management flows and conversion ofmanagement guidelines.
Scalability of both the size of the network and increasing demanding requests ofthe management systems.
Open interfaces to the existing infrastructure and their integration into operationalsequences.
Protection of the management against attacks of unauthorised persons.
J.Schönwälder - L.Deri v. 1.4 Network Management / 15
1.2 Terminology and Fundamental Concepts
Control, co-ordination and monitoring of resources takes place via themanipulation from so-called managed objects:
"A managed object is the abstracted view of a resource that presents itsproperties as seen by (and for the purpose of) management." (ISO 7498-4)
Managed objects are an abstract representation of a real resource.
The boundary of a managed object specifies which details are accessible to amanagement system and which ones are shielded (black box).
Managed objects do not necessarily correspond to objects, as one knows fromobject-oriented programming. Simple variables correspond to the MOs in theInternet management.
AttributesoperationsBehaviourNotifications
Managed Object Real Coffe MachineManagement-System
Warning: Coffe
Machine is operational
but no coffee is produced.
J.Schönwälder - L.Deri v. 1.4 Network Management / 16
Reusable Management Design Patterns [1/2]
Patterns are descriptions of communicating objects and classes that arecustomised to solve a general design problem in a particular context. In otherwords, patterns are schematic, proven solutions to recurring problems.
Patterns provide reusability in software engineering. They enable softwareengineers to capture and pass on software development experience without theneed for code (unlike object-oriented frameworks, for instance) and consequentlythey allow for a better design.
Patterns are important in the management world as they are are frequently usedfor providing a solution to different (in terms of technology and context) yet similarmanagement problems.
Reference:E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements ofReusable Object-Oriented Software, Addison-Wesley, Menlo Park, CA, USA,1994.
J.Schönwälder - L.Deri v. 1.4 Network Management / 17
Reusable Management Design Patterns [2/2]
Adapter/WrapperConvert the interface of a class into another interface clients expects. Adapter lets classeswork together that couldn't otherwise because of incompatible interfaces.
BridgeDecouple an abstraction from its implementation so that two can vary independently.
FaçadeProvide a unified interface to a set of high-level interfaces in a subsystem that makessubsystems easier to use.
LayersThe layers architectural pattern helps structure applications that can be broken down intogroups of subtasks, whereby each group of subtasks operates at a specific level ofabstraction.
MediatorIt promotes loose coupling by keeping objects from referring to each other explicitly.
ProxyProvides a surrogate or a placeholder for another object to control access to it. It makes theclient of an object communicate with a representative rather than with the object itself.
J.Schönwälder - L.Deri v. 1.4 Network Management / 18
Managed Objects (MO)
Attributes:
Attributes describe the state/condition of managed objects.
Attributes can change when the condition of the real object changes.
Attributes can be manipulated by means of management operations.
Operations:
Make it possible to access a managed object. Typical operations are get, set,create and delete.
The number and type of operations influence the object performance andcomplexity.
Behaviour:
Determines the semantics and interaction with the real resource.
The behaviour of managed objects is normally defined in plain English.
Notifications:
The quantity and type of the messages, which can be generated by pre-defined situations by a managed object when specific situations occur.
J.Schönwälder - L.Deri v. 1.4 Network Management / 19
Management Information Base (MIB)
The union of all managed objects contained in a system forms the ManagementInformation Base (MIB) of the system:
"The set of managed objects within a system, together with their attributes,constitutes that system's management information base." (ISO 7498-4)
This is the first interpretation of the term "Management Information Base“ (moredefinitions will follow).
A MIB should be known both to the implementer and the manager.
MO
MOMO
MO
MO
Layer 7
Layer 6
Layer 5
Layer 4
Layer 3
Layer 2
Layer 1Management Information Base
MOMO
MO
ManagementProtocols
J.Schönwälder - L.Deri v. 1.4 Network Management / 20
MIB Modularity
Managed objects of a system are usually defined in multiple MIB definitions.
Modules have been introduced in MIBs for enabling design modularity:
Different modules can be defined by different teams.
Management functionality can be gradually extended and modified.
Different systems can support different MIB modules/releases.
Vendors can extend the management functionality by means of proprietaryMIBs.
MIBs are defined using a specification language
J.Schönwälder - L.Deri v. 1.4 Network Management / 21
Manager/Agent Paradigm
Agent:
Implements the MOs MIB by accessing the real resources.
Receives requests from a manager, processes them and transmits appropriateresponses.
Dispatches notifications about important changes in status in the MIB.
Protects MOs against unauthorised accesses using access control rules andcommunication authentication with the partner.
Manager:
Exercises control: it controls functions hence it is the crucial instance.
Starts up management operations by appropriate protocol operations for themanipulation of MOs.
Receives messages from agents and passes them on (for handling) toappropriate applications.
J.Schönwälder - L.Deri v. 1.4 Network Management / 22
Management Protocol
Management applications and MOs are not often on same node.
A management protocol implements access to distant managed objects byencoding management data that is then secured during the transfer.
ComponentModel
Management Protocol
MIB
Agent
Management Protocol
Manager
Algorithm for thesolution of theManagement
problem
J.Schönwälder - L.Deri v. 1.4 Network Management / 23
Functional Areas (FCAPS) [1/2]
Management applications can be divided into 5 function areas:
Fault management:
Error detection, isolation, and repair.
Configuration management:
Production and administration of configuration information.
Name administration.
Start, check and termination of services.
Account management:
Entry of consumption (usage) data.
Distribution and monitoring of contingents.
Customer billing for resource consumption.
J.Schönwälder - L.Deri v. 1.4 Network Management / 24
Functional Areas (FCAPS) [2/2]
Performance management:
Statistic data collection.
Determination of the system performance.
Systems modifications for increase in efficiency.
Security management:
Production and verification of security policies.
Generation and distribution of passwords and accounts.
Report and analysis of security-relevant events.
These 5 functional areas according to the initial letters of the English termsnormally under the contraction FCAPS.
These functional areas are not mutually independent (data measurement has oftenimpact on system configuration).
Basic functions (e.g. monitoring of a counter for threshold values) often reside indifferent functional areas.
J.Schönwälder - L.Deri v. 1.4 Network Management / 25
Management Architectures Overview
Structure of the management information: defines the rules of the description of Managed Objects.
• Identification and designation of Mos.• Composition of MOs.• Behaviour of MOs.• Relations to other MOs.• Possible operations and internal messages of the MOs.
Definition of the datatypes, structure and syntax for the description of the MOs. The quantity of the descriptions of MOs in accordance with these rules defines
the Management Information Base (MIB)
Management Protocols and Services: Defines the services and enable the access to remote MOs. Several protocols can be used for the implementation of the defined services. The service primitive and the appropriate protocol operations influence
considerably the efficiency and the complexity of the management system.
J.Schönwälder - L.Deri v. 1.4 Network Management / 26
Management Architectures Overview
Organisational Model:
Definition of the distribution of roles of a management architecture.
• co-operative management of similar systems.
• systems belonging to different management authorities (hierarchicalconcept)
Partitioning in Management Domains according to different criteria
Functional Model:
Analysis of the total function and partitioning into functional areas by means ofgeneric auxiliary functions.
Definition of the auxiliary functions and their parameters.
Implementation using several MOs (management support objects)
J.Schönwälder - L.Deri v. 1.4 Network Management / 27
1.3 Overview: Network Basics
Copper Cable (Twisted Pair): Inexpensive technology for low frequencies. susceptible to disturbances (electromagnetic irradiation).
Coax(ial) Cable: technology for high to very high frequencies. It consists of a central conductor embodied by a peripheral conductor. Not much susceptibility to electromagnetic irradiation's. Small absorption with partial loss of energy at high frequencies.
Optical Fibres: Support for very high frequencies. Monomodal fibre carries light over almost 100 km without reinforcement
(repeater). Efficient and cheaper than coaxial cables, although the link technology is
somewhat more complicated (transceiver).
J.Schönwälder - L.Deri v. 1.4 Network Management / 28
Network Basics
Radio Link Relay (line of sight):
Modulates the signal on an electromagnetic wave (carrier).
Application in areas, in those a wiring is not practicable (e.g. city, distant sites).
It must exist a line of sight connection between senders and recipients.
Error rate depends on the view conditions (weather, fog).
Radio Waves:
Radiant emittance of an area (cell), determined by electromagnetic waves.
Possible mobility of the recipients and senders (GSM) .
Narrow bandwidth and high fault liability.
Satellites:
Long transmission time [latency] (approx. 200 ms) between senders andrecipients.
Very high frequencies and bandwidths between microwaves and multiplexers.
Suitable for transfer over geostationary satellites, which turn with the earth.
J.Schönwälder - L.Deri v. 1.4 Network Management / 29
Line vs. Packet Switched Systems
Circuit Switching (Circuit Switched Network):
From a sender to a recipient over a constantly established physical line.
Communication takes place in the following phases:
1. Connection establishment.
2. Data exchange.
3. Connection clearing.
After the connection has been established the bandwidth is completely available to thesender (reserved bandwidth).
Examples: Plain Telephone, GSM, Leased Lines.
Packet Switched Networks:
Messages divided into small units, so-called packets.
There is only a constant line from the sender to the next relay station.
Relay stations receive packets and send them towards the target.
Relay stations must know the path to individual targets (choice of route = routing).
The bandwidth between relays can be better used (over-planning, traffic multiplexing).
Examples: GPRS/UMTS, Internet.
J.Schönwälder - L.Deri v. 1.4 Network Management / 30
Connection Oriented vs. Connectionless
Connection Oriented (CO) Communications:
Each communication requires first the establishment of a connection to thecommunication partner (signalling).
CO communications can be implemented on both circuit switching and packetswitching system.
The address of the recipient is specified only at connection establishment.
Failures of network components lead to connection termination.
Connectionless (CL) Communications:
Data exchange can begin at any time without connection establishment
CL communications can be implemented on both circuit switching and packetswitching system.
Each dispatched message must contain address information of the recipient.
Failures and disturbances are less noticed but still cause loss of messages(packet loss).
J.Schönwälder - L.Deri v. 1.4 Network Management / 31
Network Topologies [1/2]
Star
Simple way selection.
Bad reliability (single point of failure).
Ring
Bad reliability (single point of failure).
Better support for network control.
Bus
Stations share a common medium.
Good reliability.
Linear Network
Conceptually simple.
Average reliability.
The position in the network influences transmission times.
J.Schönwälder - L.Deri v. 1.4 Network Management / 32
Network Topologies [2/2]
Meshed Network
No switching necessarily
Good reliability
n (n-1) / 2 connections with n nodes (fullymeshed)
Backbone Network
Coupling of networks to larger units
Usually hierarchical structure
Reliability directly dependent on the reliability ofthe liaison vehicles
Fits well into existing hierarchical organisations
J.Schönwälder - L.Deri v. 1.4 Network Management / 33
Services and Protocols: Some Definitions
ServiceIt is defined as an abstract function supplied by a network
Service PrimitiveThe individual elementary functions are called service-primitives. Typical ISO/OSI servicesare: request Service Request indication Indication that a service was requested response Reaction of the service to a service request confirm Acknowledgement that a requested service was provided
Service Access Point (SAP)The interfaces over which the service primitive can be access as service access points.
EntitiesThe services furnished by so-called instances.
ProtocolThe rules and the restrictions according to which instances interact with other instances.
J.Schönwälder - L.Deri v. 1.4 Network Management / 34
Representation and Layering of Services
The definition of layers is a fundamental principle for the structuring of communicationsystems.
Services of a layer may only accept service primitives of services in adjacent layers.
N-Authority 1 N-Authority 2
Service User Service Provider
SAP NService Layer N
Layer N
(N-1)-Authority 1 (N-1)-Authority 2 Layer N-1
Service Layer N-1 SAP N-1
J.Schönwälder - L.Deri v. 1.4 Network Management / 35
Time Diagrams
Time diagrams clarify the temporal and spatial connections between serviceprimitives.
Vertical axis are time axis, horizontal axis give the spatial distance between usersand providers of services.
Service requests of a confirmed service can result either in a positive or negativeconfirmation.
Service requests of an unconfirmed service are not acknowledged.
request
confirmation
indication
response
requestindication
Confirmed Service Unconfirmed Service
Service User Service Provider Service User Service Provider
J.Schönwälder - L.Deri v. 1.4 Network Management / 36
ISO/OSI-Reference Model
Media
Network
Transport
Physical
Data Link
Session
Presentation
Application
Network
Transport
Physical
Data Link
Session
Presentation
Application
Application Process
Network
Physical
Data Link
Application Process
Media
Transit System
End System End System
J.Schönwälder - L.Deri v. 1.4 Network Management / 37
ISO/OSI Transport System [1/2]
Physical Layer
Transport of a stream of bits over a media.
Transport depending on the characteristics of the media being used.
Representation of values 0 and 1 (e.g. voltage levels).
Synchronisation between senders and recipients.
Definition of standard plugs for media interconnection.
Data Link Layer
Transport of a frame of bits.
Data communication between systems that share a common media.
Detection and recovery of transfer errors.
Flow control for handling traffic peaks (traffic jam).
Implementation usually in hardware on adapter cards (e.g. Ethernet card).
J.Schönwälder - L.Deri v. 1.4 Network Management / 38
ISO/OSI Transport System [2/2]
Network Layer
Determination of a route through the network (routing).
Multiplex of network connections over a shared connection.
Error detection and recovery between end-systems.
Flow control between end-systems.
Division of a Packet in multiple frames.
Transport Layer
End-to-end communication between applications.
Virtual connections over connectionless datagram services.
Error detection and recovery between applications.
Flow control between applications.
Concurrent usage of multiple services.
J.Schönwälder - L.Deri v. 1.4 Network Management / 39
ISO/OSI Higher Layers
Session Layer
Synchronisation and co-ordination of communicating processes.
Session control (checkpoints for recovery).
Presentation Layer
Transformation and adaptation of data presentations (e.g ASCII EBCDIC).
Serialisation of data structures for the purpose of transfer.
Data compression.
Application Layer
Supply of fundamental services, which can be used directly by any applicationincluding (but not limited to):
File transfer, virtual terminals, name space administration, database access,network management, electronic communication networks, process and printcontrol...
J.Schönwälder - L.Deri v. 1.4 Network Management / 40
Internet Layer Model
Media
Internet (IP)
Transport
Internet (IP)
Transport
Application Process
Internet (IP)
Application Process
Media
Router
Endsystem End System
ApplicationApplication
SubnetworkSubnetwork SubnetworkSubnetwork SubnetworkSubnetwork
J.Schönwälder - L.Deri v. 1.4 Network Management / 41
ISO Standardisation
Working Document
Committee Draft
Draft InternationalStandard
Full Standard
TechnicalReport
TechnicalReport
No Implementation
Still NoImplementation !
Reject
Reject
Modifications Needed
Modifications Needed
J.Schönwälder - L.Deri v. 1.4 Network Management / 42
IETF Standardisation
Working Document
Proposed Standard
DraftStandard
Full Standard
Historical
Historical
Implementation experiencemust be obtained
Several independentimplementations must
interoperateReject
Reject
Modifications Needed
Modifications Needed
After a maxof 2 years
After a maxof 4 years
J.Schönwälder - L.Deri v. 1.4 Network Management / 43
1.4 Overview: Abstract Syntax Notation One
Abstract Syntax Notation One (ASN.1) is a syntax user for the definition of datastructures and message formats.
ASN.1 goals:
Exchange of information between machines with different hardwarearchitectures (8/16/32/64 bit, little/big-endian).
Independence from existing programming languages (language neutral).
Coding of the data during the transfer should be selectable between sendersand recipients (negotiation).
Separation of the data presentation from the application-specific data structurerepresentation.
The abstract syntax defines the data structures during the transfer and determinesin which form these data structures will serially transfer over a network.
J.Schönwälder - L.Deri v. 1.4 Network Management / 44
Abstract Syntax and Transfer Syntax
ASN.1 defines a standardised abstract syntax.
ASN.1 permits several encoding rules that transform the abstract syntax into abyte stream suitable for transfer. BER (Basic Encoding Rules) defines the mappingbetween abstract and transfer syntax.
Applications normally use a local syntax depending on the programming languagebeing used.
System A
Enc/Dec
System B
Enc/DecCommon DataRepresentation
Local Syntax Local Syntax
Abstract Syntax (ASN.1)
Transfers Syntax (ASN.1 Encoding Rules)
J.Schönwälder - L.Deri v. 1.4 Network Management / 45
Primitive ASN.1 Datatypes
Names of ASN.1 datatypes begin with a uppercase letter.
Names of ASN.1 values (constants) begin with a lowercase letter.
ASN.1 keywords and macro names consists only of uppercase letters.
Comments are enclosed between `--` (e.g. `-- This is a comment --`).
BOOLEAN:
Can only take the predefined values TRUE and FALSE.
INTEGER:
Covers all the possible integer numbers. No delimitation of the number range.
BIT STRING:
A sequence of bits. The length does not have to be divisible by 8.
OCTET STRING:
A sequence of octets (bytes). It is the base type for different character sets andother derived types (GeneralizedTime, UTCTime).
J.Schönwälder - L.Deri v. 1.4 Network Management / 46
Primitive ASN.1-Datatypes
ENUMERATED: Type of enumerating. Possible values must be determined by the definition of
derived datatypes. OBJECT IDENTIFIER:
Unique identification of a node in the ISO registration tree. Path of the root of the tree to the target node.
ObjectDescriptor: A character string for the identification of a node in the Registration tree. Not necessarily unique.
ANY: any ASN.1-datatype (Union of all ASN.1 datatypes as C ‘void’).
EXTERNAL: Data not described using an ASN.1 definition.
NULL: A substitute symbol, in order to indicate in an assembled datatype the absence
of a value.
J.Schönwälder - L.Deri v. 1.4 Network Management / 47
ISO Registration Tree
Used for uniquely identifying definitions, documents, objects...
Hierarchical structure, similar to hierarchical file systems.
All nodes of a level identified by a unique number.
The path from the root of the registration tree to a node results in a numericalsequence called Object Identifier (e.g. 1.3.6.1).
ccitt(0) iso(1) joint-iso-ccitt(2)
standard(0) registration-authority(1) member-body(2) identified-organization(3)
dod(6)
internet(1)
directory(1) mgmt(2) experimental(3) private(4)
J.Schönwälder - L.Deri v. 1.4 Network Management / 48
Assembled ASN.1 Datatypes
SEQUENCE:
Corresponds to structures in C or records in Pascal.
The sequence of the items in a SEQUENCE is fixed.
SET:
Similar to a SEQUENCE, with the difference that the sequence of the elementsis not specified.
SEQUENCE OF:
Ordered quantity (list) of homogeneous data.
SET OF:
Unordered quantity of homogeneous data.
CHOICE:
Type of selection, similar to the C union.
REAL: It consists of the INTEGER datatype extended with mantissa and exponent.
J.Schönwälder - L.Deri v. 1.4 Network Management / 49
Reduced Datatypes
Definition of further datatypes by restricting the scope of existing datatypes.
Exact syntax dependent on the underlying primitive datatype.
Examples:LottoNumber ::= INTEGER (1..90)MD5Key ::= OCTET STRING (SIZE (16))IPAddress ::= OCTET STRING (SIZE (4|16))Counter32 ::= INTEGER (0..4294967295)Integer32 ::= INTEGER (-2147483648..2147483647)Unsigned64 ::= INTEGER (0..18446744073709551615)
Restrictions of the scope are applied to derived datatypes (e.g SEQUENCE OFMD5Key).
The restriction of the INTEGER datatype makes sense as today's computersinternally usually operate with 32-bit or 64-bit numbers.
J.Schönwälder - L.Deri v. 1.4 Network Management / 50
Some Definitions of Types and Values
Type definitions:Number ::= INTEGERDateAndTime ::= UTCTimeID ::= OBJECT Identifier
Value definitions :ok BOOLEAN ::= TRUEseven Number ::= 7now DateAndTime ::= "971105012200-0100"
Implicit Value Definitions :Lotto ::= INTEGER { first(1), last(49) }AccessRight ::= BIT STRING { read(1), write(2), execute(3) }MaskAccessRight ::= { read, execute }Sex ::= ENUMERATED { female(1), male(0) }
J.Schönwälder - L.Deri v. 1.4 Network Management / 51
A Complex Example [1/2]
Message ::= SEQUENCE {version INTEGER,community OCTET STRING,data ANY -- e.g. PDUs if no authentication
}
PDUs ::= CHOICE {get-request GetRequest-PDU,get-next-request GetNextRequest-PDU,get-response GetResponse-PDU,set-request SetRequest-PDU
}
GetRequest-PDU ::= [0] IMPLICIT PDUGetNextRequest-PDU ::= [1] IMPLICIT PDUGetResponse-PDU ::= [2] IMPLICIT PDUSetRequest-PDU ::= [3] IMPLICIT PDU
J.Schönwälder - L.Deri v. 1.4 Network Management / 52
A Complex Example [2/2]
PDU ::= SEQUENCE {request-id INTEGER,error-status INTEGER {
noError(0), tooBig(1), noSuchName(2), badValue(3), readOnly(4), genErr(5)},
error-index INTEGER,variable-bindings VarBindLis
}
VarBindList ::= SEQUENCE OF VarBind
VarBind ::= SEQUENCE {name ObjectName,value ObjectSyntax
}
J.Schönwälder - L.Deri v. 1.4 Network Management / 53
ASN.1 TAGS
Identification of datatypes during the information transfer by means of tags.
Tags consist of a tag number and a tag class. There are four classes defined: UNIVERSAL:
World-wide unique identifier (valid only within the ASN.1 standard). APPLICATION:
Unique identification within a module. PRIVATE:
For manufacturer-specific identification. Not generally used. CONTEXT-SPECIFIC:
Type identifier without class of specification (e.g. type of selection).
Example:INTEGER identified by UNIVERSAL 2OCTET STRING identified by UNIVERSAL 4
J.Schönwälder - L.Deri v. 1.4 Network Management / 54
Further ASN.1 Properties
Module Concept: Explicit import of definitions. Explicit export of definitions. Registration of definitions in the ISO registration tree.
Macros: Efficient mechanism for the extension and description of new types. Drawback: extension of the syntax makes it extremely difficult to build
compilers that support the full ASN.1 syntax. The macro system is very complex and often oddly used. Newer developments for the simplification of ASN.1.
Encoding Rules: Basic Encoding Rules (BER) (part of the ASN.1 standard) Packet Encoding Rules (PER) Distinguished Encoding Rules (DER)
J.Schönwälder - L.Deri v. 1.4 Network Management / 55
Basic Encoding Rules (BER)
The Basic Encoding Rules determine how a ASN.1 datatype can be representedas a string of bytes.
Based on tag/length/value coding (TLV) algorithm, where the each variable isidentified by one tag, the length of the value in bytes and the value of those bytes.
The TLV coding permits a recipient to reconstruct the type of a message from thereceived byte stream.
BER coding is a little inefficient as there is often unnecessary information to betransferred.
The use of OPTIONAL fields further complicated the BER definition.
BER also defines the transmission direction of the bit stream other than the codingthe ASN.1 datatypes:
Byte (Octet)
8 7 6 5 4 3 2 1Transmission Direction
J.Schönwälder - L.Deri v. 1.4 Network Management / 56
Alternative Encoding Rules
Packed Encoding Rules (PER)
Very compressed encoding based on ASN.1 subtype information.
Distinguished Encoding Rules (DER)
Subset of BER that gives exactly one way to represent any ASN.1 value (BERhave long and short format). Used e.g. in X.509 certificates where computationof digital hash sums must be unique. Uses definite-length encoding (v.s. BERvariable length).
Canonical Encoding Rules (CER)
Subset of BER that gives exactly one way to represent any ASN.1 value.Unlike DER it is based on indefinite-length encoding.
J.Schönwälder - L.Deri v. 1.4 Network Management / 57
Coding Tags Classes
Each tags is coded in a byte:
Tag classes:
Bit 8 Bit 7
UNIVERSAL 0 0
APPLICATION 0 1
CONTEXT-SPECIFIC 1 0
PRIVATE 1 1
8 7 6 5 4 3 2 1
Tag Number (type identification)
Primitive (0) or sub (1) type
Tag Class
J.Schönwälder - L.Deri v. 1.4 Network Management / 58
Coding Field Length
The length field indicates the length of the directly following value.
Length within 0..127:
Length > 127 :
8 7 6 5 4 3 2 1
Length (0..127)
0
8 7 6 5 4 3 2 1
Field length (>127)
1
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
Number of bytes that specify the field length
....
J.Schönwälder - L.Deri v. 1.4 Network Management / 59
Value Coding
For each primitive ASN.1 type there is a rule that allows values to be translatedinto a stream of bytes and vice-versa.
The rules for INTEGER and OCTET STRING are simple.
The rules for OBJECT IDENTIFIER are relatively complex.
Assembled values (SEQUENCE, SEQUENCE OF) are easily represented by codingeach individual item.
With CHOICE constructs only the available value is transferred, therefore theassociated tag must be unique.
For further details:
D. Steedman: Abstract Syntax Notation One (ASN.1) - The Tutorial andReference, Technology Appraisals, 1990
J.Schönwälder - L.Deri v. 1.4 Network Management / 60
Example of a BER Coded Message
30 1B SEQUENCE, Length 27 02 01 00 INTEGER, Length 1, "0" 04 06 70 75 62 6C 69 63 OCTET STRING, Length 6, "public" A1 0E GetNextRequest-PDU, Length 14 02 04 36 A2 8F 07 INTEGER, Length 4, "916623111" 02 01 00 INTEGER, Length 1, "0" 02 01 00 INTEGER, Length 1, "0" 30 00 SEQUENCE OF, Length 0
Length of the BER encoding must be well known (no dummy values) when a valueis coded. With some restrictions it is also possible to specify the length after thevalue.
The decoding is more difficult when the length is specified after the value.
Coding the primitive values is not always as simple as in the example (somedatatypes can be encoded in both short and long form).
J.Schönwälder - L.Deri v. 1.4 Network Management / 61
2. Internet Management
1. Introduction
2. Internet Management2.1 Overview
2.2 Structure the Management Information (SMIv2)
2.3 Fundamental MIBs
2.4 Simple Network Management Protocol Version 1 (SNMPv1)
2.5 Simple Network Management Protocol Version 2c (SNMPv2c)
2.6 Simple Network Management Protocol Version 3 (SNMPv3)
2.7 MIB Implementation and Agent Extensibility Protocol (AgentX)
3. OSI-Management
4. Integrated Systems Management
5. Distributed Internet Management
6. Current Developments
J.Schönwälder - L.Deri v. 1.4 Network Management / 62
2.1 Overview
1987 Simple Gateway Monitoring Protocol (SGMP)
1987 High-level Entity Management System (HEMS)
1988 Simple Network Management Protocol (SNMPv1) proposed
1990 Simple Network Management Protocol (SNMPv1) standard 15, 16
1991 Management Information Base II standard 17
1993 SNMP Version 2 (Party/Party/Context) historical
1996 SNMP Version 2 (Communities) draft/experimental
1998 SNMP Version 3 (User-based) draft
SNMPv1 has a large spreading particularly in data communication.
The attempts for the standardisation of SNMPv2 failed.
SNMPv3 with SNMPv1 has been accepted by a large community of networkmanufacturers.
The user community has accepted SNMPv3 very well in terms of support anddevelopment.
J.Schönwälder - L.Deri v. 1.4 Network Management / 63
SNMP Development Goals
Minimisation of the number and complexity of the management functions, whichare implemented by an agent: Reduction of development costs for management agents (simple applications). Ubiquity: use the same management technology for all devices (printers or
Cray). Application extensibility: development of new management functions without
the need to modify the agents.
Expandability by defining new MIBs. Independence from existing computer or network architectures. Robustness by a simple, connectionless transport service (UDP). No dependency on other network services. Addition of management to new/existing devices/applications should be
inexpensive, simple to develop and of limited functionality. Unfortunately some of these original goals have been lost: the term "simple" refers
to the protocol and not to the specifications or the implementation of managementapplications.
J.Schönwälder - L.Deri v. 1.4 Network Management / 64
Trap Directed Polling
SNMP managers polls in regular intervals the SNMP agents.
Agents can signal exceptional cases to a manager by sending a trap.
The SNMP manager can adapt the polling strategy upon the receipt of traps (trapdirected polling).
SNMP is a strictly centralised model, where the manager implements the wholefunctionality and responsibility.
Manager
Agent
MIB
Agent
MIB
Agent
MIB
Agent
MIB
Agent
MIB
Agent
MIBInfo
rmat
ion
(Tra
ps) C
ontrol (Polling)
J.Schönwälder - L.Deri v. 1.4 Network Management / 65
SNMP Application Areas
SNMP can be used not only for network management:
control and monitoring of production processes.
control and monitoring of complex computer systems.
monitoring of complex application programs (relational databases, SAP R/3components...).
Many good SNMP toolkits are available on the market.
Very few applications are available for solving complex management problems.
The implementation of special applications or the conversion of local procedureguidelines is generally relatively complex and expensive.
J.Schönwälder - L.Deri v. 1.4 Network Management / 66
2.2 Structure the Management Information (SMIv2)
The current information model known as "Structure of Management Informationversion 2" (SMIv2) is defined and based on simple typed variables.
SMIv2 is based on extended subset of ASN.1 (1998).
Each variable has a primitive, not assembled ASN.1 datatype: INTEGER, OCTET STRING, OBJECT IDENTIFIER, NULL Integer32, Unsigned32, Gauge32, Counter32, Counter64, IpAddress, TimeTicks,
Opaque
It does not implement complex data structures and operations on the variables. Variables are either scalars (exactly one instance) or columns in a “conceptual”
two dimensional table (zero or several variables). On the variables only "read" and "write" operations can be applied. However the
SNMP protocol permits the manipulation of lists of variables. SMIv2 management information Bases (MIBs) are defined using special ASN.1
macros. It leverages the complexity of new MIBs definitions: definition of basic functionality
and primitive types to be used in new MIBs.
J.Schönwälder - L.Deri v. 1.4 Network Management / 67
SMIv2 Basic Datatypes (RFC 2578)
SMIv2 SMIv1 Description
INTEGER INTEGER Integer Numbers (-2147483648..2147483647)
OCTET STRING OCTET STRING Sequence of bytes (octets).
OBJECT IDENTIFIER OBJECT IDENTIFIER Unique identifier.
Integer32 INTEGER 32 bit Integers (-2147483648..2147483647)
Unsigned32 - 32 bit Positive Integers (0..4294967295)
Gauge32 Gauge “Thermometer“ Integer (0..4294967295)
Counter32 Counter 32 bit non decreasing counter (0..4294967295)
Counter64 - 64 bit non decreasing counter
(0..18446744073709551615)
TimeTicks TimeTicks Time in 1/100th of seconds
IpAddress IpAddress 4 Byte IPv4 Address
Opaque Opaque Unspecified ASN.1 Type (not recommended)
BITS - Bits in a OCTET STRING
- NetworkAddress Network Address (not recommended)
J.Schönwälder - L.Deri v. 1.4 Network Management / 68
A MIB Use Case
Definition of the variables in the ISO Registration tree.
Nodes are defined for naming purposes.
The leave of the tree represent the managed objects (i.e. “the meat”).
Sub nodes can be used in order to logically organise the object types.
address
name
uptime
Manager
Agent
MIB
address (1)
name (1) uptime (2)
info (2)
(1)
J.Schönwälder - L.Deri v. 1.4 Network Management / 69
Object Identifier and Instance Identifier
In the registration tree each object can be identified by means of a unique objectidentifier.
Concrete developments (instance) of a type of object are unique designated by aso-called Instance Identifier.
A unique instance identifier is obtained by attaching an instance identifiers to theobject identifier.
Scalar object have basically only one instance, where the instance identifier hasbasically the value 0 (e.g. sysName.0).
Instance identifiers for non-scalar variables are derived from the unique naming ofa conceptual table.
As object identifier can have up to 128 elements, hence instance names cannot beinfinitely complex.
J.Schönwälder - L.Deri v. 1.4 Network Management / 70
Example of Object and Instance Identifiers
Object Identifier Instance Identifier Type Value
1.1 0 IpAddress 10.1.2.1
1.2.1 0 OCTET STRING "FilterFresh"
1.2.2 0 TimeTicks 54321
MIB nodes names are relevant for human users only.
Descriptors must be unique within a MIB module, although can be used severaltimes in different MIB modules (one gets unique descriptors by the combiningmodule names and descriptors).
address (1)
name (1) uptime (2)
info (2)
(1)
J.Schönwälder - L.Deri v. 1.4 Network Management / 71
For matter of simplicity in the above example addresses are represented usingnatural numbers.
Extension of the Example MIB with a Routing table
address (1)
name (1) uptime (2)
info (2)
(1)
fwdTable(3)
fwdEntry(1)
index(1) mask(2) next(3)
1
2
3
4
5
6
2
3
5
7
8
9
2
3
2
2
3
3
1
2
3
5
7
8
9
J.Schönwälder - L.Deri v. 1.4 Network Management / 72
Identification of Table Entries
Tables are defined basically with two "auxiliary nodes":
the first node defines the table and is of type SEQUENCE OF.
the second node defines an entry (a row) in the table and is of type SEQUENCE.
this is the only permitted use of SEQUENCE and SEQUENCE OF in SNMP SMIv2.
The result of the column and instance identifier (code of the table) is a uniqueobject identifier for each table entry.
Table Example (convention OID => value):
1.3.1.1.1 => 1 1.3.1.3.1 => 2 1.3.1.2.4 => 7
1.3.1.2.1 => 2 1.3.1.1.4 => 4 1.3.1.2.7 => not existing
J.Schönwälder - L.Deri v. 1.4 Network Management / 73
Tables Naming [1/3]
Table naming is very important as it affects the way tables are accessed.
Two kind of tables naming:
Use row numbers (not being used by SNMP).
Use an index column (the SNMP way).
1
2
3
4
5
2
3
5
7
8
2
3
2
2
3
1
2
3
4
5
2
3
5
7
8
2
3
2
2
3
This is row number 3
This is the index column
J.Schönwälder - L.Deri v. 1.4 Network Management / 74
Tables Naming [2/3]
A table index is not necessarily an INTEGER. For instance the routingTable usesan IP address as table index.
A table index can be made of several components:
X . C . I1 . I2 …… In
OID
of t
he ta
ble
Col
umn
num
ber
Inde
x va
lue
1
Inde
x va
lue
n
130.89.16.23 1 130.89.16.23
130.89.16.23 2 130.89.16.127
192.168.10.12 1 172.16.1.18
192.168.10.12 2 172.16.1.12
destination (1)
policy (2)
next (3)
routingTable
1 = low cost2 = high reliability
J.Schönwälder - L.Deri v. 1.4 Network Management / 75
Tables Naming: Complex Table Indexes [3/3]
An IP Routing table is the combination ofIP address and the IP netmask necessaryto satisfy the routing rules.
The individual bytes of the IP address arespecified as individual sub identifiers.
Example:
1.3.1.1.134.169.35.1.255.255.255.0 => 134.169.35.1
1.3.1.3.134.169.34.0.255.255.255.0 => 134.169.34.15
fwdTable(3)
fwdEntry(1)
net(1) mask(2) next(3)
127.0.0.1 255.0.0.0 127.0.0.1
134.169.34.0 255.255.255.0 134.169.34.15
0.0.0.0 255.255.255.0 134.169.34.1
134.169.35.1 255.255.255.0 134.169.34.18
134.169.35.2 255.255.255.0 134.169.34.18
net mask
Instance Identifier
J.Schönwälder - L.Deri v. 1.4 Network Management / 76
Rules for the Specification of Instance Identifier values
Values for fundamental types:
Values for INTEGER:A single integer value.
Values for fixed length OCTET STRING: Each individual byte is treated as an individual value.
Values for variable length OCTET STRING:The first value is the length, followed by each individual byte.
Values for OBJECT IDENTIFIER:
The first value is the length, followed by each individual byte.
The IMPLIED keyword can be used without the length byte if it does not lead toambiguities.
The max length of OBJECT IDENTIFIER values is limited to 128 items, soinstance identifiers will not be arbitrary complex.
J.Schönwälder - L.Deri v. 1.4 Network Management / 77
MIB Module
Similar object types are combined into MIB modules.
Each MIB module must have a unique name (uppercase letters).
MIB modules are (almost) normal ASN.1 modules and obey to the lexical ASN.1rules.
Definitions can be imported by other MIB modules with the help of of the ASN.1IMPORT statement.
All used ASN.1 SMI Macros must be explicitly imported
COFFEE-MIB DEFINITIONS ::= BEGIN
IMPORT MODULE-IDENTITY, OBJECT-TYPE, enterprises,IpAddress, TimeTicks FROM SNMPv2-SMI;
...
END
J.Schönwälder - L.Deri v. 1.4 Network Management / 78
Module-Identities (RFC 2578)
<descriptor> MODULE-IDENTITY LAST-UPDATED <ExtUTCTime> ORGANIZATION <Text> CONTACT-INFO <Text> DESCRIPTION <Text>[REVISION <ExtUTCTime> DESCRIPTION <Text>]*::= <ObjectIdentifier>
Defines administrative information e.g. contact information and version number.
the REVISION and DESCRIPTION clauses are not mandatory and can occurseveral times.
ExtUTCTime contains a date in the format„YYMMDDHHMMZ“ (UTC) or„YYYYMMDDHHMMZ“, e.g.. „9502192015Z“ or „199502192015Z“.
J.Schönwälder - L.Deri v. 1.4 Network Management / 79
Example of Module Identities (RFC 2233)IF-MIB DEFINITIONS ::= BEGIN
IMPORTS ...
ifMIB MODULE-IDENTITY LAST-UPDATED "9611031355Z" ORGANIZATION "IETF Interface MIB Working Group" CONTACT-INFO " Keith McCloghrie 408-526-5260 Cisco Systems, Inc. [email protected] 170 West Tasman Drive San Jose, CA 95134-1706, US" DESCRIPTION "The MIB module to of describe generic objects for network interface sub-layers. This MIB is an updated version of MIB II´s ifTable, and incorporates the extensions defined in RFC 1229." REVISION "9602282155Z" DESCRIPTION "Revisions made by the Interfaces MIB WG" REVISION "9311082155Z" DESCRIPTION "Initial revision, published as part of RFC 1573." ::= { mib-2 31 }
...
END
J.Schönwälder - L.Deri v. 1.4 Network Management / 80
Object Identities (RFC 2578)
<descriptor> OBJECT-IDENTITY STATUS <Status> DESCRIPTION <Text>[REFERENCE <Text>]::= <ObjectIdentifier>
Defines and registers an object identifier value.
Permits the allocation of any node within the registration tree.
The STATUS clause defines whether the allocated node is "obsolete" "current", or"deprecated".
The optional REFERENCE is used to refer to further information (similar to HTMLhyperlinks).
J.Schönwälder - L.Deri v. 1.4 Network Management / 81
Example of Object Identities (RFC 2578, RFC 1906)
zeroDotZero OBJECT-IDENTITY STATUS current DESCRIPTION "A value used for null Identifiers." ::= { 0 0 }
snmpUDPDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMPv2 over UDP transport domain. The corresponding transport address is of type SnmpUDPAddress." ::= { snmpDomains 1 }
snmpIPXDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMPv2 over IPX transport domain. The corresponding transport address is of type SnmpIPXAddress." ::= { snmpDomains 5 }
J.Schönwälder - L.Deri v. 1.4 Network Management / 82
Object Types (RFC 2578)
<descriptor> OBJECT-TYPE SYNTAX <Syntax>[UNITS <Text>] MAX-ACCESS <Access> STATUS <Status> DESCRIPTION <Text>[REFERENCE <Text>][INDEX <Index>][AUGMENTS <Index>][DEFVAL <Value>]::= <ObjectIdentifier>
Macro for the definition of object types and conceptual tables.
The INDEX and AUGMENTS clauses are permitted only for the definition by tables.
Exactly one of the above clauses must be specified during table definition.
J.Schönwälder - L.Deri v. 1.4 Network Management / 83
Example for ObjectTypes (RFC 2012)
tcpRtoMin OBJECT-TYPE SYNTAX Integer32 UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum value permitted by a TCP implementation for the retransmission timeout, measured in milliseconds. More refined semantics for objects of this type depend upon the algorithm used to determine the retransmission timeout. In particular, when the timeout algorithm is rsre(3), an object of this type has the semantics of the LBOand quantity of thecribed in RFC 793." ::= { tcp 2 }
J.Schönwälder - L.Deri v. 1.4 Network Management / 84
Example for ObjectTypes (RFC 1907)
sysORTable OBJECT-TYPE SYNTAX SEQUENCE OF SysOREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table lising the capabilities of the local SNMPv2 entity acting in an agent role with respect to various MIB modules. SNMPv2 entities having dynamically- configurable support of MIB modules will have a dynamically-varying number of conceptual rows." ::= { system 9 }
sysOREntry OBJECT-TYPE SYNTAX SysOREntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the sysORTable." INDEX { sysORIndex } ::= { sysORTable 1 }
J.Schönwälder - L.Deri v. 1.4 Network Management / 85
Notification-Types (RFC 2578)
<descriptor> NOTIFICATION-TYPE[OBJECTS <Objects>] STATUS <Status> DESCRIPTION <Text>[REFERENCE <Text>]::= <ObjectIdentifier>
Macro for the registration of an event.
In case of event a manager or an agent can send an appropriate notification toanother manager.
The OBJECTS clauses defines which MIB objects must be contained in the eventdescription.
The DESCRIPTION clause must describe which instances are meant in each case.
J.Schönwälder - L.Deri v. 1.4 Network Management / 86
Example for Notification Types (RFC 2233)linkDown NOTIFICATION-TYPE OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } STATUS current DESCRIPTION "A linkDown trap signifies that the SNMPv2 entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links is about to enter the down state from some other state (but not from the notPresent state). This other state is indicated by the included value of ifOperStatus." ::= { snmpTraps 3 }
linkUp NOTIFICATION-TYPE OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } STATUS current DESCRIPTION "A linkDown trap signifies that the SNMPv2 entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links left the down state and transitioned into some other state (but not into the notPresent state). This other state is indicated by the included value of ifOperStatus." ::= { snmpTraps 4 }
J.Schönwälder - L.Deri v. 1.4 Network Management / 87
New Types from Textual Conventions
Textual conventions allow new types to be derived from SMIv2 base types.
However, additional types may not be derived from a textual convention.
A DISPLAY-HINT clause defines a simple figure of the ASN.1 representation of avalue into a format readable for humans.
The DISPLAY-HINT clause can be used only together with the INTEGER andOCTET STRING datatype and from which it derives.
A Textual convention can determine restrictions on the scope.
A Textual convention cannot define an assembled type.
J.Schönwälder - L.Deri v. 1.4 Network Management / 88
Textual Conventions [1/2]
Textual conventions are defined in RFC 2579.<descriptor> ::= TEXTUAL-CONVENTION
[DISPLAY-HINT <Text>] STATUS <Status> DESCRIPTION <Text>[REFERENCE <Text>] SYNTAX <Syntax>
The DISPLAY-HINT clause defines a bi-directional figure of the internally usedrepresentation on a representation readable for humans. .
In the SYNTAX clause only base datatypes may be used (one can thus limit notexisting Textual Conventions even further).
All further semantics must be defined in the DESCRIPTION clause.
J.Schönwälder - L.Deri v. 1.4 Network Management / 89
Textual Conventions [2/2]
The followings are the textual conventions defined in RFC 2579:
PhysAddress
MacAddress
TruthValue
AutonomousType
InstancePointer
VariablePointer
RowPointer
RowStatus
TimeStamp
TimeInterval
DateAndTime
StorageType
TDomain
TAddress
J.Schönwälder - L.Deri v. 1.4 Network Management / 90
Example:
´´d´´ stands for ´´143´´
´´d-2´´ stands for ´´1.43´´
´´o´´ stands for ´´217´´
´´x´´ stands for ´´8F´´
INTEGER DISPLAY-HINTS
Formatd
d-<number>ox
DescriptionRepresentation of an Integer
Representation of `d` with a decimal pointOctal RepresentationHex Representation
J.Schönwälder - L.Deri v. 1.4 Network Management / 91
OCTET STRING DISPLAY-HINTS
[<repeat>]<number><format>[separator][terminator]
Example: ´´255a´´ format for the ASCII characters ´´aBc´´ in the string ´´aBc´´ ´´1x:´´ format for the ASCII characters ´´aBc´´ in the string ´´61:42:63´´ ´´0aH0ae0a10a10ao0a 1a´´
format for the ASCII characters ´´World´´ in the string ´´HelloWorld´´
Field<repeat>
<number><format>
<separator><terminator>
Description (similar to C/C++ printf)Indicator for the specification repetition
# bytes in the following format fieldFormat (a ASCII, d Decimal, x Hexadecimal, o Octal, t UTF8)
Separator among multiple valuesTerminator specified at the end of the rule
J.Schönwälder - L.Deri v. 1.4 Network Management / 92
Example for Textual-Conventions (RFC 2579)
RunState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC of describes the current execution state of
a running application or process." SYNTAX INTEGER {
running(1), runnable(2), waiting(3), exiting(4), other(5)}
MacAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x:" STATUS current DESCRIPTION "Represents an 802 MAC address represented in the `canonical' or the defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first." SYNTAX OCTET STRING (SIZE (6))
J.Schönwälder - L.Deri v. 1.4 Network Management / 93
Example for Textual-Conventions (RFC 2579)DateAndTime ::= TEXTUAL-CONVENTION DISPLAY-HINT "2d-1d-1d,1d:1d:1d.1d,1a1d:1d" STATUS current DESCRIPTION "A date-time specification.
field octets contents range ----- ------ -------- ----- 1 1-2 year 0..65536 2 3 month 1..12 3 4 day 1..31 4 5 hour 0..23 5 6 minutes 0..59 6 7 seconds 0..60 (use 60 for leap-second) 7 8 deci-seconds 0..9 8 9 direction from UTC '+' / '-' 9 10 hours from UTC 0..11 10 11 minutes from UTC 0..59
For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be displayed as:
1992-5-26,13:30:15.0,-4:0
Note that if only local time is known, then timezone information (fields 8-10) is not present." SYNTAX OCTET STRING (SIZE (8 | 11))
J.Schönwälder - L.Deri v. 1.4 Network Management / 94
Further SMIv2 Macros
OBJECT-GROUPS It enables the definition of groups of related object types.
This macro can be used in the MODULE-COMPLIANCE macro.
NOTIFICATION-GROUPS It enables the definition of groups of related notification types.
This macro can be used in the MODULE-COMPLIANCE macro.
MODULE-COMPLIANCE It defines one or more constraints that a MIB implementations must fulfil.
AGENT-CAPABILITIES It describes the capabilities of a real MIB implementation.
J.Schönwälder - L.Deri v. 1.4 Network Management / 95
A Complete Example: TUBS-LINUX-MIB [1/4]TUBS-IBR-LINUX-MIB DEFINITIONS ::= BEGIN
IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Gauge32 FROM SNMPv2-SMI DisplayString FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ibr FROM TUBS-REGISTRATION;
linuxMIB MODULE-IDENTITY LAST-UPDATED "9801070622Z" ORGANIZATION "TU Braunschweig" CONTACT-INFO "Juergen Schoenwaelthe TU Braunschweig Bueltenweg 74/75 38108 Braunschweig
E-mail: [email protected]" DESCRIPTION "Experimental MIB modules for the linux operating system." REVISION "9801070622Z" DESCRIPTION "Load average object-types added, clarification of linuxCPU." REVISION "9411152024Z" DESCRIPTION "The initial revision of this module." ::= { ibr 5 }
J.Schönwälder - L.Deri v. 1.4 Network Management / 96
A Complete Example: TUBS-LINUX-MIB [2/4]-- The various groups defined within this MIB module:
linuxObjects OBJECT IDENTIFIER ::= { linuxMIB 2 }
linuxConformance OBJECT IDENTIFIER ::= { linuxMIB 3 }
-- object definitions
linuxCPU OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The Identification of the linux CPUs. This string contains foreach CPU present in the system the CPU type, model and vendor (if known by the operating system)." ::= { linuxObjects 1 }
linuxBogo OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of BOGO MIPS of the linux system." ::= { linuxObjects 2 }
J.Schönwälder - L.Deri v. 1.4 Network Management / 97
A Complete Example: TUBS-LINUX-MIB [3/4]linuxLoadAvg1 OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The average number of processes ready to runtimes 100 during the last 1 minute time interval." ::= { linuxObjects 3 }
linuxLoadAvg5 OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The average number of processes ready to runtimes 100 during the last 5 minute time interval." ::= { linuxObjects 4 }
linuxLoadAvg15 OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The average number of processes ready to runtimes 100 during the last 15 minute time interval." ::= { linuxObjects 5 }
J.Schönwälder - L.Deri v. 1.4 Network Management / 98
A Complete Example: TUBS-LINUX-MIB [4/4]-- conformance information
linuxCompliances OBJECT Identifier ::= { linuxConformance 1 }
linuxGroups OBJECT Identifier ::= { linuxConformance 2 }
linuxCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for an SNMP entity which implements the linux MIB." MODULE -- this module MANDATORY-GROUPS { linuxGroup } ::= { linuxCompliances 1 }
linuxGroup OBJECT-GROUP OBJECTS { linuxCPU, linuxBogo, linuxLoadAvg1, linuxLoadAvg5, linuxLoadAvg15 } STATUS current DESCRIPTION "A collection of linux specific objects." ::= { linuxGroups 1 }
END
J.Schönwälder - L.Deri v. 1.4 Network Management / 99
2.3 Fundamental MIBs
MIB-II (RFC 1213) defines object types for the Internet Protocols IP, ICMP, UDP,TCP, SNMP (and other definitions not relevant here). Basically it models themanagement of the TCP/IP protocol stack.
Goals of the MIB-II definition: Define basic error and configuration management for Internet protocols. Very few and weak control objects. Avoidance of redundant information in the MIB. MIB implementation should not interfere with the normal network activities. No implementation-dependent object types.
Altogether 170 object types.
Some MIB definitions turned out to be too simple and minimal (Routing table,Interface table).
Some MIB definitions presuppose a 4-Byte address format, hence these tablesmust be redefined for IP version 6 (IPv6).
J.Schönwälder - L.Deri v. 1.4 Network Management / 100
Registration and Structure of MIB-II
ccitt(0) iso(1) joint-iso-ccitt(2)
standard(0) registration-authority(1) member-body(2) ithetified-organization(3) ...
dod(6)
internet(1)
directory(1) mgmt(2) experimental(3) private(4)
mib-2(1)
system(1) interfaces(2) at(3) ip(4) icmp(5) tcp(6) udp(7) egp(8) transmission(10) snmp(11) ...
x25(1) dot3(1) dot5(1) ...
security(5) snmpV2(5) ...
J.Schönwälder - L.Deri v. 1.4 Network Management / 101
Remarks on MIB-II
The “transmission” branch accommodates all the MIB definitions that deals withinformation transmission (X.25, PPP, RS232, SONET, ISDN, IEEE 802,3, IEEE802,5, FDDI...)
The "at" (ARP Table) branch was replaced by an extension of the group of IP.
The EGP (External Gateway protocol) branch is no longer used as the EGPprotocol nowadays does not have any importance.
Many further MIB modules have been registered under the " mib-2” node. Theassignment of the registration numbers is delegated to the Internet AssignedNumbers Authority (IANA).
These days it would be good to introduce a certain modularity in the MIB so thatdifferent branches could be updated independently.
J.Schönwälder - L.Deri v. 1.4 Network Management / 102
"system" Group
sysUpTime.0 is a very important variable as it is used for determining servicediscontinuities:
If sysUpTime.0t1 < sysUpTime.0t2 where t2 > t1 then the agent has beenreinitialised and management application rely on previous values.
sysServices roughly displays the services supplied by the system:
system(1)
sysDescr(1) sysObjectID(2) sysUpTime(3) sysContact(4) sysName(5) sysLocation(6) sysServices(7)
X X0 0 0 X X Xphysical layer (e.g. repeaters)data-link layer (e.g. bridges)internet layer (e.g. router)transport layer (e.g. hosts)application layer (e.g. http-server)
J.Schönwälder - L.Deri v. 1.4 Network Management / 103
Example of the system Table
sysDescr: “Cisco Gateway”
sysObjectID: 1.3.6.1.4.1.9.1.1
sysUpTime: 37153422 (4 days, 7 h, 12 min, 14.22 s)
sysContact: “[email protected]”
sysName: “bordergateway.di.unipi.it”
sysLocation: “Corso Italia, Room 24, 2nd floor.”
sysServices: 6 (bridge and router functions)
X X X X X
Phy
sica
l lay
er (
e.g.
rep
eate
r)
Dat
a-lin
k la
yer
(e.g
. brid
ge)
Inte
rnet
laye
r (e
.g. I
P r
oute
r)
End
-to-
end
(e.g
. IP
Hos
t)
App
licat
ion
(e.g
. NF
S s
erve
r)
J.Schönwälder - L.Deri v. 1.4 Network Management / 104
"interface“ GroupifI
ndex
(1)
ifDes
cr(2
)
ifTyp
e(3)
ifMtu
(4)
ifSpe
ed(5
)
ifPhy
sAdd
ress
(6)
ifA
dm
inS
tatu
s(7)
ifOpe
rSta
tus(
8)
ifLas
tCha
nge(
9)
ifInO
ctet
s(10
)
ifInU
cast
Pkt
s(11
)
ifInN
Uca
stP
kts(
12)
ifInD
isca
rds(
13)
ifInE
rror
s(14
)
ifInU
nkno
wnP
roto
s(15
)
ifOut
Oct
ets(
16)
ifOut
Uca
stP
kts(
17)
ifOut
NU
cast
Pkt
s(18
)
ifOut
Dis
card
s(19
)
ifOut
Err
ors (
20)
ifOut
QLe
n(21
)
ifSpe
cific
(22)
1
2
n
interfaces(2)
ifNumber(1) ifTable(2)
ifEntry(1)
J.Schönwälder - L.Deri v. 1.4 Network Management / 105
Case diagrams illustrate dependencies between Variables:
the number of packets delivered by a network interface to the next higherprotocol layer: ifInUcastPkts + ifInNUcastPkts.
the number of packets received by the network:(ifInUcastPkts + ifInNUcastPkts) + ifInDiscards + ifInUnknownProtos + ifInErrors
he number of actually transmitted packets:(ifOutUcastPkts + ifOutNUcastPkts) - ifOutErrors - ifOutDiscards
Case Diagram for the "interface“ Group
ifInUcastPkts+
ifInNUcastPkts
ifOutUcastPkts+
ifOutNUcastPkts
ifInDiscards
ifInUnknownProtos
ifInErrors
ifOutErrors
ifOutDiscards
J.Schönwälder - L.Deri v. 1.4 Network Management / 106
ipN
etT
oMed
iaT
able
(22)
ipIn
Unk
now
nPro
tos(
7)
"ip“ Groupip
For
war
ding
(1)
ipD
efau
ltTT
L(2)
ipIn
Rec
eive
s(3)
ipIn
Hdr
Err
ors(
4)
ipIn
Add
rErr
ors(
5)
ipF
orw
Dat
agra
ms(
6)
ipIn
Dis
card
s(8)
ipIn
Del
iver
s(9)
ipO
utR
eque
sts(
10)
ipO
utD
isca
rds(
11)
ipO
utN
oRou
tes(
12)
ipR
easm
Tim
eout
(13)
ipR
easm
Req
ds(1
4)
ipR
easm
OK
s(15
)
ipR
easm
Fai
ls(1
6)
ipF
ragO
Ks(
17)
ipF
ragF
ails
(18)
ipF
ragC
reat
es(1
9)
ipA
ddrT
able
(20)
ipR
oute
Tab
le(2
1)
ip(4)
ipR
outin
gDis
card
s(23
)
J.Schönwälder - L.Deri v. 1.4 Network Management / 107
Case Diagram for the “ip“ Group
ipInDelivers ipOutRequests
ipInAddrErrors
ipInHdrErrors
ipInReceives
ipOutNoRoutes
ipOutDiscards
ipForwDatagrams
ipFragOKs
ipFragCreates
ipFragFails
ipInUnknownProtos
ipInDiscards
ipReasmOKs
ipReasmFails
ipReasmReqds
J.Schönwälder - L.Deri v. 1.4 Network Management / 108
Further MIBs: Transmission [1/5]
MIB Description RFC
IEEE 802.3 Repeater Devices 2108
Data Link Switching 2024
IEEE 802.5 1748
ATM 1695
SMDS 1694
Ethernet 1650
Frame Relay 1604
SONET / SDH 1595
FDDI 1512
Link Control Protocol of PPP 1471
Multiprotocol Interconnect over X.25 1461
DS3 / E3 1407
DS1 / E1 1406
Frame Relay DTEs 1315
J.Schönwälder - L.Deri v. 1.4 Network Management / 109
Further MIBs: Network Layer [2/5]
MIB Description RFC
IP Forwarding Table 2096
RMON 1757
RMON Version 2 2021
IP Mobility Support 2006
OSPF Version 2 1850
RIP 1724
BGP Version 4 1657
Token Ring extensions to RMON 1513
Identification MIB 1414
BGP Version 3 1269
J.Schönwälder - L.Deri v. 1.4 Network Management / 110
Further MIBs: Application Layer [3/5]MIB Description RFC
WWW servers 2039
RDBMS 1697
DNS Resolver 1612
DNS Server 1611
X.500 Directory 1657
Mail 1566
Network Services 1565
Host Resources 1514
J.Schönwälder - L.Deri v. 1.4 Network Management / 111
Further MIBs: Hardware Specific [4/5]
MIB Description RFC
Entity 2037
Printer 1759
Modem 1696
Parallel printer-like Hardware 1660
RS-232-like Hardware 1659
Character Stream Devices 1658
UPS 1628
J.Schönwälder - L.Deri v. 1.4 Network Management / 112
Further MIBs: Vendor Specific [5/5]
MIB Description RFC
APPC 2051
TCP/IPX Connection 1792
SNA Data Link Control (SDLC) 1747
AppleTalk 1742
SNA NAUs 1666
DECNET Phase IV 1559
SNMP over IPX 1420
SNMP over AppleTalk 1419
J.Schönwälder - L.Deri v. 1.4 Network Management / 113
Relations Between MIBs [1/2]
Interface Statistics X
IP, TCP & UDP Statistics X
SNMP Statistics X
Host Job Counts X
Host File System Information X
Link Testing X X
Network Traffic Statistics X X X
Address Tables X X
Host Statistics X X
MIB
-II
Hos
t
Rep
eate
r
Brid
ge
RM
ON
J.Schönwälder - L.Deri v. 1.4 Network Management / 114
Relations Between MIBs [2/2]
Historical Statistics X
Spanning Tree Performance X
Wide Area Link Performance X
Thresholds for any variable X
Configurable Statistics X
Traffic Matrix with all Nodes X
‘Host Top N’ Information X
Packet/Protocol Analysis X
Distributed Logging X
MIB
-II
Hos
t
Rep
eate
r
Brid
ge
RM
ON
J.Schönwälder - L.Deri v. 1.4 Network Management / 115
2.4 Simple Network Management Protocol Version 1
Transmission ControlProtocol (TCP)
User DatagrammProtocol (UDP)
Internet Protocol (IP) &Internet Control MessageProtocol (ICMP)
ATM ISDN 802.3 802.5
Virtual Terminal
File Transfer Electronic Mail
Name Service Network Filesystem
Simple Network
Management Protocol
Information Retrieval
Network Layer
Transport Layer
Application Layer
J.Schönwälder - L.Deri v. 1.4 Network Management / 116
Lexicographical Ordering
MIB instances are arranged in the MIB according to their lexicographical ordering.
The ordering is determined by the value of the object identifier that identify theinstance.
The SNMP log uses the lexicographical order, in order to read (walk) conceptualtables or unknown MIBs.
J.Schönwälder - L.Deri v. 1.4 Network Management / 117
Example of Lexicographical Ordering
Object Identifier: Value: Object Identifier Value :1.1.0 10.1.2.3 1.3.1.2.4 71.2.1.0 "FilterFresh" 1.3.1.2.5 81.2.2.0 54321 1.3.1.2.6 91.3.1.1.1 1 1.3.1.3.1 21.3.1.1.2 2 1.3.1.3.2 31.3.1.1.3 3 1.3.1.3.3 21.3.1.1.4 4 1.3.1.3.4 21.3.1.1.5 5 1.3.1.3.5 31.3.1.1.6 6 1.3.1.3.6 31.3.1.2.1 21.3.1.2.2 31.3.1.2.3 5
With this ordering the conceptual table structure is lost as the walk output is a listand no longer a table.
the SNMP protocol operates only on this arranged list.
J.Schönwälder - L.Deri v. 1.4 Network Management / 118
SNMPv1 protocol operations (RFC 1157)
Manager Agent
Get
Response
Manager Agent
Set
Response
Manager Agent
GetNext
Response
ManagerAgent
Trap
Note: the SNMP protocol can only exchange (a list of) scalars.
J.Schönwälder - L.Deri v. 1.4 Network Management / 119
SNMPv1 Message Format
PDU type request-id 0 0 variable-bindings
GetRequest, GetNextRequest, SetRequest:
value1name1 value2 valuenname2 namen...
variable-bindings:
PDU type request-id error-status error-index variable-bindings
GetResponse:
PDU type enterprise address generic vbs
Trap:
specific timestamp
version community SNMP PDU
SNMP message:
J.Schönwälder - L.Deri v. 1.4 Network Management / 120
The Get operation can be used for reading one or more variables.
Possible errors when processing a GET operation: noSuchName the requested instance does not exist or is not a leaf.
tooBig the result of the request does not fit not into the response (UDP).
genErr any other error occurred.
In the case of several errors occurred, only one error is signalled as error-indexand error-status are unique in the PDU.
SNMPv1 Get Operation
Manager Agent
Get
Response
J.Schönwälder - L.Deri v. 1.4 Network Management / 121
Example of Get Operation
Get(1.1.0)Response(noError@0, 1.1.0=10.1.2.3)
Get(1.2.0)Response(noSuchName@1, 1.2.0)
Get(1.1)Response(noSuchName@1, 1.1)
Get(1.1.0, 1.2.2.0)Response(noError@0, 1.1.0=10.1.2.3, 1.2.2.0=54321)
Get(1.3.1.1.4, 1.3.1.3.4)Response(noError@0, 1.3.1.1.4=4, 1.3.1.3.4=2)
Get(1.1.0, 1.2.2.0, 1.1)Response(noSuchName@3, 1.1.0, 1.2.2.0, 1.1)
J.Schönwälder - L.Deri v. 1.4 Network Management / 122
SNMPv1 GetNext Operation
It retrieves the object name and the value of the next instance. This operation isused to discover MIB structures and read tables.
The GetNext operation allows MIB instances to be read in accordance to thelexicographical order.
Using multiple/successive GetNext operations it is possible to read the completeMIB without knowing its structure.
Possible errors when processing a GetNext Operation: noSuchName the requested instance does not exist (= end of MIB). tooBig the result of the request does not fit not into the response (UDP). genErr any other error occurred.
Manager Agent
GetNext
Response
J.Schönwälder - L.Deri v. 1.4 Network Management / 123
Example of GetNext Operation
GetNext(1.1.0)Response(noError@0, 1.2.1.0=FilterFresh)
GetNext(1.2.1.0)Response(noError@0, 1.2.2.0=54321)
GetNext(1.1)Response(noError@0, 1.1.0=10.1.2.3)
GetNext(1.3.1.1.1)Response(noError@0, 1.3.1.1.2=2)
GetNext(1.3.1.1.6)Response(noError@0, 1.3.1.2.1=2)
GetNext(1.3.1.1.1, 1.3.1.2.1, 1.3.1.3.1)Response(noError@0, 1.3.1.1.2=2, 1.3.1.2.2=3, 1.3.1.3.2=3)
J.Schönwälder - L.Deri v. 1.4 Network Management / 124
SNMPv1 Set Operation
The Set Operation writes values in one or more MIB instances. The Set Operation is atomic. With the help of the set operation new MIB instances can also be created, if the
MIB definition permits (there is no standard procedure defined in SNMPv1 forinstance creation).
Possible errors when processing a Set operation: noSuchName the requested instance does not exist and cannot be created. badValue the specified value is of wrong type. tooBig the result of the request does not fit not into the response (UDP). genErr any other error occurred.
The error code readOnly is also defined, but not usually used!
Manager Agent
Set
Response
J.Schönwälder - L.Deri v. 1.4 Network Management / 125
Example of Set Operation
Set(1.2.1.0=HotJava)Response(noError@0, 1.2.1.0=HotJava)
Set(1.1.0=foo.bar.com)Response(badValue@1, 1.1.0=foo.bar.com)
Set(1.1.1=10.2.3.4)Response(noSuchName@1, 1.1.1=10.2.3.4)
Set(1.2.1.0=HotJava, 1.1.0=foo.bar.com)Response(badValue@2, 1.2.1.0=HotJava, 1.1.0=foo.bar.com)
Set(1.3.1.1.7=7, 1.3.1.2.7=2, 1.3.1.3.7=3)Response(noError@0, 1.3.1.1.7=7, 1.3.1.2.7=2, 1.3.1.3.7=3)
J.Schönwälder - L.Deri v. 1.4 Network Management / 126
SNMPv1 Trap Operation
With the trap operation and agent can emit an event and inform a manager. Note:a manager can be configured to discard traps!
The receipt of a trap operation is not acknowledged thus is unreliable as it can belost during the transfer.
The production of traps can lead to so-called trap storms, if e.g. after a powerfailure all devices want to display the restart at the same time.
Agents can be normally configured with the IP addresses of hosts where traps canbe dispatched. However there is no standard technique in SNMPv1 for such agentconfiguration. Usually a configuration file (not the MIB) is used.
Although if traps are used, polling is still necessary (for instance the agent mightbe down)
ManagerAgent
TrapNOTE:• The only operation Agt ->Mgr• Unsolicited operation
J.Schönwälder - L.Deri v. 1.4 Network Management / 127
Example of SNMPv1 Trap Operation
ColdStartTrap(generic=0, specific=0)
WarmStartTrap(generic=1, specific=0)
LinkDownTrap(generic=2, specific=0, 1.3.6.1.2.1.2.2.1.1.2=2)
LinkUpTrap(generic=3, specific=0, 1.3.6.1.2.1.2.2.1.1.2=2)
AuthenticationFailureTrap(generic=4, specific=0)
EnterpriseSpecific (QMS, qmsPtrErrorMsg)Trap(generic=6, specific=1, enterprise=1.3.6.1.4.1.480,
1.3.6.1.4.1.480.2.1.1.1=out of paper)
J.Schönwälder - L.Deri v. 1.4 Network Management / 128
2.5 Simple Network Management Protocol Version 2c
There are some variants of of SNMP Version 2:
SNMPv2p
SNMPv2 version with party-based security model, historical
SNMPv2c
SNMPv2 with trivial community-based security model, experimental
SNMPv2u
SNMPv2 with a user-based security model, historical
SNMPv2*
SNMPv2 with security and administration model, historical
The term SNMPv2 is ambiguous. SNMPv2c found some spreading, although IETFhas never standardised it.
Work on a solution of the security problems has blocked improvements of otherprotocol characteristics (too) for a long time.
J.Schönwälder - L.Deri v. 1.4 Network Management / 129
SNMPv2c protocol operations (RFC 1905)
Manager Agent
Get
Response
Manager Agent
Set
Response
Manager Agent
GetNext
Response
ManagerAgent
Trap
Manager/Agent Manager
Inform
Response
Manager Agent
GetBulk
Response
J.Schönwälder - L.Deri v. 1.4 Network Management / 130
SNMPv2c Message Format
PDU type request-id 0 0 variable-bindings
GetRequest, GetNextRequest, SetRequest, Trap, InformRequest:
value1name1 value2 valuenname2 namen...
variable-bindings:
PDU type request-id error-status error-index variable-bindings
GetResponse:
version community SNMP PDU
SNMP message:
GetBulkRequest:
PDU type request-id non-reps max-reps variable-bindings
J.Schönwälder - L.Deri v. 1.4 Network Management / 131
Exceptions allow instance access errors to be signaled to MIB authorities, withoutcausing the whole operation to fail (as happened in SNMPv1).
Example:
Get(1.1.0, 1.1.1, 1.2.0)Response(noError@0, 1.1.0=10.1.2.3, 1.1.1=noSuchInstance,
1.2.0=noSuchObject)GetNext(1.1, 1.5.42)Response(noError@0, 1.1.0=10.1.2.3, 1.5.42=endOfMibView)
SNMPv2 Exceptions (RFC 1905)
SNMPv2 Exception SNMPv1 Status Used by
noSuchObject noSuchName Get
noSuchInstance noSuchName Get
endOfMibView noSuchName GetNext, GetBulk
J.Schönwälder - L.Deri v. 1.4 Network Management / 132
Not existing MIB instances produce an exception and not an error.
Similar to the equivalent SNMPv1 operations.
SNMPv2c Get and GetNext Operations
Manager Agent
Get
Response
Manager Agent
GetNext
Response
J.Schönwälder - L.Deri v. 1.4 Network Management / 133
SNMPv2c Set Operation
There are 14 possible error codes during processing of set operations:wrongValue wrongEncoding wrongTypewrongLength inconsisentValue noAccessnotWritable noCreation inconsisentNameresourceUnavailable commitFailed undoFailed
There are two more error codes that have been defined but not really used:readOnly, authorizationError
No support of error codes that depend on the object type.
Manager Agent
Set
Response
J.Schönwälder - L.Deri v. 1.4 Network Management / 134
SNMPv2c GetBulk Operation
An extension of the GetNext operation:
It returns the first N elements (non repetition) of the varbind list treated asnormal GetNext operations.
The following items of the varbind list treated as repeated Get Next operation,whereby M (max repetition) indicates the max number of repetitions.
The GetBulk operation is similar to the GetNext operation on the lexicographicalarranged list of the MIB instances and has therefore no knowledge of tableboundaries.
Manager Agent
GetBulk
Response
J.Schönwälder - L.Deri v. 1.4 Network Management / 135
Example of the GetBulk Operation GetBulk(non-repeaters=0, max-repetitions=4, 1.1)
Response(noError@0, 1.1.0=10.1.2.3, 1.2.1.0=FilterFresh, 1.2.2.0=54321, 1.3.1.1.1=1)
GetBulk(non-repeaters=1, max-repetitions=2 1.2.2, 1.3.1.1, 1.3.1.2, 1.3.1.3)
Response(noError@0, 1.2.2.0=54321, 1.3.1.1.1=1, 1.3.1.2.1=2, 1.3.1.3.1=2, 1.3.1.1.2=2, 1.3.1.2.2=3, 1.3.1.3.2=3)
Without knowledge about the length of a table it is difficult for the manager toselect a suitable number for max repetitions:
if max-repetitions is too small, then there is no efficiency increase of GetBulkwith respect to the GetNext operation .
if max-repetitions is too large, then a large number of unnecessary instancesare read .
The agent can possibly produce a response, which can either get lost in large/busynetworks or not be processed at all by the manager (this causes the manager toretransmit the request).
If max repetitions is large and reading the MIB instances is time-consuming,agents can receive multiple times the manager’s request (e.g. due toretransmission) thus blocking the agent for some time.
J.Schönwälder - L.Deri v. 1.4 Network Management / 136
SNMPv2c Trap Operation
It corresponds logically to the SNMPv1 Trap operation.
Trap specific information (sysUpTime, trapType) is accommodated in the varbindlist.
Trap types are indicated by Object Identifier and not by a pair of numbers (generic,specific) as in SNMPv1.
ManagerAgent
Trap
J.Schönwälder - L.Deri v. 1.4 Network Management / 137
SNMPv1 vs. SNMPv2c Traps
In SNMPv2 MIBs may now include NOTIFICATION-TYPE macros. SNMPv1 Trap
myLinkDown TRAP-TYPE ENTERPRISE myEnterprise VARIABLES { ifIndex } DESCRIPTION "A myLinkDown trap signifies that the sending SNMP application
entity recognises a failure in one of the communications links represented in the agent's configuration."
::= 2
SNMPv2 TraplinkUp NOTIFICATION-TYPEOBJECTS { ifIndex }STATUS currentDESCRIPTION"A linkUp trap means that the entity has detected that the ifOperStatus
object has changed to Up"::= { snmpTraps 4 }
J.Schönwälder - L.Deri v. 1.4 Network Management / 138
SNMPv2c Inform Operation
The structure of the PDU corresponds to a SNMPv2 Trap PDU.
It allows (new) managers to talk each other (SNMPv1 limited interaction to agent-manager or vice-versa).
The receipt of a Inform message is acknowledged with a Response message.
Example: Inform(1.2.2.0=54321, 1.4.1.0=1.4.2.43,
1.3.1.2.2=16, 1.3.1.3.2=3)Response(noError@0, 1.2.2.0=54321, 1.4.1.0=1.4.2.43,
1.3.1.2.2=16, 1.3.1.3.2=3)
Manager/Agent Manager
Inform
Response
J.Schönwälder - L.Deri v. 1.4 Network Management / 139
SNMPv2c and SNMPv1 Error Codes
SNMPv2 SNMPv1 Comment
noError noError all operations
tooBig tooBig Get, GetNext, Set, Inform
noSuchName noSuchName Get, GetNext, Set (only with SNMPv1)
badValue badValue Set (only with SNMPv1)
readOnly readOnly not used
genErr genErr Get, GetNext, GetBulk, Set
wrongValue badValue Set (only with SNMPv2c)
wrongEncoding badValue Set (only with SNMPv2c)
wrongType badValue Set (only with SNMPv2c)
wrongLength badValue Set (only with SNMPv2c)
inconsisentValue badValue Set (only with SNMPv2c)
noAccess noSuchName Set (only with SNMPv2c)
notWritable noSuchName Set (only with SNMPv2c)
noCreation noSuchName Set (only with SNMPv2c)
inconsisentName noSuchName Set (only with SNMPv2c)
resourceUnavailable genErr Set (only with SNMPv2c)
commitFailed genErr Set (only with SNMPv2c)
undoFailed genErr Set (only with SNMPv2c)
authorizationError noSuchName not used
J.Schönwälder - L.Deri v. 1.4 Network Management / 140
SNMP v2 vs SNMP v1
Improved Performance via the Get-Bulk PDU.
Definition of additional datatypes and formalisms based on implementationexperience of SNMPv1 agents/managers.
Transport Service Independence: mappings for SNMPv2 have been defined forseveral transports and not for just UDP (TCP is on the way!).
Redefined the Trap PDU:
It has the same format of the other PDUs
It may be sent to zero, one or many managers
J.Schönwälder - L.Deri v. 1.4 Network Management / 141
2.6 SNMP V3
Design goals of SNMPv3: Issue of secure SET! protocol operations. Definition (hopefully) of a long-living architecture model Support of cheap simple and more expensive complex implementations
(scalability). Independence of the standards Use of existing material (mostly MIBs) when possible (design reuse) SNMP is to remain as simply as possible
Several (commercial and open source) implementation available.
Spreading in real networks still relatively small (most network devices still useSNMPv1).
J.Schönwälder - L.Deri v. 1.4 Network Management / 142
The SNMP engine of a SNMP entity consists of several subsystems and adispatcher.
The manager/agent model is replaced by a number of smaller “applications ”.
The modularity permits incremental advancement of SNMP by means of SNMPContext (RFC 2571)
Architectural Model of SNMPv3 (RFC 2571)
SecuritySubsystem
Message ProcessingSubsystem
Access ControlSubsystem
Dispatcher
SNMP Engine
CommandGenerator
SNMP Applications
NotificationReceiver
CommandResponse
NotificationOriginator
ProxyForward
other
SNMP Entity
J.Schönwälder - L.Deri v. 1.4 Network Management / 143
SNMP Context (RFC 2571)
A context is a quantity of management information that a SNMP Entity can haveaccessed to. For each subsystem:
a SNMP-Entity has potentially access to several contexts.
The same information can be present in several contexts.
In a management domain an instance of a Managed Objects is uniquely identifiedby the following items:
• the identification of the SNMP engines in a SNMP Entity (e.g. „xzy“).
• the name of the context in a SNMP Entity (e.g. „board1“).
• the identification of the type of the Managed Objects (e.g. „IF-MIB::ifDescr).
• the identification of the Instance (e.g. „1“).
Note: the identification of an SNMP engine does not have to do anything with theiraddressing.
J.Schönwälder - L.Deri v. 1.4 Network Management / 144
SNMP Manager in SNMPv3: Architectural Model
CommandGenerator
NotificationReceiver
PDUDispatcher
MessageDispatcher
TransportMappings
UDP IPX
v1MP
v2cMP
v3MP
other MP
CommunitySecurity Model
User-basedSecurity Model
otherSecurity Model
Security SubsystemMessage ProcessingSubsystem
NotificationOriginator
J.Schönwälder - L.Deri v. 1.4 Network Management / 145
SNMPv3 Agent in SNMPv3: Architectural Model
PDUDispatcher
MessageDispatcher
TransportMappings
UDP IPX
v1MP
v2cMP
v3MP
other MP
CommunitySecurity Model
User-basedSecurity Model
otherSecurity Model
Security SubsystemMessage ProcessingSubsystem
CommandResponse
NotificationOriginator
ProxyForwarder
Access ControlSubsystem
MIB Instrumentation
View-basedAccess Control
J.Schönwälder - L.Deri v. 1.4 Network Management / 146
SNMPv3 Message Format (RFC 2572)
Security information are in the centre of the message.
msgData contain either a ScopedPDU or an encoded ScopedPDU.
msgID is used for the association of responses to pending inquiries.
msgSecurityParameter depends on msgSecurityModel.
msgVersion msgGlobalData msgSecurityParameter msgData (scopedPDU)
SNMPv3Message:
msgID msgMaxSize msgFlags msgSecurityModel
MsgGlobalData:
msgEngineID msgEngineBoots msgEngineTime msgUserName
UsmSecurityParameter:
msgAuthParams msgPrivParams
contextEngineID contextName SNMPv2 PDU (as defined in RFC 1905)
ScopedPDU:
J.Schönwälder - L.Deri v. 1.4 Network Management / 147
SNMPv3 Textual Conventions
SnmpEngineID
unique Identification of the SNMP Engine.
SnmpSecurityModel
unique Identification of the Security Models.
SnmpMessageProcessingModel
unique Identification of the Message Processing Models.
SnmpSecurityLevel
Message Security Level (noAuthNoPriv, authNoPriv, authPriv).
the security level is coded and transfer in the msgFlags.
KeyChange
Behind these Textual Convention hides itself an algorithm for USM (UserSecurity Model).
Defines a cryptographic algorithm to change authentication or encryption keys.
Note: If a code was broken and if the aggressor knows all code modificationmessages, then he can calculate the current code.
J.Schönwälder - L.Deri v. 1.4 Network Management / 148
Security Issues
Blow you can find the questions which must be answered when a decision whetheran operation has to be performed:
Is the received message authentic?
Who (requestor name) would like to get the operation executed?
Which objects are affected by the operation?
Which access rights has the requestor regarding the objects concerned?
Questions 1 and 2 are answered by the measures to the protection of themessages (authentication, encoding).
Questions 3 and 4 are answered by a model to the access supervision (Unix-like).
J.Schönwälder - L.Deri v. 1.4 Network Management / 149
Authentication in SNMPv3 (RFC 2574)
Cryptographic strong hash functions (MD5, SHA-1) for the calculation ofcryptographically strong checksums (Message Authentication Code or MAC).
Algorithmic production of key KU from a password is done by applying a hashfunction to the 1 MB long password concatenation.
Derivative "more localised" key KUL is derived from key KU for the SNMP Engine Eusing MD5: KUL = MD5(KU, E, KU)
HMAC (keyed hashing) of a message M using KUL and MD5: Extension of KUL to 64 bytes by adding 0x00 bytes. Set IPAD to a 64 bytes vector of value 0x36. Set OPAD to a 64 bytes vector of value 0x56. Calculate KI := KULX XOR IPAD and KO := KULX XOR OPAD. Calculate HMAC := MD5(KO, MD5(KI, M)). The first 96 bits of HMAC result in the MAC of the message M.
SNMPv3 includes protection against repetitions of old messages from looselysynchronised clocks and time stamp data integrity.
J.Schönwälder - L.Deri v. 1.4 Network Management / 150
Authentication with Message Authentication Code (MAC) is efficient to implement.
The Hash function must be cryptographically strong and a "good" MAC producer.
The MD5 algorithm (RFC 1321) can be implemented in software with acceptableperformance (128 bit digest).
The Secure Hash algorithm 1 (SHA-1) is considered at present stronger of MD5 .
Data Integrity and Authentication
Hash-Function
MAC
DataKey
MAC DataUser
Hash-Function
MAC
DataKey
MAC DataUser
= ?
Senthe receiver
J.Schönwälder - L.Deri v. 1.4 Network Management / 151
Protection Against Repetitions of Old Messages
A recipient must know the "time-of-day" of the authoritative SNMP engine for the message.
If the received message is situated in the validity interval and is ”younger" than the last validmessage, then the message will become processed and the clocks adapted.
Before the beginning of authenticated communication the clocks must be synchronised.
engineBoots engineTime
Timestamp DataengineID Timestamp DataengineID
Authoritative Engine Receiver
engineBoots
engineTime
authClock
latestRecvTime
Lifetime
Timewindow
Valid?
J.Schönwälder - L.Deri v. 1.4 Network Management / 152
Protection Against Sniffing
For protecting against sniffing the ScopedPDU can be optionally encoded.
Data Encryption Standard (of the) in Cipher Block Chaining Modus (CBC) is usedfor encryption.
Encryption is relatively complex and should only be used in area/situations wherean encoding is really necessarily.
SNMPv3 permits "relatively protected" code modification without encryption (byusing message digest).
of the (CBC)
DataKey
Secured DataUser
of the (CBC)
DataKey
Secured DataUser
Sender Receiver
J.Schönwälder - L.Deri v. 1.4 Network Management / 153
Access Control in SNMPv3 (RFC 2575)
whosecurityModel
securityNamegroupName
where contextName
howsecurityModel
securityLevel
why viewType
what object type
which object instancevariableName
viewName
yes/no
The securityLevel determines whether a message without authentication(noAuth/noPriv), with authentication (auth/noPriv) or with authentication andencoding (auth/priv) is dispatched,
The securityName is a name independent of the securityModel.
J.Schönwälder - L.Deri v. 1.4 Network Management / 154
A view subtree is the quantity of all MIB objects, which possess common OIDprefix.
A view tree family is the combination of one view subtree OID prefix with a filter(bitmask), which determines whether an item of the prefix is significant or not.
A view is an ordered set of view tree families.
It defines the access rights for read view, write view and notify view.
MIB Views (RFC 2575)
1
1 2
1 2 1
1 1 2 3
1 2 31 1 12 2 2
1 1 12 2 2
1.1.2.1.*.11.2.1.2.*
J.Schönwälder - L.Deri v. 1.4 Network Management / 155
View-based Access Control (VACM) MIB Tables (RFC 2575)
vacmContextTable: Example:
vacmContextName ““
The vacmContextTable lists all locally existing contexts.
vacmSecurityToGroupTable: Example:
vacmSecurityModel usm
vacmSecurityName „initial“
vacmGroupName „initial“
vacmSecurityToGroupStorageType nonVolatile
vacmSecurityToGroupStatus active
The vacmSecurityToGroupTable does form a tuple (securityModel, securityName)on a VACM group.
A tuple (securityModel, securityName) can be member of several VACM groups.
J.Schönwälder - L.Deri v. 1.4 Network Management / 156
VACM MIB Tables (RFC 2575)
vacmAccessTable: Example 1: Example 2:
vacmGroupName „initial“ „initial“
vacmAccessContextPrefix “ „“
vacmAccessSecurityModel usm usm
vacmAccessSecurityLevel noAuthNoPriv authPriv
vacmAccessContextMatch exact exact
vacmAccessReadView „restricted“ „internet“
vacmAccessWriteView „“ „internet“
vacmAccessNotifyView „restricted“ „internet“
vacmAccessStorageType nonVolatile nonVolatile
vacmAccessStatus active active
The vacmAccessTable assigns to a VACM group (vacmGroupName) the accesswith a given securityModel and securityLevel and a given context for readView,writeView and notifyView.
J.Schönwälder - L.Deri v. 1.4 Network Management / 157
VACM MIB Tables (RFC 2575)
vacmViewTreeFamilyTable: Example:
vacmViewTreeFamilyViewName „internet“
vacmViewTreeFamilySubtree 1.3.6.1
vacmViewTreeFamilyMask “
vacmViewTreeFamilyType included
vacmViewTreeFamilyStorageType nonVolatile
vacmViewTreeFamilyStatus active
Several entries with the same value for vacmViewTreeFamilyViewName define aMIB View.
A MIB View can explicitly include or exclude specific instances.
The vacmViewTreeFamilyMask defines a filter, which specifies whether a OID is asignificant component or not.
J.Schönwälder - L.Deri v. 1.4 Network Management / 158
Characteristics and Issues of Access Control
The access decision is determined by both the instance name and type.
By means of a suitable MIB structure and bitmask it is possible to reduce thenumber of necessary access control rules.
The examination of access rules in an agent can be very expensive, since it isoften not possible to know how many instances with a GetNext or GetBulkoperation have to be skipped.
The access control (RFC 2575) forbids the affiliation of a securityName in severalgroups. As consequence the configuration of pretty similar but slightly differentaccess rules for different securityNames are complex to configure.
J.Schönwälder - L.Deri v. 1.4 Network Management / 159
It is possible for have several iterative phases for the MIB definitions until it is indraft status.
MIB definitions cannot however be further changed, if they were released.
2.7 MIB Implementation of the Agent Extensibility Protocol
AgentImplementation
Analysis andModelling
MIB ViewDraft
MIB Module Draft
Manager Implementation
Test Manager
Test AgentObject Analysis OID StructureModule Structure
MIB Module
ImplementationLimitations
Test Suites
Test SuitesAgent Requests
J.Schönwälder - L.Deri v. 1.4 Network Management / 160
Modelling a System
Components:
Identification of the logical and physical components of a device or a service.
Attributes:
Constant parameters, those that describe the modelled components.
Relations:
Relations between components (e.g. be contain in, logical order).
Relations between attributes of components.
Cardinality of of components and attributes.
Status attributes:
Clearly distinguish between the required and the current status.
Document with status transition diagrams all the possible status transitions.
J.Schönwälder - L.Deri v. 1.4 Network Management / 161
Modelling a System
Statistics:
Statistics document, what a component did in the past.
It needs to be defined a lifetime for statistics (how long they will remain valid).
Actions:
Actions make it possible to execute well-defined operations on a component.
It is necessary to define the actions parameters.
The effects of an action on the component or other sections of the systemneed to be defined.
It needs to be defined the action behaviour when multiple managerssimultaneously execute the same action without any undefined status.
It is necessary to define what acceptable actions can be defined in a certainstatus.
Tradeoffs between a single complex action or multiple simple actions thatproduce the same behaviour need to be analysed.
J.Schönwälder - L.Deri v. 1.4 Network Management / 162
MIB Name Conventions
Similar definitions should be registered together in the registration tree.
Names of object types should begin the logical grouping with a common prefix,that suggest (e.g. sysDescr, sysUpTime).
Names for counter are to be selected in the Plural form.
Names of conceptual tables should possess the ending Table (e.g. ifTable).
Names of lines of a conceptual table should possess the ending entry (e.g.ifEntry).
All items of a conceptual table should use common prefix in the name (e.g. ifType,ifDescr).
J.Schönwälder - L.Deri v. 1.4 Network Management / 163
Tables Indexing
The selection of the indexing of a table (as for databases) has different consequences, whichmust be analysed and be weighed out against each other with several alternatives:
Access ControlThe selection and the sequence of index items can strongly influence the number ofnecessary rules for the definition of MIB Views hence the administration expenditure.
Efficient accesses to table sectionsFrequently needed access to subsets of a table can be supported by suitable selection of theindex items.
Object Identifier LengthObject Identifier can have a max. length of 128 components in SNMP. Long object identifiersproduces high overhead.
Lexicographical Ordering
The order influences the usage and efficiency of an implementation.
J.Schönwälder - L.Deri v. 1.4 Network Management / 164
Tables can be extended exactly if there is a 1:1 relationship between all possiblelines of the tables.
Tables which possess only 1:1 relationship for a part of the possible lines, can usean extended version of the prior indexing.
Relations between MIB Tables
Base Table
Base Table
Augmenting Table
Subtables
J.Schönwälder - L.Deri v. 1.4 Network Management / 165
Relations between MIB Tables
N:M relations with M > N can be expressed by extending index of the first tablewith further index variables.
Tables with the same contents but with different ordering sequences can berepresented by appropriately rearranging of the index items.
Base Table
Expansion Table
Base Table Reordered Table
J.Schönwälder - L.Deri v. 1.4 Network Management / 166
Datatypes
Definition of Datatypes: A Textual Conventions should be used, if a datatype is used several times or when other
modules should be able to reuse the datatype. Datatypes can be defined „inline“ only if they are used once. In large MIB modules the definition of frequently used datatypes is recommended in their
own module (reduce module cross references).
Floating Point Numbers: Selection of a suitable scaling to avoid rounding floating point numbers Several objects can be used to represent mantissa, base and exponent. IEEE floating point numbers are packed up in a OCTET STRINGER and represented as
a character sequence in the ASCII alphabet.
Handling Large Numbers: To use several objects with different scaling. To allocate e.g. 64-Bit Integer in two 32-Bit Integer. Large numbers are packed up in a OCTET STRINGER and represented as a character
sequence in the ASCII alphabet.
J.Schönwälder - L.Deri v. 1.4 Network Management / 167
Data Structures
Complex Data Structures (Tables in Tables): It is not possible to use complex data structures! (good)
It is always possible to emulate complex data structures by extension tables(workaround).
Linked Lists: Definition of a table with an INTEGER value index
Definition of a ”next" column, similar to a next elements pointer.
Definition of a scalar that defines the beginning of the list.
Binary Trees: Definition of a table with an INTEGER value index.
Definition of one "left" and a "right" column similar to pointers.
Definition of a scalar, that stands for the root of the tree.
In a similar way still more complex data structures can be implemented. It shouldbe checked however very exactly whether the data structures cannot betransferred into simpler tabular forms.
J.Schönwälder - L.Deri v. 1.4 Network Management / 168
Production of new Conceptual Rows
The RowStatus Textual-Convention defines a status machine, that allows newrows to be created inside conceptual tables.
This mechanism is needed when large rows (I.e. the row scalars wouldn’t fit in asingle SNMP SET)
The following status exist:active The active conceptual row is active and ready to use.notInService The conceptual row exists in the agent. It is however not available
for use (this status is associated with a timer so that unused lines donot exist indefinitely).
notReady The conceptual row exists in the agent, however it is still incompleteand requires further information.
createAndGo Set by the manager, in order to produce a new line which immediately becomes active.
createAndWait Set by the manager, in order to produce a new line with notReady.destroy Set by a manager in order to delete a row (e.g. set an instance to an
invalid value).
J.Schönwälder - L.Deri v. 1.4 Network Management / 169
The state transition diagram is simplified as for some transitions (e.g. notReady toactive) further conditions must be met.
Unspecified values can produce an SNMP error message, but no status change.
RowStatus State Transition Diagram
notInServicenotReady
activenotExising
notInService
notInService
activeactive
of t
hetr
oy,
timeo
ut
destroy,timeout
destroy
crea
teA
ndW
ait
active
createAndGo
destroy
notInService
J.Schönwälder - L.Deri v. 1.4 Network Management / 170
One-shot Mode vs. Dribble Mode
One-shot mode:
Identify an unused instance identifier.
Issue a SET for such instance identifier withRowStatus=createAndGo and all variables whichare necessary in order to initialise a row completely.
Dribble mode:
Identify an unused instance identifier
Create a row by setting RowStatus=createAndWait.
Missing values are specified with further SEToperations.
When all the values have been specified,RowStatus is set to active.
Manager Agent
active
createAndGo
Manager Agent
notReady
createAndWait
notInService
more values
active
active
J.Schönwälder - L.Deri v. 1.4 Network Management / 171
Free Index Element Selection: Different Solutions
The management application selects the instance identifier according to itssemantic meaning (e.g. the destination address of a routing table).
The management application reads the entries existing in the table and determinesfrom it a probably unused entry. Nevertheless in the meantime, another management application might have occupied
the same entry. With long tables this operation is sometimes very complex although managers usually do
not interfere.
The MIB module specifies a special object that occupies an unused instanceidentifier. It is required exactly one GET operation (identify the free entry) and a SET operation
(reserve). This algorithm works with several management applications in presence of a suitable
object definition.
The management application selects coincidentally a instance identifier and tries tocreate a row. With small tables sometimes only one set operation is necessary. With large tables the collision frequency increases and thus the effort required to create
a row.
J.Schönwälder - L.Deri v. 1.4 Network Management / 172
Backend-Compiler can produce the following outputs:
Documentation (hypertext versions of MIB modules, diagrams)
Source code for the semiautomatic implementation of agents
Test-cases for testing manager and agent implementations
Inputs for management applications, the MIB definitions needed at run-time.
There is no standardised or generally accepted intermediate format.
MIB-Compiler
Errors and Warnings
SMI Conversion
MIB & SMIDefinitions
FrontendCompiler
IntermediateFormat
BackendCompiler
RuntimeData
Test Sources
Docs
J.Schönwälder - L.Deri v. 1.4 Network Management / 173
A monolithic agent is normally implemented by an individual process whichcontains the SNMP protocol machine and the MIB instrumentation.
The supported MIB modules is determined at compilation time.
The method dispatchers is called during processing of SNMP messages, whichcan either read or modify values from relevant resources.
Monolithic Agents
MIBModule
MIBModule
MIBModule
MethodDispatcher
SNMPEntity
Manager
c vb1 vb2 vb3 vb4
Monolithic Agent
J.Schönwälder - L.Deri v. 1.4 Network Management / 174
Proxy-Agents
SNMP Proxy agents permit managers to access other SNMP agents that are notreachable directly (e.g. behind a firewall) or that are reachable using non IPprotocols (e.g. IPX).
Management applications must (usually) select the appropriate community stringor context in order to enable the proxy to reach the agents (no transparency).
Proxy are important for the implementation of firewalls or for conversion betweendifferent SNMP protocol versions.
SNMPAgent
SNMPAgent
SNMPAgent
ProxyDispatcher
SNMPEntity
Manager
c1 vb1 vb3
Proxy Agent
c2 vb2 c3 vb4
c2 vb2
c3 vb
4
c 1vb 1
vb 3
J.Schönwälder - L.Deri v. 1.4 Network Management / 175
Extensible Agents
Extensible SNMP agents separate the SNMP protocol machine (master agent)from the MIB instrumentation (subagent).
MIB modules can be added by starting further subagents dynamically at runtime. Expandable agents are transparent for management applications. A special protocol regulate communications between the master agent and the
subagents
Sub-Agent
Sub-Agent
Sub-Agent
AgentXDispatcher
SNMPEntity
Manager
AgentX Master-Agent
c vb2
cvb
4
cvb 1
vb 3
c vb1 vb2 vb3 vb4
J.Schönwälder - L.Deri v. 1.4 Network Management / 176
AgentX-Protocol Version 1 (RFC 2257)
The AgentX protocol is a new standard protocol for the implementation ofexpandable SNMP agents.
AgentX Message Coding:
No ASN.1 coding.
Compact representation of object identifier values by coding repetitive OIDprefixes.
Byte order is selected by the subagent (no transformations necessarily, ifmaster agent and subagent on the same system).
AgentX Message Transport:
TCP connections to the port 705.(It is possible to have several AgentX sessions over the same TCPconnection)
UNIX Domain Sockets (/var/agentx/master).
Can be likewise used other local (not standardised) IPC mechanisms.
J.Schönwälder - L.Deri v. 1.4 Network Management / 177
Administrative AgentX Protocol Operations
Master Sub-Agent
Response
Open
IndexAllocate
Response
Register
Response
AddAgentCaps
Response
Response
Response
Response
Master Sub-Agent
RemoveAgentCaps
Unregister
IndexDeallocate
Close
Response
• AgentX Session Establishment• Index Allocation• MIB Registration• Registration of the Agent Capabilities
• Deregistration of the Agent Capabilities• MIB Deregistration• Free of allocated indexes•AgentX Session Termination
J.Schönwälder - L.Deri v. 1.4 Network Management / 178
Index-Allocation, OID Registration, Scoping
Index allocation for common tables between subagents:
Allocation of specific (private) indexes.
Allocation of indexes not used at present.
Allocation of indexes no longer in use.
OID Registration:
Registration of individual instances (instance level registration)1.3.6.1.2.1.2.2.1.1.42 (ifIndex.42)1.3.6.1.2.1.2.2.1.2.42 (ifDescr.42)1.3.6.1.2.1.2.2.1.3.42 (ifType.42)
Registration of MIB Ranges:1.3.6.1.2.1.2.2.1.[1-22].42 (ifIndex.42 - ifSpecific.42)
Scoping:
AgentX can specify scoping with GetBulk operations (similar to CMIP Scope).
J.Schönwälder - L.Deri v. 1.4 Network Management / 179
AgentX Protocol Operations for SNMP Operations
Master Sub-Agent
Get
Response
GetNext
Response
GetBulk
Response
Master Sub-Agent
Notify
TestSet
Response
CommitSet
Response
undoSet
Response
CleanupSet
Response
• SNMP-operations correspond to AgentXoperations.• A SNMP operation can concern severalsubagents.
• Atomicity of SNMP SET operations isguaranteed by the AgentX protocol.
J.Schönwälder - L.Deri v. 1.4 Network Management / 180
Agent Test Cases
Automatic regression tests for quality assurance.
Many test cases can be generated automatically from MIB definitions: Tests for the validation of the object types (type mismatch check).
Tests for checking correct protocol behaviour in particular with incorrect protocolmessages.
Tests for checking correct lexicographical order of MIB instances.
Additional in-depth test cases should be written by an independent (i.e. not the onewho developed the agent) software developer on base of the MIB definition.
MIBDefinitions
MIBCompiler
Agent
AdditionalTest Cases
AgentTesting Tool
TestOutcome
Test Case
Implementation
J.Schönwälder - L.Deri v. 1.4 Network Management / 181
Why did SNMP Succeed?
Standards can be obtained for free by everybody whereas OSI standards costmoney and can be distributed only to the members of the association.
Standards are freely available from FTP/WWW servers in an electronic formwhereas OSI standards are usually on printed paper and need to be ordered byplain mail to ITU that is based on Geneva.
SNMP standards need a relatively short period of time for their standardisation.This has enabled many organisations to define new standards. OSI standardsrequire a long time to evolve and several committee votations.
Prototypes must demonstrate the need for and the feasibility of Internet standards.OSI standards are usually first defined on papers and finally implemented. In orderto produce an RFC it is required to release two or more independentimplementation of the standard in order to prove standard’s feasibility.
J.Schönwälder - L.Deri v. 1.4 Network Management / 182
Example of Free SNMP Implementations
NET-SNMP: http://net-snmp.sourceforge.net/
Scotty: http://wwwhome.cs.utwente.nl/~schoenw/scotty/
JMAPI: http://java.sun.com/products/JavaManagement/
Advent: http://www.adventnet.com/
J.Schönwälder - L.Deri v. 1.4 Network Management / 183
3. OSI Network Management
1. Introduction
2. Internet Management
3. OSI Network Management3.1 Overview
3.2 Structure the Management Information (GDMO)
3.3 Common Management Information Protocol (CMIP)
3.4 Management Functions
4. Telecommunication Management Network
5. Integrated Systems Management
6. Distributed Internet Management
7. Current Developments
J.Schönwälder - L.Deri v. 1.4 Network Management / 184
3.1 Overview
1980 ISO/OSI starts activities in the area network management as part ofthe development of the ISO/OSI reference model.
1985 CCITT (today ITU) begins the definition of the TelecommunicationManagement Network (TMN)
1987 Beginning of the work on OSI System Management.1988 Establishment of the OSI Network Management Forum (NMF), a
manufacturer union for the conversion of the standards.1988-1992 Adjustment of the ISO/OSI standards and the TMN standards
TMN is based on the ISO/OSI standards.1991 OSI Systems Management Overview becomes International
Standard.1990-1997 Deployment of Standards, the basic management functions are
defined (e.g. forwarding and filtering of messages). OSI has small meaning for data communication, in particular since the success of
the Internet. Still the most important standard within the area of the telecommunication
systems, in particular in Europe.
J.Schönwälder - L.Deri v. 1.4 Network Management / 185
Standards Overview
OSI - ManagementFramework
(ISO 7498-4)
Systems ManagementFunctions (SMF)
(ISO 10164-1, ...,10164-22)
Systems ManagementOverview
(ISO 10040)
Management Service andManagement Protocol(ISO 9595, ISO 9596)
Structure of ManagementInformation (SMI)
(ISO 10165-1,...,10165-7)
OSI - BasicReference Model
(ISO 7498-1)
J.Schönwälder - L.Deri v. 1.4 Network Management / 186
Types of Management in the OSI Model
Protocol Management: A protocol specifies the mechanisms and functions that the management protocol must
support. Example: Token management in Token-Ring.
Layer Management: Management functions to be implemented by a layer in the OSI reference model and by
the System Management.
Example : Mechanisms for the initialisation of an OSI environment.
System Management: All management functions necessary for the operation of an OSI communication system.
Prerequisites an operational OSI protocol stack including the management protocols inthe layer 7 of the reference model.
The OSI term "system management" refer to a OSI communication system and isdifferent from the "system management" term used for computers.
J.Schönwälder - L.Deri v. 1.4 Network Management / 187
3.2 Structure the Management-Information (GDMO)
The OSI information model is based on an object-oriented paradigm that specifiesthe type of data, classes, definition and data transmission.
Each Managed Object is an instance of a Managed Object Class (MOC), andspecifies the attributes, behaviour, executable operations, messages generated bythe managed object and optional elements.
The behaviour is defined in plain English and defines the relations betweenattribute values:
the semantic of the attributes, operations and notifications.
the meaning of the return values of operations.
the circumstances where a managed object emits a message (operation).
the relations among the instance attributes.
the relations with other managed objects.
J.Schönwälder - L.Deri v. 1.4 Network Management / 188
OSI Information Model
The following operations can be executed on an attribute: Attribute read (get attribute value)
Attribute set (replace attribute value)
Attribute set to the standard value (if any) (set attribute value to default)
Add a value to a quantity attribute (add member)
Remove a value from a quantity attribute (remove member)
The following operations can be executed on a MO: Instantiation of a new managed object (create)
Deletion of an existing managed objects (delete)
Execution of an operation on a managed object (action)
Notifications are messages emitted asynchronous by a MO at each state change.
Packages permit the modular structure of MOs. It is differentiated between mandatoryconstituents and optional package members.
J.Schönwälder - L.Deri v. 1.4 Network Management / 189
Registration, Inheritance and Containment
Registration: All definitions of a managed object class are registered in the ISO registration tree in order to
uniquely identify it.
Inheritance: Managed object classes can be derived from other managed object classes (inheritance of attributes,
operations and notifications).
Promotes the creation of reusable, generic definitions.
The tree hierarchy imposes the specialisation of managed object classes on the inheritance tree.
A managed object class can be derived from several managed object classes (multiple inheritance).
Containment: Models the "be contained in" relationship between managed objects.
A managed object can be contained in exactly one managed object (tree containment).
Defines the "be contained in" relationship by means of naming.
J.Schönwälder - L.Deri v. 1.4 Network Management / 190
Naming
Local Form:
A local name is used for the unique identification of a managed objects withinthe enclosing managed objects.
The local name is specified by means of a relative distinguished name (RDN)
A RDN is defined by the value of an identified attribute.
Is defined with attribute value tuples, as attributes values association (AVA).
Global Form:
A global name specified for contained management ranging from global namesof the containing managed objects to local object names.
The global name is named distinguished name (DN).
A DN is a sequence of AVAs.
The objects at the root of the name tree have firmly given attributes for thedefinition of AVAs.
J.Schönwälder - L.Deri v. 1.4 Network Management / 191
Containment Example
Distinguished Name (DN):systemID=“University of Pisa", subsystemId="Network Subsystem",communicationsEntityId="XYZ", coProtocolMachineId="CoNS", connectionId=42
Relative Distinguished Name (RDN):connectionId=42
Network Subsystem
subsystemId = "NetworkSubsystem"
Network Entity
communicationsEntityId = "XYZ"
coProtocolMachineId = "CoNS"
Connection-Oriented Protocol Machine
Network ConnectionconnectionId = 42
J.Schönwälder - L.Deri v. 1.4 Network Management / 192
Allomorphism
A managed object of class C1 behaves exactly as a managed object of the classC2.
Classes C1 and C2 do not have to be in a leaving (father-son) relationship.
The implementation must guarantee that only the characteristics of the class arevisible from outside of C2: Operations, which concern all attributes of the class C2 are executed only on the
attributes defined in the class C2.
Notifications are passed on, only if the messages are defined in the class C2.
Additional operations are determined by the real class affiliation. For example with"set attributes VALUE to default" operation the specification for the class C1 avoidsto create inconsistencies.
Allomorphism is rather important for enabling the transition of a MIB to a newversion.
J.Schönwälder - L.Deri v. 1.4 Network Management / 193
GDMO Templates
The Guidelines for the definition of Managed Objects (GDMO) determine the notation, userfor the definition of the Managed Objects.
For MO definition are used templates based on the language ASN.1: managed object class template Definition of a managed object class.
package template Logical group of related definitions.
parameter template Extension mechanism through parameter.
attribute template Definition of individual attributes.
attribute group template Grouping of attributes.
behaviour template Describes the behaviour of managed objects.
action template Defines the operations on a managed object.
notification template Definition the notifications that can be emitted.
name binding template Defines the legal positioning in the naming tree.
References between individual templates are implemented based on the registration bymeans of references.
J.Schönwälder - L.Deri v. 1.4 Network Management / 194
GDMO Example
pduCounterObject MANAGED OBJECT CLASSDERIVED FROM "CCITT REC.X.721(1992)|ISO/IEC 10165-2: 1992":top;CHARACTERIZED BY
basePackage PACKAGE -- in-line PACKAGE definitionATTRIBUTES
pduCounterNameGET;
pduCounterINITIAL VALUE syntax.initialZeroGET;
; -- end of in-line PACKAGE definition; -- end of CHARACTERIZED BY constructCONDITIONAL PACKAGES additionalPackages
PRESENT IF *enable/disable control is required*;REGISTERED AS { object-Identifier 1 }
J.Schönwälder - L.Deri v. 1.4 Network Management / 195
3.3 Common Management Information Protocol (CMIP)
Management-applications
OSI Presentation Layer (ISO 8823)
OSI Session Layer (ISO 8327)
OSI Transport Layer (ISO 8073)
CMISE (ISO 9595)
ACSE (ISO 8650) ROSE (ISO 9072)ACSE (ISO 8650)
FTAM (ISO 8571)
X.25 (ISO 8208)
LAPB (ISO 7776)
X.21 bis (ITU-T)
CLNS (ISO 8348)
IEEE 802.2/802.3
Physical Signaling
J.Schönwälder - L.Deri v. 1.4 Network Management / 196
Protocols and Services Overview
Common Management Information Service Element (CMISE): Services for accessing the management information.
Based on ACSE and ROSE
Common Management Information Protocol (CMIP): Protocol used for the implementation of the CMISE-Services
Association Control Service Element (ACSE): Services for the setup and deletion of connections between applications.
Remote Operations Service Element (ROSE): OSI equivalent of the Remote Procedure Call (RPC).
File Transfer, Access and Management (FTAM): Protocol for data transfer (similar to Internet FTP).
J.Schönwälder - L.Deri v. 1.4 Network Management / 197
CMIS Service Primitives
Operations on Attributes of Managed Objects: Attribute value read M-GET Attribute value modification M-SET Abort of an in progress M-GET M-CANCEL-GET
Operations on Managed Objects: Creation of Managed Objects M-CREATE Deletion of Managed Objects M-DELETE Execution of an operation on a Managed Object M-ACTION
Event Transmission: Transmission of event messages M-EVENT-REPORT
M-SET and M-ACTION can acknowledged (confirmed) and unconfirmed.Remaining service are always acknowledged (confirmed).
CMIS services can be applied to several managed objects and attributes of amanaged objects (scoping).
The services that concern several managed objects or attributes can be called with"best effort" or "atomic" synchronisation.
J.Schönwälder - L.Deri v. 1.4 Network Management / 198
Scoping
For scoping one understands the selection of several managed objects for theexecution of the same operation due to its position in the containment tree.
Selections can be based:
the base instance only
all object instances of the nth layer underneath the base instance
From the base instance to the nth layer underneath the base instance
The entire tree including the base instance
Scoping can be used for M-GET, M-SET, M-ACTION and M-DELETE.
J.Schönwälder - L.Deri v. 1.4 Network Management / 199
Scoping Example
Basis instance Instances of the nth layer
All instances up to the nth layer All instances under the base instance
J.Schönwälder - L.Deri v. 1.4 Network Management / 200
Filtering
For Filtering one understands the selection of several Managed Objects for theexecution of the same operation based on the instance attribute values.
A test is defined by a filter printout, which may contain boolean operators and, or,not and the predicates and relations equality, substrings,greaterOrEqual, lessOrEqual, present (for optional attributes), andsubsetOf, supersetOf and nonNullSetIntersection (for multivalueattributes only).
If a test is applied to an not existing attribute, then the test fails, and thus theoperation on the Managed Object is not executed..
The filter is applied only on those instances selected by scoping.
J.Schönwälder - L.Deri v. 1.4 Network Management / 201
Filtering Example
Filter all managed objects of the class protocolEntity whose names begins with"123 " and the attribute "severity" is different than "minor" and "badPduCout" has avalue of less or equal to "20":
test-filter CMISFilter ::=and { item equality {objectClass, Object-Class protocolEntity}, item substrings {initialString {entityID, PrintableString ''123''}}, or { not item equality {severity, Severity minor}, item lessOrEqual {badPduCount INTEGER 20} }}
Special tools normally translate filters from a user friendly syntax to the notationrequired by the protocol.
J.Schönwälder - L.Deri v. 1.4 Network Management / 202
Synchronization
As seen before:
Scoping selects the set of MOs under the specified base instance on whichthe specified operation (e.g. M-GET) will be applied.
Filtering further restricts the selection: only on the scoped MOs that satisfy thefilter the operation will be applied.
Synchronization specifies the operation behavior in case of failure.
CMIP supports two types of synchronizations:
Best effort: in case of failure on one or more MOs , the agent returns negativeresponses for those MOs where the operation failed, and positive replies forthe remaining MOs .
Atomic: in case of failure on one or more Mos, the whole operation fails andonly negative replies are defined.
J.Schönwälder - L.Deri v. 1.4 Network Management / 203
Scoping, Filtering and Synchronization
YesYesYesM-ACTION
NoNoNoM-CANCEL GET
NoNoNoM-EVENT REPORT
YesYesYesM-SET
YesYesYesM-GET
YesYesYesM-DELETE
NoNoNoM-CREATE
SynchronizationFilteringScoping
J.Schönwälder - L.Deri v. 1.4 Network Management / 204
Diagram for the M-GET service
M-GET.requestM-GET.indication
M-GET.responseM-GET.confirm
RO-Invoke
RO-Result
M-GET.request
M-GET.confirm
RO-Invoke
RO-Reject
M-GET.requestM-GET.indication
M-GET.responseM-GET.confirm
RO-Invoke
RO-Error
Aborted Operation
Operation withPositive Reply(success)
Operation Error
Manager Agent
J.Schönwälder - L.Deri v. 1.4 Network Management / 205
Several results are implemented by a "role exchange": the calling managerbecomes the recipient of calls, which are started by the agent.
M-GET Service with Multiple Responses
M-GET.requestM-GET.indication
M-GET.responseM-GET.confirm
RO-Invoke
RO-Invoke
M-GET.responseM-GET.confirm RO-Resul
t
Multiple resultsare returnedwhen theoperation isapplied tomultiple MOs
M-GET.responseM-GET.confirm RO-Invok
eM-GET.response
M-GET.confirm RO-Invoke
M-GET.responseM-GET.confirm RO-Invok
eM-GET.response
M-GET.confirm RO-Invoke
M-GET.responseM-GET.confirm RO-Invok
eM-GET.response
M-GET.confirm RO-Invoke
M-GET.responseM-GET.confirm RO-Invok
e
Manager Agent
J.Schönwälder - L.Deri v. 1.4 Network Management / 206
Issued during the processing of a call with n>1 of results: the results 1... n arereturned by means of RO Invoke. Subsequent results are sent by means of ROResult for the termination of the original service call.
M-GET Abort by M-CANCEL-GET
M-GET.requestM-GET.indication
M-GET.responseM-GET.confirm
RO-Invoke
RO-Invoke
M-GET.responseM-GET.confirm RO-Invok
eM-GET.response
M-GET.confirm RO-Invoke
M-GET.responseM-GET.confirm RO-Resul
tM-CANCEL-GET.response
M-CANCEL-GET.confirm RO-Result
Manager Agent
M-CANCEL-GET.requestM-CANCEL-GET.indication
RO-Invoke
J.Schönwälder - L.Deri v. 1.4 Network Management / 207
3.4 Management Functions
For the implementation of the 5 functional areas (FCAPS) several managementfunctions have been developed and standardised (system management function,SMF).
The management functions represent generic basic modules, with which the 5functional areas can be implemented.
ConfigurationManagement
LogManagement
SecurityManagement
Event ReportManagement
FaultManagement
ISO 10164-1
ISO 10164-2
ISO 10164-3
ISO 10164-4
ISO 10164-5
ISO 10164-6
ISO 10164-n
....
J.Schönwälder - L.Deri v. 1.4 Network Management / 208
OSI-Management Functions (ISO Standards)
Object Management Functions ISO 10164-1:1993 X.730 State Management Functions ISO 10164-2:1993 X.731 Attributes for Representing Relationships ISO 10164-3:1993 X.732 Alarm Reporting Functions ISO 10164-4:1992 X.733 Event Report Management Function ISO 10164-5:1993 X.734 Log Control Function ISO 10164-6:1993 X.735 Security Alarm Reporting Function ISO 10164-7:1992 X.736 Security Audit Trail Function ISO 10164-8:1993 X.740 Objects and Attributes for Access Control ISO 10164-9:1995 X.741 Usage Metering Function ISO 10164-10:1995 X.742 Metric Objects and Attributes ISO 10164-11:1994 X.739 Test Management Function ISO 10164-12:1994 X.745 Summarization Function ISO 10164-13:1995 X.738 Confidence and Diagnostic Test Categories ISO 10164-14:1996 Scheduling Function ISO 10164-15:1995 X.746 Management Knowledge Management Function ISO 10164-16:1997 Change over Function ISO 10164-17:1996 Software Management Function ISO 10164-18:1997
J.Schönwälder - L.Deri v. 1.4 Network Management / 209
OSI-Management Functions (Draft Standards)
Domain and Policy Management Function ISO 10164-19
Time Management Function ISO 10164-20
Command Sequencer ISO 10164-21
Response Time Monitoring Function ISO 10164-22
Most OSI Management functions are taken over after short time of the ITU andpublished with same contents as X.7 ** recommendation..
Further management functions are under development.
Relatively current outlines can be found on the WWW pages of the ISO or ITU.
ISO or International Telecommunication Union documents are (finally) freelyavailable on their respective web sites.
J.Schönwälder - L.Deri v. 1.4 Network Management / 210
Example 1: Event Forwarding and Storage
Event Report Management Function ISO 10164-5 X.734
A substantial feature is the filtering of event messages by so-called EventForwarding Discriminator (EFD) Managed Objects. Similar to SNMP Trap.
A EFD Managed Object possesses an Discriminator attribute, which contains aCMIS filter, that is used for deciding whether to forwarding the message.
Log Control Function ISO 10164-6 X.735
Log Managed Objects regulate storage event messages from other systems,received from event messages in so-called Log Records.
A Log Record can also store event log records belonging to remote systems.
The OSI event transmission and storage permits an early and distributed filteringor logging of event messages, requiring however relatively complex and efficientagents.
J.Schönwälder - L.Deri v. 1.4 Network Management / 211
Model of the Event Forwarding and Storage
LogProcessing
EventProcessing
Managed Objects
PotentialEvent-Reports
PotentialLog-Records
EFD Managed Objects
Log Managed Objects
CMIS-operations
Event-Reports
Event-Reports
J.Schönwälder - L.Deri v. 1.4 Network Management / 212
Example 2: Metric Objects
Metric Objects and Attributes ISO 10164-11 X.739 Determination of statistical sizes of (average values, variances) attributes. Production of event messages when above/below specified thresholds. Modelling of the analysis procedures in a leaving hierarchy.
A metric object can monitor exactly one attribute of a managed object. Producing new managed object, an appropriate metric object be generated
automatically.
Managed Objects
Metric Object
Event Reports
observedAttributeIdobservedObjectInstancegranularityPeriod...
J.Schönwälder - L.Deri v. 1.4 Network Management / 213
Metric Objects - Leaving Hierarchy
Further procedures can only at the design time be defined and implemented (MOmodification is needed).
It is possible to dynamically add new procedures to the meter while operational. Metric objects are not designed to produce statistics printouts for multiple
attributes.
Top
Scanner
MonitorMetric
MeanMonitor
MovingAverageMeanMonitor AlgorithmIndicatingMeanMonitor
MeanAndVarianceMonitor MeanAndPercentileMonitor MeanAndMinMaxMonitor
J.Schönwälder - L.Deri v. 1.4 Network Management / 214
CMIP vs. SNMP
CMIP SNMP
Model Event Based Polling Based
Information Approach Object Oriented Variable Oriented
Agent Complexity Complex Simple
State Information Kept by the Agent Kept by the Manager
Underlying Service CO - reliable CL - unreliable
Implementation Difficult Simple (v2 and v3 not too easy)
Retrieval Objects Scalars (tables)
Actions Supported Tricky
Objects Selection Scoping & Filtering -
Security Via Underlying Services Authentication/Encryption/ACLs
Management Functions Many Few
Price High Low
Market Acceptance Limited Large
J.Schönwälder - L.Deri v. 1.4 Network Management / 215
SNMP vs. ISO vs. TMN
SNMP (IETF)
Management should be simple
Variable-oriented approach.
Management information exchanges may be unreliable.
ISO
Management should be powerful.
Object Oriented approach.
Management information must be exchanged in a reliable fashion.
TMN
It defines only a management architecture.
The actual management protocols have been inherited by OSI.
The management should be out of band.
J.Schönwälder - L.Deri v. 1.4 Network Management / 216
4. Integrated Systems Management
1. Introduction
2. Internet Management
3. OSI Management
4. Integrated Systems Management4.1 Isolated Management Tools
4.2 Management Platforms
4.3 Topology Discovery
4.4 Monitoring and Event Correlation
4.5 Trouble Ticket Systems
4.6 Comparison Criteria
5. Distributed Internet Management
6. Actual Developments
J.Schönwälder - L.Deri v. 1.4 Network Management / 217
Isolated Management Tools
Testing Tools:
Determination of errors on the level of the physical transfer.
Frequency generators, oscilloscopes, Time Domain Reflectometer (TDR),Circuit Quality Monitor (CQM), Bit-Error-Rate-Tester (BERT).
Protocol Analysers:
Recording (sniffing) of protocol flows.
Filter capabilities for selecting " interesting " cases.
Support (protocol decoders) during the study and analysis of protocol flows.
Functions for the generation of test cases and repetition of messages.
Testing sets and protocol analysers require particularly trained personnel forsuccessful application and interpretation of the results.
J.Schönwälder - L.Deri v. 1.4 Network Management / 218
A management platform provides basic functions for the implementation ofmanagement applications.
Defined APIs permit third party to extend the functionality of the platform bydeveloping new management applications.
4.2 Management Platforms
GUI
Management Applications
System Kernel
Communication Modules Information Administration Database
API
API
J.Schönwälder - L.Deri v. 1.4 Network Management / 219
Aspects of the Integration
Protocol Integration: Integration of different management protocols by means of uniform APIs
Implementation of protocol converters (Gateways)
a) inside the management platform.
b) in special management gateways distributed in the network.
c) inside the agents.
Integration of Functions: Homogeneous functions are implemented only once and used by different applications
(write once deploy many).
All the (potential) activities needed for network management are supplied by theplatform.
GUI Integration: Integration of menus etc. of different management applications in a common desktop.
Set of guidelines and libraries for obtaining the same platform look `n feel.
J.Schönwälder - L.Deri v. 1.4 Network Management / 220
Example of Commercial Management Platforms
HP OpenView Market leader, many third providers from management applications.
Cabletron Spectrum Innovative technology (Inductive Modelling Technique).
Sun Solstice Enterprise Manager Follow-up version of the quite successful Sun Net Manager (partially Java based).
IBM/Tivoli Derived from HP OpenView, with many improvements and error corrections.
Computer Associates Unicenter TNG Huge, graphical management console (too complex, made up of several untighten
applications).
Castlerock SNMPc Small management platform for Windows systems.
...
J.Schönwälder - L.Deri v. 1.4 Network Management / 221
Databases
Integration of tools over a common data model and information exchange throughthe database.
Type of Data Stored on a DB:
Static or slowly modifying data over the network topology, device configurationinformation etc.
Configuration Data:
Parameters that control network operations.
Metric Data:
Describe the status of the network at a certain point in time (usually at fixedtime).
Long lasting data are stored persistently (report data, forecast data, etc.).
Temporary measurements data are only temporally/limited administered sincethey are usually used only for the error diagnosis and problem analysis.
J.Schönwälder - L.Deri v. 1.4 Network Management / 222
Requirements for Database Systems
Requirements:
uniform interface (e.g. SQL) independently of the underlying platform
High error tolerance and reliability (24x7 operation).
Fast response behaviour also with constant accommodation of new data
Assistance for minimising protocol operations during data entry.
Embedded procedures for the data reduction and analysis (data mining).
Application notification when the quantity of data changes (triggers).
Typical Problems:
Transactions of conventional relational databases are often a bottleneck forreal time data (network data is quasi real time).
Production of histories and versions cannot be easily implemented withrelational databases.
Limited support for constructing queries which contain temporal aspects.
J.Schönwälder - L.Deri v. 1.4 Network Management / 223
Protocol Interfaces (APIs)
XOM (X/Open) is an interface for manipulating ASN.1 data structures in C..
XMP (X/Open) is an extension around XOM that allow to manipulate SNMP andCMIP protocol primitives.
SNMP++ (HP) is a C++ class definition, where SMI datatypes and SNMP datastructures are represented as C++ classes. It enables the implementation ofSNMP based applications in C++.
WinSNMP (Microsoft) enables the implementation of management applications oragents under Win32 in C.
JMX (Sun) is a Java class library for the implementation of managementapplications.
TMN/C++ is a C++ API for ASN.1, CMIS, GDMO, TMN.
Many different APIs for scripting languages such as Perl, Tcl or Python.
No generally accepted and wide-spread API standards!
J.Schönwälder - L.Deri v. 1.4 Network Management / 224
4.3 Topology Discovery
Goals:
Automatic entry of the actual network topology.
Automatic detection of new network items in addition to the existing ones.
Automatic documentation, administration and update of topology maps.
Active Discovery:
Dispatching of special messages (ping, SNMP, etc.) in order to detect topologyinformation (load of the communications network).
Active Discovery:
Capture and analysis of data that result from normal operation of the networkresult (no load of the communications network, rarely used devices howeverare not detected).
Most systems use combinations of active and passive techniques.
J.Schönwälder - L.Deri v. 1.4 Network Management / 225
Frequently used procedures in IP networks
Dispatching ICMP ECHO/ ICMP traceroute to a whole network.
ICMP traceroute (van Jacobsen Algorithm) for the determination of networks androuting.
SNMP access to sysObjectID for the detection of SNMP capable devices.
Analysis of address relocation tables (ipNetToMedia) for the identification of MACaddresses.
Analysis of routing tables (ipForwardTable) for the detection of the routingstructure.
Analysis of neighbourhood tables in bridges.
Analysis of the information in the Domain Name System (DNS), in particularinterpretation of typical name conventions (e.g. www/ftp/mail.domain.it).
Interpretation of the MAC addresses for the determination of the manufacturers ofa device manufacturer specific equipment.
J.Schönwälder - L.Deri v. 1.4 Network Management / 226
Vendor-Specific Procedures
Below the IP layer exist for the local area networks (Ethernet, TokenRing) manyvendor specific procedure for identifying the network topology.
At present there is an effort to define a SNMP MIB (PToPo MIB) where to exportmanufacturer information in a uniform format (conversion from proprietaryformats).
Increasing transition towards decentralised topology discovery: the centralmanagement application provides only the interpretation and joining of theindividual information.
Data supplied by the individual procedures is normally inconsistent andincomplete.
The interpreter therefore requires special algorithms or heuristics.
Systems for topology detection must have effective mechanisms with which thesearch scope can be limited.
J.Schönwälder - L.Deri v. 1.4 Network Management / 227
4.4 Monitoring and Event Correlation
Sequential entry of statistical data for the documentation of the network use andplanning of network extensions.
Monitoring of characteristic values for exceeding of limit values (thresholds) or"unusual" values with the target to produce corresponding messages (events,alarms) in abnormal situations.
Examples of typical limit values (MIB-II):ipInDiscards / sec > 1 pps ifInUtilization > 70 %
ipOutDiscards / sec > 1 pps ifOutUtilization > 70 %
ipOutNoRoutes / sec > 1 pps ifInDiscards / sec > 1 pps
ifOutDiscards / sec > 1 pps
ifInErrors / sec > 1 pps
ifOutErrors / sec > 1 pps
ifInNUcastPkts / sec > 500 pps
ifOutNUcastPkts / sec > 500 pps
The selection of the relevant characteristic values determines the performancecharacteristics. (monitoring overhead vs. late problem detection)
J.Schönwälder - L.Deri v. 1.4 Network Management / 228
Event Correlation
Summary and reduction of individual events due to a common cause.
Filtering, counting, compression, generalisation and classification of events.
The temporal aspect must be considered. (early allocation of time stamps isnecessary).
Due to disturbances, event messages can arrive almost in any order.
Correlation systems must be expandable, as the network technology and thenetwork load caused by new applications can constantly change.
Correlation systems must to be scalable and able to deal with large quantities ofevent messages arriving quasi at the same time.
J.Schönwälder - L.Deri v. 1.4 Network Management / 229
The facts describe the network configuration.
The causal model describes the knowledge over causal connections in thenetwork.
The correlator receives the event messages from the monitor and with thehelp of the causal model tries to determine the causes for disturbances.
In case of success such systems supply good assertions, since they canpush away on causal connections.
Causal Model
Facts(Topology,...)
NetworkMonitor
CausalModel
Correlator
Events
Causes
J.Schönwälder - L.Deri v. 1.4 Network Management / 230
Rule-based Systems
Declarative in the form of facts (e.g. topology) and rules use to represent theknowledge:if <precondition> then <action>
The inference engine controls the application of the rules: Forward concatenation: on the basis of the well-known facts rules, whose
precondition is fulfilled, are selected and the internal messages executed, untilno more rules can be applied.
Backwards deduction: only the rules outgoing from the target are applied. Ifparameters of the precondition are unknown, one tries to deduce this by theapplication of further rules.
Facts(Topology,...)
NetworkMonitor
Rules
InferenceEngine
Events
Causes
J.Schönwälder - L.Deri v. 1.4 Network Management / 231
Case-based systems are based on a collection of well-known cases, which isconstantly updated and extended.
Wrong problem diagnosis needs to be administered. Repetitions of well-knownmisinterpretations need to avoided.
It is presupposed ‘a priori’ knowledge over the problem area.
Basically it is not possible to detect new, unknown problems.
The search for "similar" cases can become very complex, as systems are typicallynot capable of abstraction.
Case-based Systems
NetworkMonitor
Correlator
Events
PossibleCauses
CaseDatabase Solved
Cases
J.Schönwälder - L.Deri v. 1.4 Network Management / 232
Existing Event Correlation Systems
ECS (Hewlett-Packard): Part of the HP OpenView often commodity for management of SDH/ATM
networks. Events are shifted through the dataflow by means of correlation networks,
where each node can process the state of individual event messages. Several ECS systems can be hooked up for scalability purposes.
DECS (System Management Arts, Smarts): Problems are represented by a quantity of observable symptoms. Incoming event messages are stored in vectors, and are used for coding of
symptoms used for problem detection. High speed system due to the early detection of possible code words and
tolerance in relation to incomplete information due to the Hamming distance ofthe individual code words.
Additional Systems: IMPACT (GTE Laboratories) Expert (AT&T Laboratories) NetFACT (IBM T.J. Watson Research)
J.Schönwälder - L.Deri v. 1.4 Network Management / 233
4.5 Trouble-Ticket Systems
Trouble ticket systems (TTS) or Help Desk systems enable the systematic entry,handling and analysis of cases of an error:
Error cases become either manual (e.g. calling of a customer) or automatically(e.g. after termination of an event correlation) an input to a TTS.
The TTS transfers the ticket to the concerned groups of people and monitorsthe handling of the problem up to the final solution.
Closed Trouble tickets are stored in a database.(statistical analysis, search for similar cases in the past)
It allows to track/solve problems with the need of fewer specialised persons.
Trouble-Ticket System Requirements:
A TTS must be able to receive error messages from very different sources.
A TTS must support involved people in appropriate way, and be well integratedinto existing operational sequences.
The operation of the TTS must take place easily and via a clear user interface.
The introduction of a TTS and motivation of the users is often a largeorganisational problem!
J.Schönwälder - L.Deri v. 1.4 Network Management / 234
4.6 System Management Platforms: Comparison Criteria
Functional criteria: Support of Management Protocols. Support of standard and vendor-specific MIBs. Implementation of Management Functions. Security of the management software (Access Control, Authentication).
Operational criteria: User friendliness. Efficiency and Scalability. Reliability and Stability.
Product extension and availability of new components by third-party providers. Integration with existing software systems (e.g. databases). Installation and learning speed, availability of technical personnel. Quality of the documentation and support of the manufacturer/provider. Long-term support and updates/new releases by the manufacturer. Quality and license (open source) of the programming interfaces and
languages. Initial, Operational and training costs.
J.Schönwälder - L.Deri v. 1.4 Network Management / 235
5. Distributed Internet Management
1. Introduction
2. Internet Management
3. OSI Management
4. Integrated Systems Management
5. Distributed Internet Management
5.1 MIB Based5.2 Remote Operations Based5.3 Management by Delegation
5.4 Script Based
5.5 OSF DME
6. Actual Developments
J.Schönwälder - L.Deri v. 1.4 Network Management / 236
Different Approaches for Distributed Management
MIB Based: Expression MIB Event MIB Notification MIB
Remote Operations Based Remote Operations MIB Remote Monitoring MIB (RMON) Traffic Flow Measurement
Management by Delegation
Script Based Script MIB Schedule MIB
J.Schönwälder - L.Deri v. 1.4 Network Management / 237
5.1 Distributed Management: MIB Based [1/2]
Manager
Manager Manager
Agent Agent Agent Agent Agent
Inform
Poll
Command
• Standard MIB approach (similar to SNMPv2 Manager2Manager MIB)
• Limited functionality
• Runtime behaviour must be defined at implementation time.
Top level manager
Intermediate manager
Event MIB
Expression MIB
J.Schönwälder - L.Deri v. 1.4 Network Management / 238
Distributed Management: MIB Based [2/2]
Expression MIB:
Input are (wild carded) variables of a (local) MIB.
Operates on both absolute and delta values.
Rich set of expressions.
The output is stored in the value table.
The value table may server as input for other operations.
Event MIB:
Input are variables of a remote MIB.
Triggers on changes or threshold crossing.
Notification MIB:
It generates a notification (SNMP Trap) or a SET operation.
J.Schönwälder - L.Deri v. 1.4 Network Management / 239
5.2 Distributed Management: Remote Operations Based
Ping MIB: to perform a ping operation from a remote host.
Traceroute MIB: to perform a traceroute from a remote host.
Name Lookup MIB: to perform a name lookup from a remote host.
RMON: to monitor remote networks and services.
NeTraMet: to monitor network traffic flows using a traffic meter.
Rem. Ops.
MIB
J.Schönwälder - L.Deri v. 1.4 Network Management / 240
Remote Network Monitoring (RMON)
Offline Operation:
A RMON probe should collect, analyse, and produce statistics of traffic dataindependently of the manager also (especially) in case of connections failure.
Pre-emptive Monitoring:
The probe should, if appropriate resources are available, sequentially enterdata in the management system, be able to analyse such data, andasynchronously inform managers about detected events.
Problem Detection and Forwarding:
The sequential analysis of data, produced either by active or passivemonitoring, permits the production of events, which are sent to managers orstored in the probe.
Multiple Managers:
The probe should not be able to be used concurrently by several managers(multiple readers a single writer).
Not all RMON implementations fulfil all these goals.
J.Schönwälder - L.Deri v. 1.4 Network Management / 241
RMON-1 MIB (RFC 1757, RFC 1513)
The Statistics group contains extent of utilisation and error statistics for theEthernet and Token Ring network segments. It shows packets, collisions, octets,broadcasts, multicasts, errors, and keeps track of packet size distribution (< 64, 64- 1518, > 1518 octets).
The History group enables it to copy periodically the values from the Statisticsgroup into a circular buffer.
The monitoring of MIB instances threshold values, based on the ASN.1 datatypeINTEGER, is implemented by the Alarm group. An alarm (SNMP Trap) isproduced when a threshold is exceeded.
The entry and association of observed traffic to MAC addresses take place in theHosts group.
An analysis (sort) of the data entered in the Hosts group is possible in theHostTopN group.
The Matrix group contains data over communication relations which are defined bypairs by MAC addresses. Useful for “what if” analysis, and for detecting intruders.
J.Schönwälder - L.Deri v. 1.4 Network Management / 242
RMON-1 MIB Structure (RFC 1757, RFC 1513)
The Filter group is used to select individual packets. A filter expression (bitpattern) assigns packages to a channel. The channel determines whether thepacket is only counted or whether an event is produced on packet receipt.
The Capture group provides a scratchpad memory where are stored all thepackets received by a channel.
The Event group regulates the handling of internal events: it defines the variousevents that cause the emission of SNMPv1 traps sent to managementapplications or be stored in a log.
A probe cannot receive notifications produced by other systems.
The threshold monitoring is intended only for local probe instances.
J.Schönwälder - L.Deri v. 1.4 Network Management / 243
Several Managers using RMON
Problems caused by several managers: Simultaneous allocation of monitor resources can easily exceed the available
capacity. A manager can monitor resources for a long time: in this time frame other
managers might not be able to access the probe. Resources can be assigned to a manager, so that is abnormal situation
happen in the manager (e.g. crash) these resources are no longer released(hence made available to other managers).
Introduction of MIB objects, which identify the owner of resources: A management application cannot detect the occupied resources. When a management application is restarted, it should release resources no
longer necessary. A network administrator can have the capability to release resources occupied
by other network administrators. No access supervision or ownership is implemented. Property boundaries are
based on cooperation and are not enforced.
J.Schönwälder - L.Deri v. 1.4 Network Management / 244
Alarm (SNMP Trap)
In case of exceeding a upper limit value, an event is produced each time thethreshold is exceeded or when a value that used to be above a threshold returnsinside the specified range. Similar considerations can be applied to lower thresholdvalue.
Thresholds can either be on to the measured value (absolute absolute) or on thedifference of the current value to the last measured value (delta value).
RMON Threshold Monitoring: Alarm Group
Time
Value
Rising Treshold
Falling Treshold
J.Schönwälder - L.Deri v. 1.4 Network Management / 245
RMON Sampling Interval
MIB instance value sampling must be done twice per sampling interval, otherwiseexceeded thresholds may be undetected for overlapping intervals.
Example 1: (10 seconds sampling interval, threshold value 20, 10 seconds test interval)
Time: 0 10 20
Value: 0 19 32
Delta: 19 13
Actual Threshold To Check: 19 13
Example 2: (5 seconds sampling interval, threshold value 20, 10 seconds test interval)
Time: 0 5 10 15 20
Value: 10 19 30 32
Delta: 10 9 11 2
Actual Threshold To Check : 19 20 13
In the second example for T=15 a threshold exceed is determined, since the deltain 10 second interval is 9+11=20.
J.Schönwälder - L.Deri v. 1.4 Network Management / 246
RMON-1 Filters
Received packages can be selected by means of filters: A data filter checks whether a certain bitmask is contained inside the packet. A status filter checks whether the packet status information matches the
specified bitmask.
Filter Specification: Auxiliary calculation (# means XOR):
relevant_bits_different := (input # filterPktData) & filterPktDataMask Successful match:
(relevant_bits_different & (! filterPktDataNotMask)) == 0 Successful mismatch:
((relevant_bits_different & filterPktDataNotMask) != 0) || (filterPktDataNotMask == 0)
Example: (all ethernet packets sent to 00:00:00:00:00:A5 and not originated by00:00:00:00:00:BB)filterPktDataOffset 0filterPktData 00 00 00 00 00 A5 00 00 00 00 00 BBfilterPktDataMask FF FF FF FF FF FF FF FF FF FF FF FFfilterPktDataNotMask 00 00 00 00 00 00 FF FF FF FF FF FF
J.Schönwälder - L.Deri v. 1.4 Network Management / 247
RMON-1 Filter Specification
bitwise XOR
bitwiseAND
bitwiseAND
bitwiseAND
bitwiseNOT
Captured Packet
filterPktDataOffset
filterPktDataMask
filterPktData
filterPktDataNotMask
Test passed if all bits are 0(pass if match)
Test passed there is a bit set to 1 or whenfilterPktDataNotMask is set to 0
(pass if mismatch)
J.Schönwälder - L.Deri v. 1.4 Network Management / 248
A RMON channel is defined by a set of filter pairs (data and status filters)
A packet is accepted by a channel when,
if at least one pair of filters holds (acceptMatched channel)
or if at least one filter of all filters pairs does not pass the test (acceptFailedchannel).
Example (acceptMatched):
RMON-1 Channels
Data Filter (i,1)
Status Filter (i,1)
Data Filter (i,n)
Status Filter (i,n)
and
and
or
Packet
Status
J.Schönwälder - L.Deri v. 1.4 Network Management / 249
RMON-1 Channelsprocedure packet_data_match (result){
if ((result == 1 && channelAcceptType == acceptMatched) || (result == 1 && channelAcceptType == acceptFailed ) ) {
channelMatches++;if (channelDataControl == on) { if ((channelEventStatus != eventFired) && (channelEventIndex != 0))
generate_event(); if (channelEventStatus == eventReady)
channelEventStatus = eventFired;}
}}
All packets which pass the filter tests are counted into channelMatches. Further processing through channelDataControl can be turned on/off. Production of events through channelEventStatus:
if the value is eventAlwaysReady then an event is generated. if the value is eventReady, an event is generated and channelEventStatus is set to
eventFired. In the state eventFired, events will not produce an event each time they are generated,
until the value of channelEventStatus is changed by a management operation.
J.Schönwälder - L.Deri v. 1.4 Network Management / 250
RMONv1 vs. RMON v2
RMONv1 has been designed for low level protocols below IP.
RMONv2 has been designed to monitor high layer protocols.
RMONv2 extends RMONv1 by adding the following groups:
Protocol directory group
Protocol distribution group
Address mapping group
Network layer group group
Network layer matrix group
Application layer host group
Application layer matrix group
User history group
Probe configuration group
J.Schönwälder - L.Deri v. 1.4 Network Management / 251
RMON-2 MIB (RFC 2021, RFC 2074) [1/2]
The Protocol Directory group describes the protocols detected by the probeincluding the protocol parameter (e.g. UDP port numbers). All protocols above thenetwork layer are supported (e.g. http, ftp).
The Protocol Distribution group produces basic statistics for selected protocols(number of byte, number of packages).
The Address Mapping group provides a mapping of MAC addresses (flownthrough the probe) in network addresses.
The Network Layer Host group provides statistics for the network layer classifiedaccording to network addresses.
The Network Layer Matrix group supplies statistics for communication relations(host communications matrix) at network level.
J.Schönwälder - L.Deri v. 1.4 Network Management / 252
RMON-2 MIB (RFC 2021, RFC 2074) [2/2]
The Application Layer Host group provides statistics for an application layerprotocol according to network addresses.
The Application Layer Matrix group is similar to Network Layer Matrix group withthe exception that in this case statistics are calculated on an application layerprotocol layer.
The User History group permits an automatic generation of statistics stored intoso-called Buckets. The number of available buckets is configurable.
The Probe Configuration group enables the configuration of the probe and coversamong other things: Configuration of serial access (Modems). IP network configuration. Configuration of serial connections (SLIP) for Trap delivery. Configuration of parameters for Traps delivery.
J.Schönwälder - L.Deri v. 1.4 Network Management / 253
RMON-2 TimeFilter
Goal: To select in a potentially very large table only those values that recently changedwithout having to read the entire table.
Every table row has as first index a TimeFilter attribute, whose value determines theaffiliation of a row to a MIB View.
When the manager specifies the TimeFilter value set to t on GET, it retrieves only thosevalue that changed after the time t (the time is relative to sysUpTime value of the probe).
The agent implementation requires only a time stamp per table row, that specifies when thevalue of the row changed.
A manager that is not aware of the TimeFilter mechanism that wants to walk a table, canstick in a endless GET-NEXT loop.
J.Schönwälder - L.Deri v. 1.4 Network Management / 254
RMON-2 TimeFilter Example [1/2]
Consider the following table:FooEntry ::= SEQUENCE {
TimeFilter fooTimeMark, -- TimeFilterInteger32 fooIndex, -- KeyCounter32 fooCount
}
At the following timestamps, the counters below changed:
sysUpTime.0 fooCount.x.1 fooCount.x.2 0 0 0 500 1 0 900 2 01100 2 11400 2 22300 3 2
The agent stores the timestamp of the last counter change. On manager’s access,the agent checks whether the TimeFilter value specified by the manager is smallerthan the latter.
J.Schönwälder - L.Deri v. 1.4 Network Management / 255
RMON-2 TimeFilter Example [2/2]
A manager reads the value changes once every 15 seconds. The manager issuedthe first request 6 seconds after the time the agent started:
GetBulk(non-repeaters=1, max-repetitions=2, sysUpTime, fooCount.0)Response(noError@0, sysUpTime.0=600, fooCount.0.1=1, fooCount.0.2=0)
GetBulk(non-repeaters=1, max-repetitions=2, sysUpTime, fooCount.600)Response(noError@0, sysUpTime.0=2100, fooCount.600.1=2, fooCount.600.2=2)
GetBulk(non-repeaters=1, max-repetitions=2, sysUpTime, fooCount.2100)Response(noError@0, sysUpTime.0=3600, fooCount.2100.1=3,fooCount.2101.1=3))
GetBulk(non-repeaters=1, max-repetitions=2, sysUpTime, fooCount.3600)Response(noError@0, sysUpTime.0=5100, /* instances outside of the fooTable or endOfMibView exceptions */)
J.Schönwälder - L.Deri v. 1.4 Network Management / 256
Traffic Flow Measurement (RFC 2063, RFC 2064)
Record of data useful to document the network bandwidth over the time and usedas basis for network accounting.
Elements of the underlying model: A meter is a process which executes measurement on a network segment and which
aggregates measured data. A Collector fetches data out of the meter and stores them (e.g. on a database). Manager applications control the data acquisition in the meter and support the
processing and analysis of measuring data.
The data granularity selected is very important: A very fine granularity requires very efficient meters, in particular in networks with very
high data rates (network load between applications). A coarse granularity (total of transient data flow by a network) usually reduces
accounting richness.
The association of data streams to traffic flows is determined by the value ofattributes Ai and the corresponding values Vi. This association is programmed bymeans of rules.
J.Schönwälder - L.Deri v. 1.4 Network Management / 257
Mode of Operation
A rule is a tuple Ri = (Ai, Mi, Vi, Ci, Pi):
Rules (R1..Rn) are represented as an SNMP table. When a packet arrives, theprocessing starts with rule R1.
For each rule Ri the attribute Ai with the mask Mi is computed and the result iscompared with value Vi.
In case of inequality the processing continues with the rule Ri+1.
In case of equality the action Ci with parameter Pi is performed.
Actions permit the branch (goto) to other actions or rules, termination of ruleevaluation (ignore), mark of the tested attributes (pushto), or counting thepacket (CountPkt) in the current flow defined by the characterised attributes.
J.Schönwälder - L.Deri v. 1.4 Network Management / 258
Example of a Rule Table
Example Table:i Ai Mi Vi Ci Pi
1 SourcePeerType 255 IP Pushto 32 Null 0 0 Ignore 03 SourcePeerAddress255.255.0.0 131.114.0.0 Goto 64 DestPeerAddress 255.255.0.0 131.114.0.0 Goto 85 Null 0 0 Ignore 06 DestPeerAddress 255.255.0.0 131.114.0.0 Ignore 07 Null 0 0 Retry 08 SourceTransType 255 0 CountPkt 0
The first two rules filter IP traffic with the help of the attribute SourcePeerType. Rules 3-7 filter all packets whose source or destination addresses belong to Unipi. The action retry in rule 7 is done in case source and destination address are
exchanged and processing starts again with the first rule. Rule 8 count all packets sent to/received from Unipi. Note that different transport
protocols are counted separately (SourceTransType).
J.Schönwälder - L.Deri v. 1.4 Network Management / 259
5.3 Distributed Management: Management by Delegation
Idea: Instead of bringing the data by management protocols to the applications, theapplications are brought to the data.
Instead of calling a pre-defined function on another system (Remote ProcedureCall), the program code of the function is transferred with the call (remoteevaluation).
Advantages of the model:
Reduction of network management traffic.
Increased insensitivity to network disturbances (e.g. mgmt operations packetloss).
Scalability by means of decentralised processing of management information.
Cost savings by a "off-line management”.
Problems in the selection of a suitable programming language, in the security ofthe used runtime system or in the communication protocol.
J.Schönwälder - L.Deri v. 1.4 Network Management / 260
Construction of Symmetric MbD Agents
delegationserver
delegationclient
runtime environmentthreads
agentrole
manager roleMIB
delegationprotocol
delegationprotocol
managementprotocol
managementprotocol
procedures
J.Schönwälder - L.Deri v. 1.4 Network Management / 261
5.4 Distributed Management: Script Based
Functionality can be specified at runtime.
Powerful autonomous actions (no hierarchical dependencies/responsibilities).
The top level manager has less complexity hence it has less duties with respect toother manager/agents.
This approach requires some protection mechanisms in order to avoidunauthorised parties to interfere with the management.
Different scripting languages can be used.
J.Schönwälder - L.Deri v. 1.4 Network Management / 262
Mode of operation of the IETF Script MIB (RFC 2592)
NMSScript
Repository
Script MIBAgent
Language TableJavaTcl
JDK 1.1.58.0.4
. . . . . .
Extension TableTnm. . .
3.0.0. . .
. . . . . .
Script Table Launch Table Run Table
SNMP
HTTP, FTP, ..
.
HTTP, NFS, ...
push script pull script
juniorsenior
. . .
S
SS
S
S
S
. . .
infoinfo. . .
juniorsenior
. . .
S
S
. . .
argsargs. . .
juniorsenior
. . .
S
S
. . .
statestate. . .
J.Schönwälder - L.Deri v. 1.4 Network Management / 263
Simplified Structure of the IETF Script-MIB
RunningScriptLaunchScript
Script CodeFragment
Language Extension
iswritten
in
isbased
on
consistsof
supports
hasstarted
1 n
1 n
1 n
1
n
1
n
Index LangIDDescr
Version
Index ExtIDDescr
Version
Index
Revision
RowStatus
Source
Version
OperStatus
AdminStatus
RowStatus
Owner
Name
OperStatus
AdminStatus
RowStatus
Index
Start
End
Argument
Result
ExitCode
LifeTime ExpireTime
OperStatus
AdminStatus
RowStatus
Result LifeTime ExpireTime
Owner Start
Control
VendorRevision
Vendor
Text
J.Schönwälder - L.Deri v. 1.4 Network Management / 264
Script MIB Security Aspects
The MIB definition contains attributes such as the max runtime of scripts or themax number of parallel calls of a script.
The indexing of the MIB tables is made by an Owner attribute and suitable"auxiliary nodes" in the registration tree that, combined with the SNMP accesscontrol, provides good security.
The Owner attribute can be implemented as using the available operating systemor the runtime (e.g. Java) security profiles.
The operating system security profiles describes the quantity of operating systemresources that one current script can use.
Security services of the runtime environment (e.g. Java sandboxes, Tcl paddedcells) can limit runtime system services access.
J.Schönwälder - L.Deri v. 1.4 Network Management / 265
5.5 OSF Distributed Management Environment
What is OSF (Open Software Foundation)?No profit, vendor-neutral (in theory), consortium founded in 1988.
OSF TechnologiesOSF/Motif: User Environment ComponentOSF/1: Operating System ComponentOSF DCE: Distributed Computing EnvironmentOSF DME: Distributed Management Environment
DME ConsortiumRequest for Technology (RFT) issued 7/90 to the OSF community and not.25 Organisations submitted technologies: selection ended 9/91.Shipment started 12/93.Code released under a costly license to both ISV (Integrated System Vendors) andend-users.
J.Schönwälder - L.Deri v. 1.4 Network Management / 266
OSF DME Components
Distributed Services:
Five selected services have been defined as well as a model for additionalservices:Event Services (EVS)Software Distribution Services (SDS)License Management Services (LMS)Subsystem Management Services (SMS)PC Services for accessing some services from DOS/Windows PCs (PCS)
NMO: Manager/Agent Network Management Option
Support for SNMP and CMIP protocols via the Open Protocol API (OPI)Provisioning of XOM/XMP APIs
Peer-to-Peer Management Framework
Distributed, Object Oriented Management ServicesOMG CORBA APIs support
J.Schönwälder - L.Deri v. 1.4 Network Management / 267
OSF DME Architecture
DFS SMS EVS LMS SDS
Operating System and Network Stack
DCE Executive SNMP CMIP
XMPCorba ORB
DME Applications
Management UserInterface (MUI)
Obj Adapter
J.Schönwälder - L.Deri v. 1.4 Network Management / 268
OSF DME Goals
Consistency
Consistent GUI
Consistent syntax/semantics for APIs
Distributed Object Oriented Computing Model
Support for legacy applications
Interoperability
Scalability
Inside a single system
Inside a defined group of systems
Enterprise-wide
J.Schönwälder - L.Deri v. 1.4 Network Management / 269
1. Introduction
2. Internet Management
3. OSI Management
4. Integrated Systems Management
5. Distributed Internet Management
6. Current Developments6.1 Network Management with CORBA
6.2 Web-based Enterprise Management Initiative (WBEM)
6.3 Common Information Model (CIM)
6.4 Java-based Network Management
6.5 Application and Service Management
6.6 XML-RPC
6.7 Policy-based Management
6.8 Latest Developments
6. Current Developments
J.Schönwälder - L.Deri v. 1.4 Network Management / 270
Goal: a quantity of interacting objects, which can to be implemented in (almost) anyprogramming languages and used without knowledge of their location.
Corba has been defined by the OMG (Object Management Group) consortium.
Relevant Corba components:
Object Request Broker (ORB): the ORB locates the implementation of the target objectand directs client communication to the target (no via-ORB communications).
Client: beside the object reference it has no information about the target object.
Object Implementation: implements the target object (code and data).
Object Reference: uniquely identifies an object in a ORB.
6.1 Common Object Request Broker Architecture(CORBA)
Client Object Implementation
Object Request Broker (ORB)
J.Schönwälder - L.Deri v. 1.4 Network Management / 271
Dynamic Invocation Interface (DII):
Similar to Java RMI, it allows runtime dynamic method/procedure calls.
Client Stubs:
It implements the procedure/method calls.
Object Adapter:
Adapts a non-native Corba object to Corba (object model adaptation).
Calls methods.
Activates and deactivates an object implementation.
Structure of CORBA 2.0 ORB
Object Request Broker (ORB)
Client Object Implementation
DynamicInvocation
IDLStubs
ORBInterface
StaticIDL
Skeletons
DynamicIDL
SkeletonsObject
Adapter
J.Schönwälder - L.Deri v. 1.4 Network Management / 272
CORBA Advantages
Vendor independent Client/Server Computing in heterogeneous environments.
Transparent method calls of any local and remote CORBA object.
Static method calls with strong type checking at translation time.
Ability to dynamically issue method calls of unknown CORBA objects at runtime.
Objects are defined independently of the programming language using (IDL).
There exist IDL compilers for C, C++, SmallTalk, Java, Ada,...
Applications can call object methods regardless of the programming languageused for their implementation.
An interface repository contains Meta-information about well-known objects.
Corba interoperability guaranteed (in theory) thanks to the Inter-ORB-Protocol(IIOP).
The ORB guarantees location transparency and operating system independence.
Many basic CORBA services are implemented as CORBA objects (NamingService, Trader, Location Service, Event Service, ...).
J.Schönwälder - L.Deri v. 1.4 Network Management / 273
Interface Definition Language
Basic Datatypes:short, long, long long, unsigned short, unsigned long, unsignedlong long, float, double, octet, char, boolean, enum, any
Additional Datatypes:structure, sequence, union, string, array
Interface Definitions: Declaration of object relations (inheritance).
Declaration of datatypes.
Declaration of constants.
Declaration of attributes.
Declaration of operations.
Declaration of object exceptions.
Module Definitions: Declaration of Datatypes, constanten and exceptions.
Declaration of interfaces.
Declaration of additional modules.
J.Schönwälder - L.Deri v. 1.4 Network Management / 274
CORBA Services and Common Facilities
CORBA Services define functions which are often used:
Naming Service
Event Service
Life Cycle Service
Persistence Service
Object Relationship Service
Object Externalization Service
Object Transaction Service
Additional functional modules, in particular for special areas of application, aredeveloped within OMG and standardised as Common Facilities.
Some the CORBA services are very important event outside the CORBA world forthe functionality they provide. In particular the Event service is important formanagement.
J.Schönwälder - L.Deri v. 1.4 Network Management / 275
Internet Inter-ORB Protocol (IIOP)
Common Data Representation (CDR) Defines the bytecode representation of CORBA basic types (similar to ASN.1 BER). The sender selects the byte ordering (little endian vs. big endian). Performs the alignment of data to „natural“ (e.g. 32, 64 bits) boundaries (data alignment).
General Inter-ORB Protocol (GIOP) Definition of the message types and their formats:
Request ReplyCancelRequest CloseConnectionLocateRequest LocateReplyMessageError Fragment
Definition of the message representation in CDR. Independent of the underlying transport protocol. Large messages can be fragmented.
Internet Inter-ORB Protocol (IIOP) It defines the transfer of GIOP over TCP/IP.
J.Schönwälder - L.Deri v. 1.4 Network Management / 276
A LocateRequest verifies the existence of an object and it is sent to the ORBwhere the CORBA Object is known to exist.
A MessageError is used to report errors.
A CancelRequest is sent by a client to abort the transfer of reply fragments.
From the communication point of view, CORBA is rather similar to CMIP.
Example of GIOP Message Calls
Client Server
LocateRequest
LocateReply
Request
Reply
CloseConnection
Client Server
LocateRequest
LocateReply
Request
Reply
CloseConnection
FragmentFragment
J.Schönwälder - L.Deri v. 1.4 Network Management / 277
Joint Inter-Domain Management (XoJIDM)
Sponsored by X/Open and the Network Management Forum (NMF).
Introduction of an object-oriented development environment for the network management.
Simple, specifications which can be easily read.
Creation of reusable class libraries based on GDMO object classes:
Reuse of the MOs already standardised for the telecommunications world.
Use of CORBA for language independence .
Definition of a class library for SNMP SMI definitions:
Integration of extensive and widespread Internet SMI MIB definitions
Use of CORBA for language independence.
Reduce development complexity for the implementation of management applications basedon GDMO or SMI MOs for the implementation of management applications.
Portability and interoperability of management applications beyond platform boundaries.
J.Schönwälder - L.Deri v. 1.4 Network Management / 278
Interoperability between Management Architectures
CORBA Manager
CORBA Agent
OSI Manager
OSI Agent
Internet Manager
Internet Agent
Gateway
GatewayCMIP/GDMO SNMP/SMI
IIOP/IDL
IIOP/IDL
SNMP/SMICMIP/GDMO
By means of gateways it is possible to obtain interoperability between existingmanagement systems and agents.
J.Schönwälder - L.Deri v. 1.4 Network Management / 279
IDL Datatypes for SMIv2-Datatypes
Mapping of relevant ASN.1 Datatypes on IDL Datatypes: NULL typedef char ASN1_Null;
INTEGER typedef long ASN1_Integer;
typedef long long ASN1_Integer64;
typedef unsigned long ASN1_Unsigned;
typedef unsigned long long ASN1_Unsigned64;
OCTET STRING typedef sequence<octet> ASN1_OctetString;
OBJECT IDENTIFIER typedef string ASN1_ObjectIdentifier;
Mapping of SMI-Datatypes on IDL-Datatypes: Integer32 typedef ASN1_Integer SNMPv2_SMI::Integer32Type;
Unsigned32 typedef ASN1_Unsigned SNMPv2_SMI::Unsigned32Type;
Gauge32 typedef ASN1_Unsigned SNMPv2_SMI::Gauge32Type;
Counter32 typedef ASN1_Unsigned SNMPv2_SMI::Counter32Type;
TimeTicks typedef ASN1_Unsigned SNMPv2_SMI::TimeTicksType;
IpAddress typedef sequence<octet,4> SNMPv2_SMI::IpAddressType;
Opaque typedef ASN1_OctetString SNMPv2_SMI::OpaqueType;
Counter64 typedef ASN1_Unsigned64 SNMPv2_SMI::Counter64Type;
BITS typedef ASN1_OctetString SNMPv2_SMI::BitsType;
J.Schönwälder - L.Deri v. 1.4 Network Management / 280
Example of SMIv2 -> IDL Translation [1/2]module IF-MIB {
typedef SNMPv2_SMII::Integer32Type Integer32Type; typedef SNMPv2_TC::DisplayStringType DisplayStringType;
interface interfaces : SNMPMgmt::SmiEntry { /* DESCRIPTION: The number of network interfaces (regardless of their current state) present on this system. */ readonly attribute Integer32Type ifNumber; };
interface ifEntry : SNMPMgmt::SmiEntry { /* INDEX : (ifIndex) */ const string EntryIndexVarLis = „ifIndex“; /* DESCRIPTION: ... */ readonly attribute InterfacadexType ifIndex; /* DESCRIPTION: ... */ readonly attribute DisplayStringType ifDescr; /* ... */ }}
ifNumber
interfaces
ifTable
ifEntry
ifIndex ifDescr
J.Schönwälder - L.Deri v. 1.4 Network Management / 281
Example of SMIv2 -> IDL Translation [2/2]struct IfIndexType { struct IfAdminStatusType { ASN1_ObjectIdentifier var_name; ASN1_ObjectIdentifier var_name; ASN1_ObjectIdentifier var_index; ASN1_ObjectIdentifier var_index; InterfaceIndexType var_value; IF-MIB::ifEntry::IfAdminStatusType var_value;} }
struct LinkDownType { struct IfOperStatusType { IfIndexType ifIndex; ASN1_ObjectIdentifier var_name; IfAdminStatusType ifAdminStatus; ASN1_ObjectIdentifier var_index; IfOperStatusType ifOperStatus; IF-MIB::ifEntry::IfOperStatusType var_value;} }
interface Notifications : SNMPv2::Notifications { void linkDown(in string agent_ip_address, in string community_name, in SNMPv2TC::TimeStampType event_time, in LinkDownType notification_info);}
interface PullNotifications : SNMPv2::PullNotifications { void pull_linkDown(out CosNaming::Name src_entry_name, out SNMPv2TC::TimeStampType event_time, out LinkDownType notification_info); boolean try_linkDown(out CosNaming::Name src_entry_name,
out SNMPv2TC::TimeStampType event_time, out LinkDownType notification_info);}
J.Schönwälder - L.Deri v. 1.4 Network Management / 282
JIDM: Current State of the Art and Criticism
Compiled Specifications:
Definition the ASN.1 to OMG IDL translation.
Definition the GDMO to OMG IDL translation.
Definition the OMG IDL to GDMO translation.
Definition the SNMP SMIv2 to OMG IDL translation.
Criticism:
The JIDM specifications produce very "fine-grained" CORBA objects which canlead an object reference to appropriate scaling problems.
For each CORBA object it must exist and object reference known to theapplication (too many references).
Naming services are necessarily for the distribution of object references.
Short-lived objects produce strong overhead on the Naming Service.
Alternatives and suggestions are currently discussed: many propose to reusethe scoping and filtering possibilities introduced by CMIP for the definition of aso-called Management Request Broker.
J.Schönwälder - L.Deri v. 1.4 Network Management / 283
6.2 Web-based Enterprise Management Initiative(WBEM)
Sponsored by Intel, WBEM (http://www.wbem.net/) goal is to consolidate andunify the data provided by existing management technologies - in order tosolve enterprise problems.
The DMI was designed to be:
independent of a specific computer or operating system
independent of a specific management protocol
easy for vendors to adopt
usable locally, i.e. no network required
usable remotely using DCE/ RPC, ONC/ RPC, or TI/ RPC
mappable to existing management protocols (e. g., CMIP, SNMP).
“The DMI procedural interfaces are specifically designed to be remotelyaccessible through the use of Remote Procedure Calls. The RPCs supportedby the DMI include: DCE/RPC, ONC/RPC, and TI/RPC.” -- DMI 2.0Introduction
J.Schönwälder - L.Deri v. 1.4 Network Management / 284
6.3 Historical Development of CIM(Common Information Model)
The Desktop Management Task Force (DMTF) made of PC manufacturers started itsactivities on 1992.
The Web-based Enterprise Management (WBEM) started its activities on 1996.
WBEM has failed in 1996 to bring its ideas to the IETF. In 1997 WBEM specifications wheretransferred to DMTF.
1980 1985 1988 1990 1993 1996 1998
ITU (TMN)
ISO (CMIP)
HEMS
SGMP
SNMPv1 SNMPv2p SNMPv2c SNMPv3
IETF (SNMP)
DMTF
DMI 1.0 DMI 2.0
CIM 1.0
WBEM
J.Schönwälder - L.Deri v. 1.4 Network Management / 285
CIM Specifications
CIM has been designed to enable implementations in multiple, object- based executionmodels such as CORBA (Common Object Request Broker Architecture), COM (CommonObjects Model) and others.
CIM contains specifications for: CIM Schema. XML Encoding for CIM. CIM Operations over HTTP using the HyperMedia Management Protocol (HMMP).
The use of protocols such as HTTP and mark-up languages such as XML (eXtensibleMarkup Language) have been motivated not only by their wide deployment and acceptancein the industry but also because they are and heritage from the previous WEBM activities.
In addition the CIM modelling is based on the Unified Modelling Language (UML) a designmethod for specifying, visualising, and documenting object-oriented systems underdevelopment. It defines a number of diagrams, such as class diagram, message tracediagram, and state diagram.
J.Schönwälder - L.Deri v. 1.4 Network Management / 286
CIM Metamodel
The CIM metamodel defines the constructs used to describe CIM schemas:
Classes describe a model of an object with a certain quantity of attributes andmethods. Objects can be transmitted on a network.
Attributes have a datatype (integer values with/without signs, characters andcharacter strings, date, time and time intervals).
Methods have a formal signature (name, parameter, return value) and can beoverloaded.
A schema groups together a set of homogeneous classes.
A qualifier precisely describes the characteristics of an element. Qualifiers aredivided in Meta Qualifier, Standard Qualifier, Optional Qualifier and User-defined Qualifier.
A reference is a special attribute that uniquely identifies a class or an instance.
An association is a special class that contains at least two references.
A trigger detects a status or access change.
An Indication is a class, whose instances are produced by a trigger.
J.Schönwälder - L.Deri v. 1.4 Network Management / 287
CIM Schemata
There are three classes of schemata:
The Core Schema represents basic and partially relatively abstract elements ofa management environment. Some fundamental classes are:
• ManagedSystemElement: Base class.
• PhysicalElement: represents the physical aspect of an element (subclassof ManagedSystemElement).
• LogicalElement: represents the physical aspect of an element (subclass ofManagedSystemElement).
• System: Aggregates a set of ManagedSystemElement instances.
The Common Schemas is an extension of the Core Schemas.(Application Schema, Physical Schema, Device Schema, System Schema)
The Extension Schema is for manufacturer-specific extensions of the CommonSchema.
J.Schönwälder - L.Deri v. 1.4 Network Management / 288
CIM Evaluation
Strength:
Unlike SNMP, CIM is fully object oriented.
Drawbacks:
Based on the “reinvent-the-wheel” approach that prevented its widedeployment by customers and vendors. Unlike the PC market, the integratedmanagement word is rather conservative, not interested to marketing hype,and based on previous efforts and specifications.
Most of schemata have been inherited by the database world making CIM notreally suitable for management as it lacks many specifications.
By not conforming to the OMG’s modelling terminology and by mixingdatabase and object-oriented terminology, it has caused somemisunderstanding in the network and system management community.
J.Schönwälder - L.Deri v. 1.4 Network Management / 289
6.4 Java-based Network Management
Motivation (Motivation (http://java.sun.com/products/JavaManagement/) Foster the Java technology in the equipment, network and service management market.Foster the Java technology in the equipment, network and service management market. Provide a Java Infrastructure to facilitate the management of Java applications.Provide a Java Infrastructure to facilitate the management of Java applications. Provide a Java Infrastructure to manage legacy environments through Java technology
Why now? Distributed Java application components that must be managed emerge Mature Java technology Today’s management requires more flexibility and dynamicity
Why Java ? Java is successful in the industry. Java as a framework evolves much faster than other middleware solutions:
API definition time is very short.Increasing number of Java-enabled devices (e.g. PALM V has a J2ME VM and Swing
as well).Java offers a variety of promising and useful APIs and architectures:
– JINI, JMS, GUI toolkits, JNDI, JIRO, ... Performance and robustness will (likely?) evolve.
J.Schönwälder - L.Deri v. 1.4 Network Management / 290
Java Management Extensions (JMX): Architecture
MBeanMBeanMBean
ServiceMBean
ServiceMBean
ServiceMBean
Agent
Manager
Instrumentation
Connector Connector Proto. Adapter Proto. Adapter
HTML XML
SNMPAPI
WBEMAPI
TMNAPI
LegacyServices
MBean MBean
SNMP
JMXManager
Agent
JMXApplication
CorbaAPI
J.Schönwälder - L.Deri v. 1.4 Network Management / 291
Java-based Network Management
JMX API (JMAPI)
Set of extensible objects and methods, defines an application programminginterfaces (API) which includes:
Java Management API User Interface Style Guide
Admin View Module (AVM)
Base Object Interfaces
Managed Container Interfaces
Managed Notification Interfaces
Managed Data Interfaces
Managed Protocol Interfaces
SNMP Interfaces
Applet Integration Interfaces
Java Dynamic Management Kit 2.0
A Java agent toolkit for rapid development of autonomous Java agents forsystem, application, or network devices.
J.Schönwälder - L.Deri v. 1.4 Network Management / 292
Java-based Network Management: Pros and Cons
Advantages Elegant and OO approach (close to the OSI one) Technology and Information model tightly coupled Open and lightweight approach Drastically reduces programming costs Makes management of Java components very easy It is very easy to take advantage of additional Java APIs such as JINI, JDBC, JNDI.
Drawbacks Political risks
not all major companies or telecom operator is involved (so far) in JMXThe name and the APIs change too often: JMAPI, JDMK, JMX.... JMnextGeneration
Technological risksscalabilityperformance in large environmentsNo global naming and location transparency yetAgents must be known to be accessedAgent-only side (manager applications are out of scope of JMX)
J.Schönwälder - L.Deri v. 1.4 Network Management / 293
6.5 Application and Service Management
Monitoring and optimisation of complex applications (e.g. databases, complexdistributed application software) is becoming increasingly important:
Strong interest in a performance management.
Security management of applications.
Fault management.
The telecommunications world makes new services available, which must becreated and configured efficiently in ever shorter time intervals:
Strong interest in the configuration management.
Service performance management.
Management of service quality parameters (SLA - Service Level Agreement).
At present there are many different activities in the development and testing ofapplications for service management.
J.Schönwälder - L.Deri v. 1.4 Network Management / 294
The process oriented view records statistics regarding the processes and the servicesimplemented.
The service-oriented view records statistics of a service potentially implemented by severalprocesses.
The World-Wide-Web MIB records statistics about WWW services:
Independence from the protocols (ftp, HTTP, Web NFS...) for the definition of an abstractdocument transfer protocol.
Limitation on statistics for error detection and data lookup. No "hit metering” !
Internet Application Management
System Application MIB
Application MIB
WWW MIB
Process oriented view, system wide,no application instrumentation
Process and service oriented view,Application instrumentation
Service oriented view,Application instrumentation
J.Schönwälder - L.Deri v. 1.4 Network Management / 295
Structure the WWW MIB Services
The MIB is composed of three groups:
Service Information Group
Protocol Statistics Group
Document Statistics Group
Abstract Document Transfer Protocol (DTP):
the abstract DTP is based on request/response interactions.
Each request has a type specified with a OCTET STRING.
Each response has an INTEGER status field.
Individually requests can produce several responses.
At present figures of the abstract DTP for HTTP and FTP have been defined.
Figures for further protocols (e.g. NNTP) can be defined.
It would be desirable to have implementations for freely available software (e.g.Apache).
J.Schönwälder - L.Deri v. 1.4 Network Management / 296
Typical implementation of the suggested MIBs
The application instrumentation within the is implemented by means of asubagents embedded into the application.
During MIBs design, it has to be considered that tables can be made of subagents.
The definition of a unique services identifier of is problematic. Its definition canlead to problems, if independently developed subagents provide information abouta co-operative provided service.
Master Agent
SysApplMibSubagent
SNMP
AgentX
ApplMibSubagent
AgentX
Application 1
ApplMibSubagent
Application 2AgentX
J.Schönwälder - L.Deri v. 1.4 Network Management / 297
6.6 XML-based Management: Motivation
Motivation
Routers are complex devices that are hard to manage remotely
SNMP model is not rich enough
Writing expect scripts is time consuming and error prone
Operators and network management software vendors demand a secure,stable method to access routers
Want network-oriented solutions, not single-box ones
Use an API to manage routers:
Standards based APIs improve interoperability and integration betweendiverse systems
– Facilitates interconnection between multi-vendor platforms
– Reduces in-house and 3rd party integration effort
A common API can increase the available pool of development resources
– I.e. HTML based API
J.Schönwälder - L.Deri v. 1.4 Network Management / 298
XML-based Management vs. Other Approaches
SNMP
Internet standard management protocol widely used for network monitoring and faultmanagement but not so widely used for configuration
Many vendors don’t support their full configuration (or even monitoring) capability viaSNMP
Security problems addressed with SNMPv3
Expect [http://expect.nist.gov/]
Allows programmatic interaction with device command line interfaces Widely used as a practical network management tool
Used to acquire data from CLI not exposed via SNMP MIBsASCII format is appealing for simplicity and debugging
Error prone, especially when vendors upgrade their CLI
Corba Network object access protocol Versioning and backwards compatibility issues Vendor incompatibility between ORBs Large footprint a tight fit on embedded systems
J.Schönwälder - L.Deri v. 1.4 Network Management / 299
XML-based Management: Introduction to XML [1/2]
eXtensible Markup Language: http://www.w3c.org/xml
XML is a generally self-describing data format
Application reads data, parses it, and knows exactly what each constituent part of thedata means
An XML document is a “text file with structure” easy to understand, parse and debug.
Six main constructs
Open tags: <tag> Close tags: </tag> Data: <tag>data</tag> Empty tags: <tag/> Attributes: <tag foo=“bar” go=“gar”/> Namespaces:
<ns1:home> <address>123 Main Street</address> <network xmlns:ns2=“my.identifying.string”> <ns2:address>10.0.0.1</ns2.address> </network></ns1.home>
J.Schönwälder - L.Deri v. 1.4 Network Management / 300
XML-based Management: Introduction to XML [2/2]
XML data definition tools
Document Type Definitions (DTDs)
Lists the elements that may appear in an XML document and theirrelationships to one another
XML Schemas
Defines content and semantics in addition to element relationships
XSLT
Language for transforming XML documents
XML -> XML
XML -> (XHTML, XSL-FO, DocBook) -> formatted output
J.Schönwälder - L.Deri v. 1.4 Network Management / 301
XML-based Management: JUNOScript [1/4]
JUNOScript is an XML-based API to JUNOS [http://www.juniper.net/techpubs/software.html] Uses an RPC paradigm
Client sends requests enclosed in <rpc> tags<rpc>
<get-interface-information><name>so-1/3/0</name>
</get-interface-information></rpc>
Server response is enclosed in <rpc-reply> tags<rpc-reply>
<interface-information><name>so-1/3/0</name><admin-status>up</admin-status>…
</interface-information></rpc-reply>
J.Schönwälder - L.Deri v. 1.4 Network Management / 302
XML-based Management: JUNOScript [2/4]
If reply is affirmative, an empty <rpc-reply></rpc-reply> tag pair is returned
Errors are indicated by the <junos:error> tag
Any attributes included on the <rpc> tag are echoed on the <rpc-reply> Useful for client bookkeeping
The top-level tag in the reply includes an attribute defining the XML namespace for thereturned data
Only 1 request can be outstanding at a time
Server returns errors as <junos:error> tags
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/junos.dtd">
<junos:error>
<message>configuration database modified</message>
</junos:error>
</rpc-reply>
Client can send <junos:abort/> to abort server’s request processing
Server responds with <junos:abort-acknowledgement/>
J.Schönwälder - L.Deri v. 1.4 Network Management / 303
XML-based Management: JUNOScript [3/4]
<rpc> <get-chassis-inventory/> <!-- Same as CLI's 'show chassis hardware‘</rpc>
<chassis-module> <name>Display</name> <version>REV-04</version> <part-number>710-001519</part-number> <serial-number>AC2803</serial-number> </chassis-module> <chassis-module> <name>Host 0</name> <serial-
number>0e000006175d8a01</serial-number>
<description>Present</description></chassis-module><chassis-module><name>Host 1</name><serial-number>af0000062ae60201</serial-
number><description>Present</description></chassis-module><chassis-module><name>SSB slot 0</name><version>REV 05</version><part-number>710-001411</part-number><serial-number>AE2680</serial-number><description>Internet Processor
I</description></chassis-module>…</rpc-reply>
<rpc-reply> <chassis-inventory xmlns=“…/junos-
chassis.dtd“> <chassis junos:style="inventory">
<name>Chassis</name><serial-number>20388</serial-number><description>M20</description><chassis-module><name>Backplane</name><version>REV 07</version><part-number>710-001517</part-number><serial-number>AB6192</serial-number></chassis-module><chassis-module><name>Power supply A</name><version>Rev 02</version><part-number>740-001465</part-number><serial-number>000476</serial-number><description>AC</description></chassis-module><chassis-module><name>Power supply B</name><version>Rev 02</version><part-number>740-001465</part-number><serial-number>000506</serial-number><description>AC</description></chassis-module>
J.Schönwälder - L.Deri v. 1.4 Network Management / 304
XML-based Management: JUNOScript [4/4]
Simplifies application development
Standard, commonly used language
Widely available tools and information
Easy to understand text format
Larger talent pool of engineers
Offers a reliable alternative to Expect scripts
XML’s self-describing data prevents problems with variations in CLI output
Enhances Interoperability
XML is a standard method of exchanging information between programs
Adopted by many industries – eCommerce, databases, networking, etc.
J.Schönwälder - L.Deri v. 1.4 Network Management / 305
XML-based Management: WebServices
A web service is a software system identified by a URL, whose public interfacesand bindings are defined and described using XML. [Official W3C Definition]
Definitions: XML (eXtensible Markup Language)
Markup language that underlies most of the specifications used for Webservices.
SOAP (Simple Object Access Protocol) A network, transport, and programming language-neutral protocol that
allows a client to call a remote service. The message formatis XML. WSDL (Web services description language)
An XML-based interface and implementation description language. Theservice provider uses a WSDL document in order to specify theoperations a Web service provides.
UDDI (universal description, discovery, and integration) Both a client-side API and a SOAP-based server implementation that
can be used to store and retrieve information on service providers andWeb services.
J.Schönwälder - L.Deri v. 1.4 Network Management / 306
WebServices: Architecture
J.Schönwälder - L.Deri v. 1.4 Network Management / 307
WebServices: SOAP
J.Schönwälder - L.Deri v. 1.4 Network Management / 308
WebServices and Network Management
Why the management world is becoming interested in web services?
SNMP is somehow complicated for common users that instead know/use webtechnologies such as HTTP and XML.
The web services technologies are already used in other fields so they arebasically for free (no software to install nor encoders/decoders).
Many available applications are web services aware. For instance it is possible touse Microsoft Excel to grab monitoring data in a few Visual Basic lines of code(.NET is required).
How is the management world using web services?
Create gateways (e.g. from SNMP) to web services.
Reuse existing MIB experience for modeling new systems using past experience.
Develop simple SOAP-based services to be embedded in appliances so that theycan be managed using web services instead of SNMP.
J.Schönwälder - L.Deri v. 1.4 Network Management / 309
6.7 Towards Policy-based Management
Issues in distributed system management:
Large scale: thousand of objects to manage.
Multiple organisations and different equipment to manage
Requirement Availability: minimise downtime.
Distribution: devices may be located in physically distant sites making difficultto maintain them in a consistent state.
Security: management is powerful hence it must be protected by unauthorisedusers.
Policy-based management solutions to the above problems:
Use domains to group managed objects across large organisations in order tosimplify management or reflect organisational structure.
Use an automated policy to guarantee availability and ease replication anddistribution.
Use authorisation (licensed agents) to enforce security.
J.Schönwälder - L.Deri v. 1.4 Network Management / 310
Policy Based Management: Domains and Policies
Domains
A domain is a collection of objects which have been explicitly grouped togetherfor management purposes e.g. to apply a common policy.
Domain Hierarchy
Domains are grouped in a hierarchical structure to reflect an organisationalstructure (e.g. company, departments) or a network structure (e.g campus,building, floor).
Management Policy
A management policy defines the behaviour of the network/system undervarious circumstances. A policy can be defined from two perspectives:
A definite goal, course or method of action to guide and determine presentand future decisions.
Policies as a set of rules to administer, manage, and control access tonetwork resources.
J.Schönwälder - L.Deri v. 1.4 Network Management / 311
Policy Based Management: Management Policies
A management policy:
Influences the behaviour of managed objects: change policy to changebehaviour.
Is persistent (e.g. backup the system every night at 3 AM).
It can be dynamically changed via a management protocol.
Policies are defined in a PDL (Policy Description Language). Policies are of twotypes:
Obligation Policy: what managers must do
Authorisation Policy: what managers are permitted to do
Manager(Subject)
ManagedObject
(Target)
Obligation Policy Authorisation Policy
Monitoring (Events)
Control (Actions)
J.Schönwälder - L.Deri v. 1.4 Network Management / 312
Authorisation Policies
Defines what a subject is permitted or not permitted (prohibited) to do to a target.
Protects target objects from unauthorised management actions
Target based: the target is responsible for interpreting and enforcing the policy(managers cannot be trusted to interpret the authorisation policy).
Defaults: authorisation (everything except…), negation (everything prohibitedexcept…)
Example:
A+ (Authorisation) AGroup {videoconfence(bandwidth=4, priority=3)} AGroupRome & AGroupMilan
when (16:00 < time < 18:00)
A- (Non Authorisation) X:sysAdmin{read, write} Passwords when X.location <> ComputerRoom.
Subject TargetActions Constraints
J.Schönwälder - L.Deri v. 1.4 Network Management / 313
Obligation Policy
Defines what activities a subject must (or must not) do.
Assumes well behaved subjects with no freedom of choice.
Subject based: subject interprets policy and performs actions on targets.
Event triggered positive obligation: an event that indicate a component failure orerror rate exceeded a threshold is used to trigger a management action.
Example:
O+ At 01:00 archiver {backup} AdministrationPCs
O+ On 3*LoginFail(userid) SecurityAgent{disable(userid), log(userid),
notify(sysadmin, userid)} users
O- Tutors {TellResults} students when date < FinalExaminationMeeting
O- Guard {Lock} gate when (22:00 < time < 07:00)
J.Schönwälder - L.Deri v. 1.4 Network Management / 314
Policy Implementation
A step-by-step guide to policy implementation:
Administrators edit or create policies for a gives service.
Policy service uses target domain to query domain service for identifying towhich target object authorisations should be sent.
Policy service uses subject domain (managed objects) to determine to whichagents, obligation policies should be sent.
Managed objects emit events which are disseminated by the monitoringservice to agents, where they trigger obligation policies.
Manager agents determine target object by querying domain service
Agents invoke operations on domain service.
J.Schönwälder - L.Deri v. 1.4 Network Management / 315
Policy Protocols: COPS vs. SNMP
COPS (Common Open Policy Service) RFC 2748
Dedicated “Configuration Management” Protocol.
High level objects (SNMP has very basic objects).
It exploits a Policy Information Base (PIB).
Single Operation to Add or Delete Table Rows.
Reliable Communication (TCP) between PDP (Policy Decision Point) and PEP(Policy Enforcement Point).
Each PEP is connected to a single PDP.
SNMP
Integrated Approach to Management.
Policies can be defined within MIBs.
Each PEP (Agent) can be connected to multiple PDPs (Managers).
J.Schönwälder - L.Deri v. 1.4 Network Management / 316
Policy-based Management: An Example
BandwidthBroker
PolicyRepository
Policy DecisionPoint (PDP)
Router Router Router
LDAP
LDAP
COPS/SNMP
PEP PEP PEP
PEP: Policy Enforcement Point (Target)
PDP: Policy Decision Point (Manager)
J.Schönwälder - L.Deri v. 1.4 Network Management / 317
6.8 Latest Developments by IRTFNw Mgmt Research Group
Efficient Transfer of Bulk Data
SNMP over TCP (Experimental RFC)
Compression of both OIDs and data.
Definition of the Get-SubTree operation.
SMING (SMI Next Generation)
Independent from external standards (i.e. self contained).
Based on augmented BNF.
Additional datatypes without requiring the SMI standard to be updated ashappens with SMIv2.
Simple syntax easy to parse (hence compilers/parsers are easy to build).
Active Management
Allow management functions within MIBs.
It can be used both over SNMP and COPS.
J.Schönwälder - L.Deri v. 1.4 Network Management / 318
Simple Network and System Management Taxonomy
Centralised Hierarchical Co-operative
Paradigms Paradigms Paradigms
Not SNMP v1,2,3
Distributed WEBM
HTTP
Weakly SNMPv1+RMON
Distributed SNMPv2+M2M
OSI/TMN
Strongly SNMPv3+Script Intelligent
Distributed Mobile Code Agents
Java RMI
Distributed Objects
J.Schönwälder - L.Deri v. 1.4 Network Management / 319
Information Abstraction Level
Management Managed Computational Goal
Unit Object Object
Abstraction Low High Very high
Level
Location MIB object Intelligent agent
Access Mgmt Protocol Method Agent Language
SNMP/CMIP Call Method call
Degree of
Specification Full Full Partial
Top Related