Network Management Jacques Labetoulle Professor at Institut Eurécom.

Post on 19-Dec-2015

214 views 0 download

Tags:

Transcript of Network Management Jacques Labetoulle Professor at Institut Eurécom.

Network Management

Jacques Labetoulle

Professor at Institut Eurécom

Overview• 1st part : Introduction

– Definition– Architectures and functions– Network Planning

• 2nd part : standards– Introduction to Object Oriented Approach– OSI standards – Internet standards– Comparison– The TMN

• 3rt part : platforms and products• 4th part : Perspectives

– CORBA and network management– Other approaches (Web, agents, ...)

Introduction

• Definition and motivations

• Support architecture

• Management domains

• Network planning

Network Management

• DefinitionIt is the set of all techniques to implement in order to master the technical, financial, organizational aspects of a private network as well as the access and

information security.

• Some key words- technical area : quality of service

continuity of service

- financial area : truth of the prices

- organizational area: control of the structure and evolutions

- security area : confidentiality

access control

The network in the enterprise

• Strategically important– finance (air plane reservations )

– security (bank transfers)

– service (bank notes distributors )

– competition (stock management)

• Service obligations– continuity of service

– quality of service

– adaptability (on demand evolutions)

– cost control

Complexity of networks

• Network evolutions

centralized networks ---> distributed networks

homogeneous networks ---> heterogeneous networks

separated networks ---> integrated networks

• Evolution of network utilization– generalization to all kind of personal

– opening to external clients or people

– multiplicity of services

Networks elements in a corporatenetwork

• Multiplicity of kinds of equipmentcommunication controllers

end of line equipment

multiplexers

PABX

LAN

interconnection equipment

interconnection networks

packet switches

computer manufacturers architectures

public networks and services • Multiplicity of providers• Rapid technological evolutions

Why to manage a network?

• Economical reasons– excessive global costs (> 1% of cash flow)

– increase of network budget (20% per year)

– tractability of prices

(multiplicity of services and evolutions)

• Complexity increase – offers from operators

– generalization of local area networks

– sophistication of equipment

• Pressure from the users• Internetworking with other networks

Management areas

Functional domain

manufacturers

Voice

Data

Computer networks

Integrated networks

Perf

orm

ance

Secu

rity

Faul t

s

Confi

gura

tion

Acc

ounti

ngAlcatel

BullIBM

TRTMatra

SAT

LAN

ATM

Network Management today

• 1- It exists

• 2- It is not satisfactory

• No coherent offer

– from network operators– from manufacturers– from service providers

• Non-adapted standardization

Network Management today

• Diversity of solutions : a large variety of proprietary systems characterized by:

– limitation of management domains --> partial visions– very different ergonomics --> problems of qualification of

people– functional limitations --> partial control of networks

(faults, performance) – communication difficulties --> partial and local visions

multiplicity of work stations– A few intelligence in systems --> necessity of highly qualified persons

Network Management tomorrow

• Universal workstations

– high ergonomics

– remote management

– multiples visions

– adaptation of functions to needs

– help systems

– automation

– possibilities for evolution and adaptations

• An adapted standardization

• Integration of new techniques

Users’ point of view

• Coverage of the solution and integration– the whole enterprise (and not only the headquarters)

– integration : network, systems, applications, services

– integration : all kinds of elements (voice, data, ...)

• To day advance– very variable

• Partners– manufacturers, software editors

• Difficulties (by order of importance)– training,

– performance of the offer,

– interoperability

– ... cost

Introduction

• Definition and motivations

• Support architecture

• Management domains

• Network planning

Principles for an architecture

• A logical architecture

– definition of elements• A physical architecture

– how to connect elements• A set of functions

– definition of usage• A methodology

– conception, evolution of the management system

Architecture

Integrator machine

EMSEMSEMS

Othermanagement

systems

(PNO) Integrator machine

Integrator machine

Agent Agent Agent Agent Agent AgentAgentAgent

Architecture : the EMS's

• Close vision of a sub-area• Proprietary interfaces with equipment (now)• Normalized interfaces with the integrator• Independence from manufacturers and equipment• Possibility of "migration" of functions between Integrator and EMS's

Architecture : the work stations

• High quality ergonomic

• Specialization of operators

- access security

- control of different visions

• Direct access to information

Architecture : The integrator system

• A set of functions- for universal needs

- easy adaptations

• flexibility (centralization/distribution)• Basic components

- exchange procedures

- man/machine interface management

- information system

- functions

- intelligent systems

Architecture : The integrator system

• A sufficient vision of problems

- notion of "view" of sub-networks

• Reasonable performance

- installation dimensioning

- portability on a set of machines

Introduction

• Definition and motivations

• support Architecture

• Management domains

• Network planning

Classification of functionsreal time / differed time activities

• Real time activities

- behavior supervision

- detection of incidents, fault diagnostic

- launching of rerouting procedures , maintenance, etc.

- access control to services and resources

• Differed time activities

- network configuration management

- access and security rights management

- financial management : cost affectation , bill verification

- edition of statistics and dash boards

- planning, simulation

Classification of functionsareas breakdown

• 5 areas defined by OSI

- Configuration management

- fault management

- Performance management

- accounting

- Security management

configuration management

• Management of the Information base (MIB)

- Inventory of network elements

- Management of names of managed elements

- add, delete, change of network components

- Initialization and modification of parameters, states, ...

- Modification, creation, suppression of relations between managed elements

• Network visualization

- Global visualization

- Geographical Zooms

- Sub-networks visualization

- On demand display of managed elements characteristics

Configuration management(continued)

• Reconfiguration

- Activation of stand by configurations

- resources re-affectations

- Remote software loading

- Edition of operational state modifications

- History of reconfigurations

• Creation of directories

- Directory of offered services

- Directory of users

- Directory of furnishers

Fault management

• Fault detection

- Creation of misbehavior reports

- Management of counters and alarm thresholds

- Event filtering (elimination of redundant information)

- disfonctionnement display

• Fault localization

- Analysis of alarm reports

- Launching of measurements and tests

==> Computer assisted diagnosis

• Initialization of corrective actions

- Resource re-affectations

- Re-routings

- Traffic limitations ==> Decision support system

- calling to maintenance

Fault management (continued)

• Equipment recovering

- Launching of behavior tests

- Backup systems management

• Recording of fault histories

("trouble tickets")

• Establishment of statistics

- breakdown probabilities

- duration of incidents

- Duration of repairing

• Interface with users

- signaling of incidents by users

- information to users

Accounting• Resource usage measurement

- Recording

- Creation and management of record files

• Control of quotas by user

- establishment of current consumption

- Verification of consumption authorizations

• Follow up and control of expenses

- recording of up to date tariffs (from operators)

- management of taxation tickets

- real time evaluation of current consumption

