sistemi di elaborazione dell’informazione: elementi...

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]>


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


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/


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)


1. Introduction

1. Introduction

1.1 Motivation

1.2 Terminology and basic concepts

1.3 Networking Basics

1.4 Abstract Syntax Notation One


3. OSI Management

4. Integrated Systems Management




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.


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.


Network Management Dimensions

Security

Performance deduction

Performance evaluation

Anomaly management

Configuration management

Planning Installation Operation Migration

ComponentsSystems

UsersEnterprise

Functional Dimension

Object Dimension

Time Dimension


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.


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).


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.


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.


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.


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.


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.


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.


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.


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.


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


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


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.


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


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.


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.


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.


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)


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).


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.


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.


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).


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.


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


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.


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


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


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


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).


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.


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...


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


ISO Standardisation

Working Document

Committee Draft

Draft InternationalStandard

Full Standard

TechnicalReport

TechnicalReport

No Implementation

Still NoImplementation !

Reject

Reject

Modifications Needed



IETF Standardisation

Working Document

Proposed Standard

DraftStandard

Full Standard

Historical

Historical

Implementation experiencemust be obtained

Several independentimplementations must

interoperateReject

Reject



After a maxof 2 years

After a maxof 4 years


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.


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)


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).


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.


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)


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.


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.


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) }


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


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

}


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


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)


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


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.


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


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

....


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


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).



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





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.


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.


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)


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.


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.


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)


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)


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.


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)


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


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


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


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


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


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.


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


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“.


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


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).


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 }


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.


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 }


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 }


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.


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 }


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.


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.


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


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


OCTET STRING DISPLAY-HINTS

[<repeat>]<number><format>[separator][terminator]

Example: ´´255a´´ format for the ASCII characters ´áBc´´ in the string ´áBc´´ ´´1x:´´ format for the ASCII characters ´áBc´´ 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


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))


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))


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.


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 }


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 }


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 }


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


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).


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) ...


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.


"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)


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)


"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)


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


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

)


Case Diagram for the “ip“ Group

ipInDelivers ipOutRequests

ipInAddrErrors

ipInHdrErrors

ipInReceives

ipOutNoRoutes

ipOutDiscards

ipForwDatagrams

ipFragOKs

ipFragCreates

ipFragFails

ipInUnknownProtos

ipInDiscards

ipReasmOKs

ipReasmFails

ipReasmReqds


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


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


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


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


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


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


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


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


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.


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.


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.


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:


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


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)


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


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)


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


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)


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


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)


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.


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


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


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


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


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


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


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.


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


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 }


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


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


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


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).


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


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.


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



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


ProxyForwarder

Access ControlSubsystem

MIB Instrumentation

View-basedAccess Control


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:


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.


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).


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.


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


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?


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


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.


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.*


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.


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.


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.


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.


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


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.


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.


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).


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.


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


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


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.


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.


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).


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


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


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.


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


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


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


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


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.


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


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).


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.


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


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.


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/


3. OSI Network Management

1. Introduction


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





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.


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)


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.


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.


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.


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.


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.


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


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.


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.


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 }


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


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).


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.


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.


Scoping Example

Basis instance Instances of the nth layer

All instances up to the nth layer All instances under the base instance


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.


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.


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.


Scoping, Filtering and Synchronization

YesYesYesM-ACTION

NoNoNoM-CANCEL GET

NoNoNoM-EVENT REPORT

YesYesYesM-SET

YesYesYesM-GET

YesYesYesM-DELETE

NoNoNoM-CREATE

SynchronizationFilteringScoping


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



RO-Invoke

RO-Error

Aborted Operation

Operation withPositive Reply(success)

Operation Error

Manager Agent


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



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


eM-GET.response



eM-GET.response



e

Manager Agent


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



RO-Invoke

RO-Invoke


eM-GET.response


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


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

....


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


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.


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.


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


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...


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


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


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.



1. Introduction


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


6. Actual Developments


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.


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


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.


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.

...


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.


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.


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!


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.


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.


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.


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)


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.


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


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


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


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)


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!


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.



1. Introduction


3. OSI Management



5.1 MIB Based5.2 Remote Operations Based5.3 Management by Delegation

5.4 Script Based

5.5 OSF DME

6. Actual Developments


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


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


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.


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


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.


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.


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.


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.


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


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.


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


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)


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


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.


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


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.


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.


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.


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.


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 */)


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.


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.


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).


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.


Construction of Symmetric MbD Agents

delegationserver

delegationclient

runtime environmentthreads

agentrole

manager roleMIB

delegationprotocol

delegationprotocol

managementprotocol

managementprotocol

procedures


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.


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. . .


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


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.


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.


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


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


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


1. Introduction


3. OSI 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



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)


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


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, ...).


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.


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.


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.


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


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.


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.


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;


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


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);}


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.


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


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


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.


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.


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.


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.


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.


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


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.


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)


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.


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


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).


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


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


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


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>


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


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>



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/>

<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>



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.


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.


WebServices: Architecture


WebServices: SOAP


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.


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.


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.


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)


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


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)


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.


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).


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)


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.


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


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

sistemi di elaborazione dell’informazione: elementi...

Documents