- bill control

- follow up of equipment costs

(investments, deadening, maintenance)

- follow up of exploitation costs

Accounting (continued)

• Financial management

- cost splitting

(by service, by user, by application)

- Analysis and prevision of expenses

- Study of scenarios for cost minimization• Internal billing

- Management of users

- Management of tariffs

- Creation of taxation tickets and bills

- Bill control

- Recording of historic

Security management

• Security of Network Management

- Management of access rights to working stations

- Management of operator "views"

- Access control to management information

• Access control to the managed network

- Functions dedicated to the mechanisms :

definition of usage conditions

activation/deactivation of mechanisms

modification of parameters

management of authorization lists

(to machines, services, network elements)

Security management (continued)

- Tracking of access (identity, time, destination)

- Detection of fraudulent access attempts

recording

statistics

setting of alarms• Information Security

- Management of protection mechanisms

- Management of encryption and decryption keys

- fault detection

- Detection of fraudulent attempts

Performance management (Real time)

• Recording of performance measurements

- Definition of measurement conditions criteria

- Management of information collecting and filtering

- Establishment of statistics

- Launching of on demand measurements

- Management of information files

• Monitoring of network behavior

- Visualization resource utilization

- Signaling of threshold overpass

Performance management Real time (continued)

• Performance measurement analysis

- Network behavior

load repartition

throughputs

response times

availability

- Analysis of probable reasons of threshold overpass

correlation with equipment faults

indicators comparison and correlation

==> computer aided system

Performance managementReal time (continued)

• Corrective and preventive actions

- Resource re-affectation

modification of configuration parameters

traffic routing optimization

- Traffic Limitations

filtering, priorities

- Choice of action mode ==> computer aided system

• Follow up of actions results

- Recording of historic

- Analysis of action efficiency, definition of rules

Performance managementDiffered time

• Information analysis

- Establishment of statistics and historic

- Establishment of quality of service indicators

- Edition of reports (periodically or on demand)

- Edition of dash boards

• Provisional analysis

- Elaboration of traffic matrices

- Evaluation of performance

detection of saturation risks

simulation of scenarios

==> improvement of the QoS

balancing of resource utilization

- Network planning et dimensioning

- Follow up of corrective management

Other management areas

• Planning (see later)

• Park management (inventories, catalogue, installations, ...)

• Cabling management

• License management• Host management (users, disks, versions, ...)

Introduction

• Definition and motivations

• support Architecture

• Management domains

• Network planning

Time scales

Scale operations actions

minutes supervision observation of network

real time management problem detection

corrective actions

hours day to day maintenance

days management statistics (performance, traffic)

configuration programmed operations

security installations

Time scalesweeks operation management purchases

months financial management billing

corrective management re-dimension

modifications (routings, ...)

year short term topological evolutions

planning dimensioning, routings, ...

choice of support services annual budgets

> 1 year Strategic or strategic decisions

long term planning choice of target structures evolution towards these

structures

evolution plans

Important steps

• Evaluation of traffic needs

• Choice of a target structure

• Choice of support services

• Dimensioning and optimization

• Verification

Traffic needs

Problem : find an adequate traffic representation

• telephony : volumes easy to measure

notion of heavy load hour (per site, per link, ...)

traffic measure : the Erlang

• data : measure unit : packets, transferred octets, bandwidth needs

Often : global measures (heavy load hour, possibility of differed transfers, ...)

Do not forget protocol’s overheads!

Traffic needs

• Empirical rules : heavy load hours :

20% of the daily traffic on 8 hours

or 16% for 12 hours ; or 14% for 24 hours

heavy load hour traffic = 2,5 times the mean hourly traffic

mean traffic at heavy hours : V/3600 (in bit/s or messages/s)

• Other method : calculate the traffics per hour (no heavy hour traffic problem)

Evaluation of traffic needs

• 1- Extrapolation of traffic matrices

– organize measurement campaigns (per week, month, year, ...)

– calculate representatives values, per period• global volumes

• heavy hour volumes

– utilize mathematical techniques for chronological series extrapolation (linear regressions, Kalman filtering, ...)

– correct, taking into consideration the impact of new services

– Can use directly network management measures and techniques.

Evaluation of traffic needs

• 2- Direct analysis of flows

– analysis of the structure of the enterprise (types of entities, organization levels, ...)

– analysis of the relations and applications used

– evaluate elementary flows and integrate them

– how to proceed : inquiries

– necessity of a validation (by direct measurement of existing flows)

Choice of a target structure• Problem

– Determine main orientations (strategic choices) :• meshed or star network

• where to implement transit centers

– choice of structures from the market (manufacturer networks, private network, based on PNO’s networks and services , security aspects , redundancy, ...)

– fundamental technological choices : kind of LAN, migration towards ATM

• Remark : mixing of technical and political problems

Choice of a target structure• Problem : determination of the basis of the solution

– Start from the needs, characterized by – traffic volumes and characterization (sporadic, interactive, big

transfers, ...)

– constraints : costs, performance, security

– offers : technical constraints , tariffs, performance, easy of use, ...

• Method : a lot of logic and common sense– take into account scales economy– integrate traffics leads to economies– use of elementary rules

• regular traffics ===> dedicated networks

• sporadic traffics ===> switched networks

• variable traffics ===> virtual private networks

– look carefully at pricing principles

Dimensioning and optimization

Basic techniques

1- Inversion of performance evaluation formulas

telephone networks :

B(A,N) = Erl (A,N) = AN/N! / (1+A+A2/2+ ....+ AN/N!)

data links (Kleinrock’s independence assumption) :

W = 1/(Ci - Di)

• In fact, dimensioning is often made by using a maximum utilization factor (60 or 70% of capacity).

Dimensioning and optimization (follow up)

2- Economical optimization

formalize the problem as an objective function minimization problem (the cost), subject to constraints (arcs and nodes capacity, performance, ...)

elementary costs may depend on non trivial functions (step functions)

To solve the problem : OR techniques (linear or integer numbers programming, ...., simulated annealing).

in general, problems are NP-complete and can be solved only by heuristics

• Results of this step : a dimensioned network, the routings, installation and exploitation costs (monthly costs, maintenance costs, ...)

Dimensioning and optimization Example of a formalization problem

• Min C = Cj ej + Ci,j ei,j + CRj ej

installation of a concentrator in j ; cost of the link between i and j ; cost of the link from the concentrator j to the central node.

ei : 1 if a concentrator in j, 0 if not

ei,j : 1 if site i is linked to site j (concentrator’s location) ,

0 if not

With the constraints :

i ei,j = capa capacity of the concentrator

j ei,j = 1 only 1 link between two sites

j ei,j ej= 1 each link towards a site with a concentrator

Verification of the solution

• The solution needs to be validated :– simplifies assumptions (performance)

– necessity to validate for each time slot

• How to proceed :– analytical methods (queuing theory)

– event driven simulation (also useful to analyze evolutions of the networks)

Standards

• The object oriented approach

• The OSI standards• SNMP

Encapsulation

METHODS FIELDS

INTERFACE

Classes

Two components:

• static component : the data, composed of fields. They characterize the state of the objects during execution.

• dynamical component : procedures called methods. They represent the common behavior of the objects belonging to the same class. The methods manipulate the fields et characterize the actions done by the objects.

Example of a class

• Class Article

• Fields referencedesignationpriceHT (excluding VAT)quantity

• Methods PriceTTC (): return (1.186 * priceHT)transportPrice (): return (0.05 * priceHT)retire (q) quantity <---- quantity - qadd (q) quantity <---- quantity + q

Instantiation

• The class describes the object

• It is used as a model to build instances

• The list of the fields is hold by the class

• Instances have values

• Methods are not duplicated

Example of instantiation

Article

reference

designationpriceHT

quantity

priceTTCtransportPrice

retireadd

30341

kimono

495.00

1000

60021

portable TV

2480.00

100

Instance of Instance of

Inheritance

• Gathering of common characteristics to several classes

• Classes are specialized by defining sub-classes

• A sub-class shares variables and methods of its super-class

• It inherit the properties of its super-class

• Two techniques can be used :– enrichment : new variables and/or new methods are added

– substitution : a method is redefined

Example of inheritance

• Classclothes

• SuperclassArticle

• Instance variablessizecolor

• Methods

• ClasseArticleDeLuxe

• SuperclassArticle

• Instance variable

• MethodspriceTTC () : return (1.25*priceHT)

Inheritance graph

• The inheritance relation links a class to its super-class

• The graphical representation of this relation builds the inheritance graph

• The inheritance relation is transitive

• The word superclass designates any class from which a class inherits

• The structuring with classes brings an important modularity

• Most of OO languages behave predefined libraries of classes

• For example in Smalltalk-80 : LinkedList, Form (graphical objects), Process, Semaphore, ...

Inheritance graph

OBJECT

Article

referencedesignation

priceHTquantityprixTTC

transportPriceretireadd

ElectroMénager ArticleDeLuxe Clothesguarantyweight

priceTTC colorsize

AspiratornoiceLevelthroughput

Téléviseurtypetube

screenwidth

FreshCaviar origin

weight

Shirtshape

pocketNr

Inheritance graph

• Simple inheritance– The inheritance graph is a tree

– It determines a total order

• Multiple inheritance– A class can have several direct superclasses

– Not a tree, but an oriented graph

– Some classes can be created to be used as "inheritance reservoir". They are not instantiated. In some languages, they are called abstract classes.

– Advantages : improve modularity and avoid duplications

Multiple inheritance

OBJET

Articleréférence

désignationprixHT

quantitéretirerajouter

Transporttypeemballagedatelivraisonprixtransport

Alimélectriquevoltage

impédencepuissance

consommation

Fragileprixtransport

Périssabletempératureprixtransport

Electroménagerduréegarantie

poidsvaliditégarantie

ArticledeluxeprixTTC

Crèmeriedatelimite

Vêtementcoloristaille

Aspirateurniveausonorerayonaction

débitdépression

Téléviseurtypetube

largeurécrantélécommande

Caviarfraisprovenance

poids

Œufsprovenance

Chemisetypecol

typemanchesnbpoches

Relation «is a»

Electroménagerduréegarantie

poidsvaliditégarantie

ArticledeluxeprixTTC

OBJETArticleréférence

désignationprixHT

quantitéprixTTCretirerajouter

Crèmeriedatelimite

Aspirateurniveausonorerayonaction

débitdépression

Téléviseurtypetube

largeurécrantélécommande

Caviarfraisprovenance

poids

Œufsprovenance

Chemisetypecol

typemanchesnbpoches

Vêtementcoloristaille

Périssabletempératureprixtransport

Fragileprixtransport

Transporttypeemballagedatelivraisonprixtransport

Which method to apply?

• Simple inheritance– The inheritance graph reduces to an ordered list.

– The method is found by looking at this list from the bottom.

• Example :Method priceTTC for the class TV :

Inheritance tree of the class :

TV, Article DeLuxe, Article, Object

The selected method is taken in ArticleDeLuxe

Which method to apply?

• multiple inheritance

• The inheritance graph of a class is a graph.

• So there may be a conflict!

E

A

BC

D

D

A

B C

M

M

M

MM

D

A

B C MM

1: no conflict 2: conflict between B and C3: conflict between B and C

Message transmission

• An object cannot directly react on one another.

• It only can activate a method of the target object.

• To do that, he sends a message

• Sending of messages is the only communication mean between objects.

• The reception of a message leads to the research of the method to apply in the environment of the object.

• When the method delivers a result, this one is returned to the sender (transmission with return).

Main OO languages

• Smalltalk-80

• Objective-C LISP and object oriented derivations

(Le-Lisp, Flavors, Ceyx, ObjVLISP,...)

• SIMULA

• C++

• Eiffel

• ADA

• and JAVA!

Notion of view

Lightings

A B

C D

E

Objects

Object in NM

Element

Object

Interface

Object in NM

Newelement

ObjectInterface

Old appli

newappli

Newcharacteristics

Object in NM

• OSI protocol (CMIP)– classical object + specific characteristics

• Internet protocol (SNMP)– no inheritance

– only simple variables

• Other approaches– IDL CORBA

– Java

Standards

• The object oriented approach

• The OSI standards

• SNMP

StandardizationThe ISO model

• General framework

- included in Part 4 of the general ISO reference model

- specify the procedures for managing an heterogeneous network

- define the architectural framework

• Objectives

"plan, coordinate, organize, control and supervise the resources used in the communications in agreement with the ISO model and report on their utilization"

OSI standards

Basic reference modelISO 7298

General frameworkISO 7498-4

General overviewISO 10040

- Configuration management- Fault management

- Performance management- Accounting

- Security management

Definition of the specific management functionsISO 10164 : 1 à n

Structure of the Management Information

BaseISO 10165 - 1

Generic definitions of objets and their

attributesISO 10165 - 2

Framework for objects definitions

ISO 10165 - 4

Definition of specific managed objects

CMISISO 9595

CMIPCommon Managementinformation Protocol

Three models

• Organisational model

• Information model or MIB

• Functional model

The organizational model

• Define the framework to distribute the management

* uses the concepts of "management system" and "managed system or agent"

* The DMAP (Distributed management application process) is the application which controls and supervises the managed objects .

* The Agent Process allows the local management .

Organisation scheme

ManagementSystem

Manage-mentprocess

CMISE CMISECMIP

Agentprocess

Functions

Managedobjects

D

ManagedSystem

Management of objects

Managed object

Attributes

Operation

Notification

Operation : activated by orders sent to the class ( instance creation ) or to the object (method activation )

Notification : activated by the class or the object which send messages (state changes, thresholds overpass

Three models

• The Information model or MIB (Management Information Base)

* document ISO 10165-1

* it is a management information base , which must contain , in a structured manner, the set of all the managed objects, andthe information allowing their identification .

* the managed objects : all the resources used in an ISO communication. They are all defined with their attributes, methods, the messages they emit, the operations they can execute.

* the management information tree (MIT) represents the hierarchy of objects

Three models

• The functional model

* the ISO management is decomposed in 5 tasks :- fault management- configuration management- accounting- performance management- security management

Three management levels

• The system-management level

relies on information exchanges from all the protocol layers (ISO model)

• The layer-management level

- the management is restricted to a given layer (it relies on the services offered by lower layers)

- example : the Network Connection Management Subsystem (NCMS) which specifies a connection management sub-protocol (ISO 8073/AD1)

• The layer operations level

the management is realized by information exchanges within the layer protocol

The information model

• An object oriented approach– a description language

– an exchange language

• Principles– naming

– registration

• Libraries

The information model

• Objective : to allow the definition of managed objects in a standard way.

- coherence of definitions

- coherence with the management environment

(CMIP and functions)

- work repartition

The information model

• The model defines :

- what is an object

- of what it is composed

- what it can do

- what can be done on it

- how it is named in the protocol

- how it is linked to other objects

The information model Description of objects

- the attributes

- the methods

- the relations

- the conditional packages

- the containment tree

- the allomorphism

Description tool

• GDMO templates– MANAGED OBJECT CLASS : definition of a class

– PACKAGE

– PARAMETER

– NAME BINDING

– ATTRIBUTE

– GROUP-ATTRIBUTE

– BEHAVIOUR

– ACTION

– NOTIFICATION

Template "MANAGED OBJECT CLASS"

<class-label> MANAGED OBJECT CLASS

[DERIVED FROM <class-label>[,<class-label>]*;

]

[CHARACTERIZED BY <package-label>[,<package-label>]*;

]

[CONDITIONAL PACKAGES <package-label>PRESENT IF

<condition-definition>

[,<package-label>PRESENTIF<condition-definition>]*;

]

[PARAMETERS <parameter-label>[,<parameter-label>]*;

]

REGISTRETED AS object-identifier;

Example of a class

exampleObjectClass MANAGED OBJECT CLASS

DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992" : top;

CHARACTERIZED BY

examplePackage2 CONDITIONAL PACKAGE

examplePackage1 PACKAGE

ACTIONS qOSResetAction;

NOTIFICATION communicationError ;

REGISTRED AS {joint-iso-ccitt ms(9) smi(3) part4(4)package(4)examplepack1(0)};

PRESENT IF !conformance class 2 of underlying ressource implemented as descriptor in ISO/IEC xxxx! ;

REGISTRED AS {joint-iso-ccitt ms(9) smi(3) part4(4)managedObjectClass(3)exampleclass(0)} ;

The information model Description of objects

• Definition of information

- List of generic objects - TOP- DISCRIMINATOR- ...

- List of object classes specific to some functions- SUMMURIZATION REQUEST OBJECT- ...

- List of attributes types - COUNTERS- THRESHOLDS- ...

- List of operations, notifications, ...

Description tool

• ASN.1 (Abstract Syntax Notation 1)– It is a language defined by its grammar (cf ISO 8824)

– A grammar is a set of production rules

• The role of ASN.1– 1 Description of data structures

– 2 Allow transmission of these structures through the ISO stack

• Utilization mode – 1 describe objects in ASN.1 (following the formalism of GDMO templates)

– 2 use a "compiler" towards the development language (C, ADA, Pascal, ...) to generate :

* adapted data structures

* encoding rules to the transfer syntax

Thus, encoded ASN.1 will be transferred through the network.

The use of ASN.1

Entity A Entity B

transfert syntaxe

DescriptionASN1

data structure data structure

Encoding/decodingrules

Naming

• The containment tree– defines notions of contained and containing classes

– defines constraints for the naming process

• Naming tree– respects constraints of the registration tree

– defines a global name for each object

the Global Distinguished Name (GDN)

– allows the use of “local” names

Distinguished Name

Four trees

• Inheritance tree: properties of classes

• Containment tree: containment constraints for the naming process (defined within classes)

• Naming tree: for identification of objects (or instances)

• Registration tree: to reference classes (or constituents of classes, e.g. templates)

The inheritance tree

modem

boardswitchX25LAN

network equipment

top

The containment tree

root

network

equipment

The naming tree

station X station Y station Z station X station Z

LAN 1 routeur 1 network B LAN 2

network A

root

Name of objects :"networkA, LAN1, stationX""networkA, LAN2, stationX"

The registration tree

root (world)

ccitt iso joint-iso-ccitt

std reg member org authority body

dod

internet

directory mgmt experimental private

entreprises

reserved proteon ibm hp

021

01 2

3

6

1

12 3 4

1

01 2 11

MIB-1 MIB-2

1 2

Important remarks

All object classes must be registered by a competent authority.

The conformity will be verified using the MOCS (Management Objects Conformance Statements)

The standardization process does nor provide any help for the conception of the object model.

A set of generic object libraries are provided. These objects need to be extended (by the inheritance process).

The object TOPtop MANAGED OBJECT CLASS

CHARACTERIZED BY topPackage PACKAGE

BEHAVIOUR topBehaviour;

ObjectClass GET,

nameBinding GET;;;

CONDITIONAL PACKAGES packagesPAckage PACKAGE

ATTRIBUTES packages GET;

REGISTERED AS {smi2Package 16};

PRESENT IF "any REGISTERED package, other than this package has been instancied",

allamorphicPackage PACKAGE

ATTRIBUTES allomorphs GET;

REGISTERED AS {Smi2Package 17};

PRESENT IF "if an object supports allomorphism";

REGISTERED AS {smi2MObjectClass 14};

topBehaviour BEHAVIOUR DEFINED AS "This is the top level of managed object class hierarchy and every other managed objet class is a specialization of either this generic class (top) or a specialization of a subclass of top..."

Example : system object

system MANAGED OBJECT CLASS

DERIVED FROM top;

CHARACTERIZED BY

systemPackage PACKAGE

ATTRIBUTES systemId GET,

systemTitle GET,

operationalState GET,

usageState GET,

administrativeState GET-REPLACE;;;

CONDITIONAL PACKAGES

administrativeStatePackage PACKAGE

ATTRIBUTES administratoveState GET-REPLACE;

REGISTERED AS {smi2Package14};

PRESENT IF "an instance supports it",

....

The functional model

• Definition of 5 management domains

• Definition of SMFsSystem Management Functions

SMF : System Management Functions

• Objective :

Specification of management interfaces, based on the manager/agent model.

• Means :

Two aspects are necessary :

- the object model (managed resources , their properties, relations, operations)

- the accesses to the objects (access control , selections, coordination of elementary operation , timing...)

• Definition :

A SMF is a standard which describes object classes or properties of objets that can be used to perform management functions. It standardizes the protocol aspects of these services.

SMF : System Management Functions (continued)

• Content : three aspects- semantics of the properties and/or support objects

example : alarm types

objects Log, LogRecord

- description of the access services to these basic properties (procedures)

example : mapping on the services of CMISE

- syntax to support these definitions (GDMO templates and ASN.1 production rules )

• Relations between SMF's

A SMF can use the services defined in other SMF's

SMF : System Management Functions (continued)

• Functional units - A SMFU defines a set of properties (management services) that objects of a system can offer to a manager using an association. They can be negotiated when initializing the association.

- Example:

The object management defines two SMFU's :

- operations services

- notification services

The log management defines one SMFU

The states management does not defines a SMFU (cannot be negotiated )

• Remark :- A SMF is not a function in itself. The services described by a SMF are introduced to be integrated in a management interface. They can be used by objects from different classes.

SFM’s principle

Object

Management Interface

(CMISE)

SFM’s principleObject

Managementinterface(CMISE)

object

SMF Interface(enriched)

List of the SMF

Object Managt Function IS Workload Monitoring Function DIS

State Managt Function IS Test Management Function DIS

Attributes for Relationships IS Summarization Function CD

Alarm reporting IS Confidence and Diagnostic Test CD

Event Report Function IS Time Management WD

Log Control Function IS OSI software Management WD

Security Alarm Reporting Funct. IS

Security Audit trail Function DIS

Objects and Attributes for Access CD

Accounting Meter Function CD

Scheduling Function WD

Response Time Monitoring

Event Report Get Set Action

Create DeleteCancel-Get

ObjectManagement

StateManagement

RelationshipManagement

Alarmreporting

Event-reportmanagement

Logcontrol

Security-alarmreporting

Securityaudit trail

Accesscontrol

Accountingmeter

Workloadmonitoring

Testmanagement

Summarization

Faultmanagement

Accountingmanagement

Configurationmanagement

Performancemanagement

Securitymanagement

Specific Management Functions

State Management Function

• Attributes- Management attributes

* Operational state In service

Out of service

* Utilization state Free (non used)

Active (usable)

Occupied (not usable any more)

Unknown (from the object)

* Administrative state Blocked (by the manager)

Unblocked ( " )

Becoming free

- Maintenance attributes (STATUS)

* Repair status (in repair, alarm..)

* Installation status (being installed)

* Availability status (in test, out of service, out of tension...)

* Control status (reserved, suspended...)

State Management Function (continued)

• Notifications- State Change notification

with parameters :

state change info (state attribute)

additional state change info

• Object

- state change record

Specialization of the class "Event Log Record" with notification parameters (above)

• Offered services - State Change Reporting Service M-EVENT-REPORT

- State attribute read PT-GET

- State Attribute Modify PT-GET

CMISE/CMIP

• CMISE services– Interactions with object interfaces

(read, write, creation, instances destruction, ...)

– Utilization of naming principles

– Multiple object selection

– Multiples actions (atomicity)

CMISE(Common management Information

Service Element)

CMISE services

They are classified in two categories:

• the operation services : invocation of requests sent to an agent (concerning objects managed by this agent),

• a notification service : transmission by an agent of a report containing a notification emitted by an object.

CMISE services (continued)

Operation/notification Service Mode

Get attribute value M-GET confirmed

M-CANCEL-GET confirmed

Replace attribute value

Replace with default value

Add member M-SET conf/non-conf

Remove member

Create M-CREATE confirmed

Delete M-DELETE confirmed

Action M-ACTION conf/non-conf

Notification M-EVENT-REPORT conf/non-conf

(Common management InformationService Element)

CMISE services: M-CREATE

• Specific parameters

- superior object instance

- reference object instance

• Service

- naming : ie definition of the GDN (Global Distinguished Name)

--> choice of the superior in the naming

choice of the RDN (Relative Distinguished Name)

Example : M_CREATE

- M-CREATE uses 3 specific parameters:

- MOC (Managed object Class) - its class

- MOI (Managed Object Instance) - its GDN

- SOI (Superior Object Instance) - the GDN of the superior

- The manager has three options : it can send

- MOC and MOI

- MOC and SOI

- MOC

- In any case, the agent will return MOC and MOI

- Valorization of attributes

The values given to attributes have higher priorities than the default values of the class or the values of a referenced object.

Multiple object selection

-1

-2

-3

ScopingFiltering(attributes values)

CMIP

• ISO layer 7 protocol

• Supports remote CMISE operations

• Is integrated in an association (cf ACSE)– negotiation of the association (partners, functional units , ...)

– closure of the association

• Is built on ROSE services(remote operation invocation)

Implementations

• Normaly : on ISO stack (layers 1 to 6)

• Possible on TCP stack (CMOT)

• Possibly on LLC (with adaptations), and CMOL or LMMP

Standards

• The object oriented approach• The OSI standards

• SNMP

Network Management within Internet

• An organizational scheme

• An information system

• A protocol

• But :– no functional aspect

– no object oriented approach

– simplified mechanisms (naming, ...)

The model

Three components in the network management model :

• several managed nodes. One agent in each one. • one or several Network Management Stations (or NMS)• a protocol for the exchange of management information

The "Internet-standard Network Management Framework" describes the basic principles of the Internet network management

The managed nodesthree types are possible:• host system (work station , server, printer...)• gateway• transmission medium (bridge, multiplexer...)Architecture

MANAGEMENT PROTOCOL

"USEFUL"

PROTOCOLS

Network

Instrumen-tation

The management stations

• They are host systems containing :- the network management protocol

- the management applications

• Remark : a management station takes care of several nodes, but a node may be managed by several management stations.

• The model is thus of the type «Manager - Agent» (client-server)

The management protocol

• Each node is maintaining a set of "variables". Reading these variables allows to supervise the network. Writing these variables allows the control of the mechanisms.

• Besides the reading and writing operations , two additional mechanisms are provided :

– the transversal operation to learn about implemented parameters

– the trap operation, for fault signaling

• It is possible to manage a node not implementing the Internet stacks using a "Proxy"

The information system

Data description A sub-set of ASN.1 is used by the "management framework" In particular, only 4 kinds of data types can be used :- INTEGER a data type that can only take integer values example :Status ::=

INTEGER { up(1), down(2), testing(3)}myStatus Status ::= up -- or 1- OCTET STRING a series of de 0 or more octets (values from 0 to 255).- OBJECT IDENTIFIER a type to reference a registered object (by a competent authority). It is a series of numbers, referencing the registration tree.- NULL

Definition of managed objects

OBJECT-TYPE MACRO ::= BEGIN

TYPE NOTATION::= "SYNTAX" type (ObjectSyntax)

"ACCESS" Access

"STATUS" Status

Access::= "read-only"

| "read-write"

| "write-only"

| "not-accessible"

Status ::= "mandatory"

| "optional"

| "obsolete"

| "deprecated"

Description ::= value (description DisplayString)

VALUE NOTATION::= value (VALUE ObjectName)

END

Definition of managed objects

Example :

sysDescr OBJECT-TYPE

SYNTAX OCTET STRING

ACCESS read-only

STATUS mandadory

::= { system 1 }

The information system

2 types of structured data :

• list :

<list>::= SEQUENCE { <type1>, . . ., <typeN>}

where <type> are simple types

• table :

<table>::= SEQUENCE OF <list>

Only 2 dimensions tables are authorized.

Registration

iso(1)

org(3)

dod(6)

...

...

... internet(1)

directory(1) mgmt(2) experimental(3) private(4)

Objects must be registered. Internet prefix :

internet OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) 1}or : 1.3.6.1

The SNMP MIB• MIB-1 (first version)

• MIB-2group nb comment

system 7 nodes

interfaces 23 network interfaces

at 3 IP address translation

ip 38 Internet Protocol

icmp 26 Internet Control Message Protocol

tcp 19 Transmission Control Protocol

udp 7 User Datagram Protocol

egp 18 Exterior Gateway Protocol

transmission 0 transmission

snmp 30 SNMP itself

total 171

Example : the System group

system OBJECT IDENTIFIER ::= { mib 1}

sysDesc: description of the equipment

sysObjextID : agent identity

sysUpTime : duration since last start

sysContact : contact person

sysName : equipment identification

sysLocation : location

sysServices : offered services

Example : sysDescr "4BSD/ISODE SNMP"

SysObjectId 1.3.6.1.4.1.4.1.2.1

SysUpTime 45366736 (=5 days, 6h,1mn,7.36sec)

SysContact "M. Dupont <@ IP>"

SysName wp.psi.com

SysLocation "building A"

SysServices 48 (transport, application)

MIB structure and addressing

system 1.3.6.1.2.1.1

interfaces 1.3.6.1.2.1.2

at 1.3.6.1.2.1.3

ip 1.3.6.1.2.1.4

icmp 1.3.6.1.2.1.5

tcp 1.3.6.1.2.1.6

udp 1.3.6.1.2.1.7

egp 1.3.6.1.2.1.8

cmot 1.3.6.1.2.1.9

transmission 1.3.6.1.2.1.10

snmp 1.3.6.1.2.1.11

MIB II - interface groupifAdminStatus administrative state (up/down/test)

ifOperStatus operationnal state (idem)

ifLastChange date of last operationnal change

ifDescr interface’s name

ifType type

ifMtu maxi Nr of datagramme

ifIndex a unique value for each interface

idfSpeed throughput

ifInDiscard nr of rejected packets in input

ifOutDiscard id in output

ifInErrors nr of packets in error in imput

ifOuterrors id in output

ifInOctets nr of octets received

ifOutOctets nr of octets sent

...

ifInUnknownProtos nr of received packets with unknown protocol

ifOutQlen nr of packets in the output queue

MIB II - IP groupipRouteTable IP routing table

ipNetToMediaTable address translation table

ipForwarding if the equipment can forward

ipAddrTable IP adresse

ipInReceives nr of datagrammes (input)

ipInHdrErrors nr of packets with header error

ipInAddrErrors nr of packets with address error

ipForwDatagrammes nr of forwarded datagrammes

ipInUnknownProtos nr of input datag. with protocol error

ipInDiscards nr of discarded datagrammes (input)

ipInDelivers nr of datagrammes (input)

ipOutRequests nr of datagrammes (output)

ipOutDiscards nr of rejected datagrammes (output)

...

ipFragFails nr of failed fragmentations

ipFragCreates nr of generated fragments

Protocol mechanisms

• Authentication

• Authorization (access policy)

• Objets identification

• Internal mechanisms

Authentication

• A SNMP message contains two parts :- a community name. It must be known from receiving entity to validate the message.

- data, with an operation and operands

• Each community name :– is verified for each message

– is correlated with rights (read - write)

– «sees» a sub-set of the MIB

Authorisation

• Each community defines an access mode that can be read-only or read-write for all the objects belonging to the community (the view).

• The intersection of the access mode and object's characteristics determines the authorization :

access mode read-only read-write write-only not-accessible

read-only 3 3 1 1

read-write 3 2 4 1

where classes are defined as follows :1 no right 3 get, get-next, trap

2 get, get-next, set, trap 4 get, get-next, set, trap ** used by specific implementations

Object's identification

• Each object is identified by its OID, followed by a suffix:– 0 for a simple variable (not in a table)

– a not null value if not

• Variables inside an agent can be classified (lexicographical order),

• The naming mechanism is not explicit:

variable = - the agent (IP address , port Nr )

- OID

- suffix

SNMP behaviour

SNMP is an asynchronous request/answer protocol .Four kinds of interactions are possible :

1- the manager sends a get-request; the agent answers by a get-response.2- the manager sends a get-next-request; the agent answers by a get-response.3- the manager sends a set-request; the agent answers by a get-response4- the agent sends a trap message.

SNMP behaviour

Each SNMP message (except traps) contains :

- a request identifier

- a list of variable bindings (names and values)

- a field for error types (tooBig, noSuchName, badValue, readOnly, genErr)

- an error index (number of the faulty variable).

SNMP Version Number

Community Name

Request -id

error status

error index

variable binding

name1 value1 name2 value2 ....... namen valuen

Variable Binding

PDUtype

The get-next operation• This operation has been designed to allow to receive as

answer the value of the object immediately following the object named in the request (referring to the community's view)..

• The answer will give the name of the next object and its value.

• Why to use this instruction ?– to know if an object is managed by an agent– to "traverse" a table without knowing its size– to "traverse" completely a MIB (the last request will be followed by a "

noSuchName").

example : reading of a routing tableget-next (ipRouteDest) -> ipRouteDest.0.0.0.0

get-next (ipRouteDest.0.0.0.0) -> ipRouteDest.192.33.4.0

get-next (ipRouteDest.192.33.4.0) -> ipRouteIfIndex.0.0.0.0

The TRAP

The trap operation is used by an agent to inform a manager of events.

The syntax of the trap is different from the other messages. The fields are:

– PDU type– agent's identification (enterprise)

– its address

– the kind of generic trap

– specific field for non-generic traps

– the time of the event

– a list of variables containing information concerning the trapversion community PDUtype

enterprise agent-addr specific-trapgeneric-trap time-stampvariablebindings

MIB's extensions

• A number of MIBs has been created for various areas :

– X25

– LAN

– FDDI

– printers

– ...

The list of the RFCs can be consulted

• A particular MIB : RMONIt allows to extend the possibilities of the protocol

The MIB RMON

The management of probes

– off line operations

– preemptive monitoring

– problem detection and alarms

– value added data

– multiple managers

MIB's structure

• The Statistics group• The History group• The Alarm group• The Host group• The HostTopN group• The Matrix group• The Filter group• The Packet Capture group• The Event group

Control mechanisms

It is based on tables containing entries

- control tables : to define operations- data tables : for recording results

+ the status variable + the "owner" variable

The "owner" variableRFC1271 - MIB DEFINITIONS ::= BEGIN

IMPORTS

Counter FROM RF11555-SMI

DisplayString FROM RFC1158-MIB

min-2 FROM RFC1213-MIB

OBJECT-TYPE FROM RFC-1212;

-- This MIB module uses the extended OBJECT-TYPE macro as defined in RFC1212.

-- Remote Network Monitoring MIB

rmon OBJECT IDENTIFIER ::= {mib-2 16}

-- textual conventions

OwnerString ::= DisplayStringASCII encoding is used to determine the user, who must be

identified by his name, his IP address, the station's name, location, phone number, 'monitor'

The "status" variable

EntryStatus ::= INTEGER

{ valid (1),

createRequest (2),

underCreation (3),

invalid (4) }

- invalid : the entry is not valid any more- createRequest : positioned by the manager, while the

agent is working- underCreation : positioned by the agent when action can

start - valid : positioned by the manager when the state is

"underCreation".

The statistics group

etherStatsTable OBJECT-TYPE

SYNTAX SEQUENCE OF EtherStatsEntry

ACCESS not-accessible

STATUS mandatory

DESCRIPTION "A list of Ethernet statistics entries"

::= { statistics 1 }

etherStatsEntry OBJECT-TYPE

SYNTAX EtherstatsEntry

ACCESS not-accessible

STATUS mandatory

DESCRIPTION "A collection of statistics kept for a particular Ethernet interface"

INDEX { etherStatsIndex }

::= { etherStatsTable 1 }

EtherStatsEntry ::= SEQUENCE { etherStatsIndex INTEGER (1..65535),

etherStatsDataSource OBJECT IDENTIFIER,

etherStatsDropEvents Counter,

···

etherStatsOwner OwnerString,

etherStatsStatus INTEGER }

The statistics group

etherStatsIndex OBJECT-TYPE SYNTAX INTEGER (1..65535)

ACCESS read-only

STATUS mandatory

DESCRIPTION "the value of this object uniquely identifies this etherStats entry."

::= {etherStatsEntry 1 }

···

etherStatsOwner OBJECT-TYPE

SYNTAX OwnerString

ACCESS read-write

STATUS mandatory

DESCRIPTION

"The entity that configured ths entry and is therefore using the ressources assigned to it"

::= { etherStatsEntry 20 }

etherStatsStatus OBJECT-TYPE

SYNTAX EntryStatus

ACCESS read-write

STATUS mandatory

DESCRIPTION "The status of this etherStats entry"

::= { etherStatsEntry 21 }

SNMP Vx

• SNMP V1 : full version (RFC 1157)

• SNMPsec (historic) (RFC 1351, 1353) : secured version of SNMP V1

• SNMP V2p (historic) : V1 + protocol operations, data types, party-based security (RFC 1441 and followings). This version is also called V2 classic

• SNMP V2c (experimental) (RFC 1901, 1905 and 1906). It is an update of V2p.

• SNMP V2u (experimental) (RFC 1905, 1906, 1909 and 1910). Same as SNMP V2C, except for security (based on users)

• SNMP V2* (experimental) (no RFC). Combine the best features of V2p and V2u.

• SNMP V3 (proposed)

SNMPv3: What is it?

• SNMPv2 and more:– protocol security, i.e.,

authentication/confidentiality/key management

this is the User-Based Security model

– an enhanced access-control model• based on MIB views and groups

this is the View-Based Access Control model

SNMPv3 - RFCs

• 2570 - Introduction (April ‘99)

• 2571 - Architecture

• 2572 - Message Processing/Dispatch

• 2573 - v3 applications (functional parts)

• 2574 - User-based Security Model

• 2575 - View-based Access Control Model

• 2576 - Coexistence between v1, v2 and v3

SNMP V3

Digest of the main improvements:• A manager can behave as an Agent for a manager allows manager to

manager communications)

• An agent can manage several MIBs

(by introduction of a naming process))

• Communication classesGET 1 --not used 16

GETNEXT 2 GETBULK 32

RESPONSE 4 INFORM 64

SET 8 SNMP V2 -TRAP 128

• Table manipulations (dynamic creation or deletion of rows : method “CreateAndWait”)

• Some new types (Counter32 and Counter64)

• Two new operations (Getbulk, inform)

Architectural elements

• snmpEngineID - a string that uniquely defines a manager or an agent,

• contextEngineID - id entity with a context

• contextName - parameter to access the control subsystem, represents a set of MIB objects (String)

New terms

• scopedPDU - PDU with contextEngineID, contextName

• snmpSecurityModel – v1, v2, USM (user-based) are possible

• snmpSecurityLevel– noAuthNoPriv, authNoPriv, authPriv

• principal - for whom everything is done– people ultimately, but processes in real life

• securityName - string representing the principal

SNMP V3 protocol

• Two new instructions

* GET-BULK

For multiple lectures (repetitive use of the principles of the GET-NEXT) – N 'simple' variables

– M variables leading

to R responses

* Inform

A manager can send information about a MIB to an another manager.

N M

R

Protocol overview

• Simply: v3 wrapper + v2/v1 PDU

globalheader

message security parameters

scoped PDU header

SNMP PDU

SNMPv3 partcrypto-field part

User-based Security Model

• Cryptography

• Anti-replay and time

• usmUser group

• Key management– password to hash key mechanisms– key localization– key update

View-based Access Control Model (VACM)

• Determines whether access to a managed object in a local MIB by a remote principal should be allowed,

• Makes use of a MIB that:– defines the access control policy for this agent– makes it possible for remote configuration to be

used.

Elements of the VACM model

• Groups - a group is a set of (securityModel, securityName), for whom access rights are identical

• Security level - different security levels => different access rights

• Contexts

• Mib views - collection of subtrees

• Access policies - used to enforce a particular set of access rights.

SNMP Entity

SNMP Entity

SNMP engine (identified by snmpEngineID)

DispatcherMessageProcessingSubsystem

SecuritySubsystem

AccessControl Subsystem

Application (s)

CommandGenerator

NotificationReceiver

ProxyForwarder

CommandResponder

NotificationOriginator

Other

SNMP entity (identified by snmpEngineID, example : abcd)

SNMP engine (identified by SNMPEngineID)

DispatcherMessageProcessingSubsystem

SecuritySubsystem

Access ControlSubsystem

Command Responder Application(contextEngineID, example : abcd)

example contextnames :

“bridge 1” “bridge 2” “ “ (default)

MIB instrumentation

context context context

bridge MIB bridge MIBother MIB

some MIB

SNMPv3 engine parts• Dispatcher

– interface to applications, network, and other SNMP engine parts

• Message processing– accepts/sends PDUs from/to the Dispatcher, and invokes the USM to

verify the security-related parameters

• Security subsystem– user-based security model

• Access control– view-based model

V3 Applications

• Command generator– does get/getnext/getbulk/set and processes the

received responses

• Command responder– receives get/getnext, etc., and sends the

response

• Notification receiver/originator– receives/sends traps and inform PDUs

SNMP Manager

SNMP entityNOTIFICATIONORIGINATOR

applications

NOTIFICATIONRECEIVERapplications

COMANDGENERATOR

applications

Network

UDP IPX other...

Dispatcher

PDU Dispatcher

TransportMapping

MessageDispatcher

Message Processing Subsystem

V1MP

V2cMP

V3MP

otherMP

Security subsystem

other securitymodel

User-basedsecurity model

SNMP AgentNetwork

UDP IPX other

MIB Instrumentation

COMMANDRESPONDER

application

ACCESSCONTROL

NOTIFICATIONORIGINATOR

applications

PROXYFORWARDER

applications

V1MP

V2cMP

V3MP

otherMP

Message ProcessingSubsystem

SecuritySubsystem

Othersecuritymodel

User-basedSecurityModel

Dispatcher

Transport Mapping

Message Dispatcher

PDU Dispatcher

Comparison CMIP vs SNMP

• Information system

(object orientation, inheritance, utilization of ASN.1, ...)

• Protocol mechanisms

(filtering vs pooling; dynamic creation, ...)

• Addressing

(naming vs simple mechanisms)

• Manager to manager dialogues

Attention : a CMIP manager is simpler than a SNMP manager

SNMP vs CMIP

INTERNET ISO

Cost perelement

Relatively inexpensive to implement sinceSNMP, UDP & IP have low to zerolicence fees, and the code is small. Publicdomain implementations are available

More expensive to implement due toadditional resources (memory,processors, etc.) required.

Scalability

Polling used by most SNMP-basedmanagement systems requires carefultuning in large networks to avoidexcessive bandwidth consumption.Simplicity of SNMP agents does notprovide strong built-in support tomanager-manager interfaces.

Event or ientation of most CMIP-basedmanagement systems allows scaling inlarge networks using built-in services.Distr ibution of load between manager andagent can be used to support manager-manager interfaces.

Element to EMSbandwidth

Excessive polling for many MIB variablescan result in high bendwidth consumption.Effective pollong strategies and use oflocal proxies can reduce bandwidthrequirements.

Excessive event generation and longermessages can result in high bandwidthconsumption. Buit-in logging and eventfilter ing services can be used to reducebandwidth requirements.

Lights out localintelligence

Most agents are relatively simple andtherefore offer little self-managementcapability

Increased complexity of agents can beused as the basis for self-managementcapability

Elementintelligence

SNMP agents are intended to be simple.Arbitrary complexity to the agents can beadded by extending the MIB in theEnterprise and Extension areas

CMIP agents are expected to do eventfilter ing, and to accept action commandsas defined in the object definitions.

SNMP vs CMIPINTERNET ISO

Security ofmanagement

Secure SNMP offers authentification andaccess control, including a securityviolation alarm.

CMIP offers authentification and accesscontrol, with a full set of security alarmsand a security audit trail service.

Redundancy ofmanagement

SNMP agents implementations may sendtraps to multiple managers. SNMP useslocal naming that is relative to an agentsystem and requires additionalinformation to make local names globallyunique.

CMIP offers a management service tocontrol event forwarding and loggingwhich may be distr ibuted to multipledestinations. CMIP uses global X500 stylenaming to facilitate manager-managerdistr ibution.

Communicationreliability

Typically used over a connectionlessdatagram protocol which does not ensurereliability. This puts the burden on themanager application to detect and recoverfrom lost requests. Since SNMP traps arenot acknowledged, there is no way todetect or recover from lost trap aler ts.

Must be used over a connection whichensured reliable data transport. Thisplaces the burden for loss detection andrecovery on the underlying transport, noton the manager or agent. CMIP is stillvulnerable to connection loss whennetwork conditions are bad, however.

Installed baseSNMP has great popular ity and thousandsof agents fave been deployed, particular lyin the distr ibuted LAN area

CMIP implementations are just enter ingservice

Standardmanagementapplications

The best SNMP managers on the marketprovide fault, configuration andperformance applications. Many of thesecan support custom extensions,and/orseamlessly incorporate vendor-specific applications.

Vendors of integrating systems andapplications provide configuration andfaults management applications.Performance applications are emerging

SNMP vs CMIP

INTERNET ISO

ExtensibilityExtensibility is provided through newMIBs and MIB II extensions ine theEnterprise and Extension areas.

Object classes used with CMIP may bedesigned using extensibility mechanismssuch as inheritance, specialization andallomorphism. Thses mechanisms allowexisting classes to be refined for extension,promoting reuse of existingimplementations ans seamless integrationof new features.

Backbonetransportprotocols

Typically used over UDP, can also be usedover TCP. Below the transport layerusually employed over Internet IP, butmay also be used over OSI, Appeltalk,NetWare IPX, etc.

Typically used over a full OSI stack, canalso be used over TCP/IP by employingRFC 1006 to map OSI transport to TCP.Also may be used over LANs byemploying IEEE 802.1B to map to LLC

Designcomplexity

See also cost. Simple and low cost designsare possible.

CMIP agents and their supporting objectsrequire a rigorous design approach usingobject oriented methodology

Automateddiscovery

Automatic discovery is possible through anumber os mechanisms, with additionalinformation via SNMP-walkingtechniques. Secure SNMP may make thesetechniques obsolete.

OMNIPoint 1 provides sharedmanagement knowledge services forCMIP management systems which enablesmanagers to discover agent capabilitiesand objects.

Comparison

CMIP SNMP V1 SNMP V3 RMON

complexity ofagent

high low low high

dissemination low high low(increasing)

medium

security high low as requested low

complexity ofmanager

medium high high medium

distributedarchitecture

yes no yes no

complexity ofAPI

high low low medium