Transcript 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
• Definition
It 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 :
- financial area :
- organizational area:
- security area :
quality of service
continuity of service
truth of the prices
control of the structure and
evolutions
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
homogeneous networks
separated networks
--->
--->
--->
• Evolution of network utilization
– generalization to all kind of personal
– opening to external clients or people
– multiplicity of services
distributed networks
heterogeneous networks
integrated networks
Networks elements in a corporate
network
• Multiplicity of kinds of equipment
communication 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
Integrated networks
Computer networks
Data
LAN
ATM
Voice
Functional domain
Alcatel
Bull
IBM
TRT
Matra
SAT
manufacturers
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
– very different ergonomics
– functional limitations
(faults, performance)
– communication difficulties
– A few intelligence in systems
persons
--> partial visions
--> problems of qualification of
people
--> partial control of networks
--> partial and local visions
multiplicity of work stations
--> necessity of highly qualified
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
Other
management
systems
Integrator machine
Integrator machine
(PNO)
Integrator machine
EMS
Agent
Agent
EMS
EMS
Agent
Agent
Agent
Agent
Agent
Agent
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 functions
real 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 functions
areas 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 management
Real 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 management
Differed 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
real time management
corrective actions
observation of network
problem detection
hours
days
day to day
management
configuration
security
maintenance
statistics (performance, traffic)
programmed operations
installations
Time scales
weeks
months
operation management
financial management
corrective management
purchases
billing
re-dimension
modifications (routings, ...)
year
short term
planning
topological evolutions
dimensioning, routings, ...
choice of support services
annual budgets
> 1 year
Strategic or
long term planning
strategic decisions
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
I
N
T
E
R
F
A
C
E
METHODS
FIELDS
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
• Fields
• Methods
Article
reference
designation
priceHT (excluding VAT)
quantity
PriceTTC (): return (1.186 * priceHT)
transportPrice (): return (0.05 * priceHT)
retire (q)
quantity <---- quantity - q
add (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
30341
kimono
495.00
1000
Article
reference
designation
priceHT
60021
portable TV
2480.00
100
quantity
Instance of
priceTTC
transportPrice
retire
add
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
• Class
clothes
• Superclass
Article
• Instance variables
size
color
• Methods
• Classe
ArticleDeLuxe
• Superclass
Article
• Instance variable
• Methods
priceTTC () :
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
reference
designation
priceHT
quantity
prixTTC
transportPrice
retire
add
ElectroMénager
guaranty
weight
Aspirator
noiceLevel
throughput
ArticleDeLuxe
priceTTC
Téléviseur
typetube
screenwidth
FreshCaviar
origin
weight
Clothes
color
size
Shirt
shape
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
Article
Alimélectrique
référence
désignation
prixHT
quantité
retirer
ajouter
voltage
impédence
puissance
consommation
Transport
typeemballage
datelivraison
prixtransport
Périssable
Fragile
température
prixtransport
Electroménager
duréegarantie
poids
validitégarantie
Aspirateur
niveausonore
rayonaction
débit
dépression
Articledeluxe
prixTTC
Téléviseur
typetube
largeurécran
télécommande
Caviarfrais
provenance
poids
prixtransport
Crèmerie
datelimite
Œufs
provenance
Vêtement
coloris
taille
Chemise
typecol
typemanches
nbpoches
Relation «is a»
OBJET
Article
référence
désignation
prixHT
quantité
prixTTC
retirer
ajouter
Transport
typeemballage
datelivraison
prixtransport
Fragile
prixtransport
Périssable
température
prixtransport
Electroménager
duréegarantie
poids
validitégarantie
Articledeluxe
Aspirateur
niveausonore
rayonaction
débit
dépression
Téléviseur
typetube
largeurécran
télécommande
prixTTC
Chemise
typecol
typemanches
nbpoches
Vêtement
coloris
taille
Caviarfrais
provenance
poids
Crèmerie
datelimite
Œufs
provenance
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.
D M
D
E
DM
C
BM
CM
BM
BM
CM
A
1: no conflict
A
A
2: conflict between B and C 3: conflict between B and C
• So there may be a conflict!
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
A
B
Objects
C
D
E
Lightings
Object in NM
Interface
Element
Object
Object in NM
Interface
Old
appli
new
appli
Object
New
element
New
characteristics
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
Standardization
The 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 model
ISO 7298
General framework
ISO 7498-4
General overview
ISO 10040
- Configuration management
- Fault management
- Performance management
- Accounting
- Security management
Definition of the specific
management functions
ISO 10164 : 1 à n
CMIP
Common Management
information Protocol
Structure of the
Management Information
Base
ISO 10165 - 1
Generic definitions
of objets and their
attributes
ISO 10165 - 2
CMIS
ISO 9595
Framework for
objects definitions
ISO 10165 - 4
Definition of specific
managed objects
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
Managed
System
Management
System
Management
process
Functions
Agent
process
D
CMISE
CMIP
CMISE
Managed
objects
Management of objects
Attributes
Operation
Notification
Managed object
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, and
the 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
Description
ASN1
data structure
data structure
Entity A
Entity B
Encoding/decoding
rules
transfert syntaxe
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
top
network
LAN
X25
equipment
switch
board
modem
The containment tree
root
net work
equipment
The naming tree
r oot
ne t wo r k A
LA N 1
st at i o n X
r o ut e ur 1
st at i o n Y
Name of objects :
"networkA, LAN1, stationX"
"networkA, LAN2, stationX"
ne t wo r k B
st at i o n Z
LA N 2
st at i o n X
st at i o n Z
The registration tree
root (world)
0
1
ccitt
2
joint-iso-ccitt
iso
0
std
1
member
body
reg
authority
2
org
3
6
dod
1
internet
1
2
3
directory mgmt experimental private
1
MIB-1
4
1
2
entreprises
MIB-2
0
1
reserved proteon ibm
11
2
hp
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 TOP
top
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 SMFs
System 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
Management
Interface
(CMISE)
Object
SFM’s principle
Object
Management
interface
(CMISE)
SMF Interface
(enriched)
object
List of the SMF
Object Managt Function IS
State Managt Function
IS
Attributes for Relationships IS
Alarm reporting
IS
Event Report Function
IS
Log Control Function
IS
Security Alarm Reporting Funct.
Security Audit trail Function
Objects and Attributes for Access
Accounting Meter Function
Scheduling Function
WD
Response Time Monitoring
Workload Monitoring Function
Test Management Function
Summarization Function
Confidence and Diagnostic Test
Time Management
OSI software Management
IS
DIS
CD
CD
DIS
DIS
CD
CD
WD
WD
Fault
management
Accounting
management
Object
Management
Event-report
management
Configuration
management
State
Management
Log
control
Accounting
meter
Performance
management
Relationship
Management
Security-alarm
reporting
Workload
monitoring
Security
management
Alarm
reporting
Security
audit trail
Test
management
Access
control
Summarization
Specific Management Functions
Event Report
Get
Create
Set
Delete
Action
Cancel-Get
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
- State attribute read
- State Attribute Modify
M-EVENT-REPORT
PT-GET
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
Get attribute value
Replace attribute value
Replace with default value
Add member
Remove member
Create
Delete
Action
Notification
Service
M-GET
M-CANCEL-GET
M-SET
M-CREATE
M-DELETE
M-ACTION
M-EVENT-REPORT
Mode
confirmed
confirmed
conf/non-conf
confirmed
confirmed
conf/non-conf
conf/non-conf
(Common management Information
Service 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
Filtering
(attributes values)
Scoping
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 nodes
three types are possible:
• host system (work station , server, printer...)
• gateway
• transmission medium (bridge, multiplexer...)
Architecture
MANAGEMENT PROTOCOL
"USEFUL"
InstrumenPROTOCOLS
Network
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
Objects must be registered. Internet prefix :
internet OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) 1}
or : 1.3.6.1
iso(1)
...
org(3)
dod(6)
...
directory(1) mgmt(2)
...
internet(1)
experimental(3) private(4)
The SNMP MIB
• MIB-1 (first version)
• MIB-2
group
system
interfaces
at
ip
icmp
nb
7
23
3
38
26
comment
nodes
network interfaces
IP address translation
Internet Protocol
Internet Control Message Protocol
tcp
udp
egp
transmission
19
7
18
0
Transmission Control Protocol
User Datagram Protocol
Exterior Gateway Protocol
transmission
snmp
total
30
171
SNMP itself
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
interfaces
at
ip
icmp
tcp
udp
egp
cmot
transmission
snmp
1.3.6.1.2.1.1
1.3.6.1.2.1.2
1.3.6.1.2.1.3
1.3.6.1.2.1.4
1.3.6.1.2.1.5
1.3.6.1.2.1.6
1.3.6.1.2.1.7
1.3.6.1.2.1.8
1.3.6.1.2.1.9
1.3.6.1.2.1.10
1.3.6.1.2.1.11
MIB II - interface group
ifAdminStatus
ifOperStatus
ifLastChange
administrative state (up/down/test)
operationnal state (idem)
date of last operationnal change
ifDescr
ifType
ifMtu
ifIndex
idfSpeed
ifInDiscard
ifOutDiscard
ifInErrors
ifOuterrors
ifInOctets
ifOutOctets
...
ifInUnknownProtos
interface’s name
type
maxi Nr of datagramme
a unique value for each interface
throughput
nr of rejected packets in input
id
in output
nr of packets in error in imput
id in output
nr of octets received
nr of octets sent
ifOutQlen
nr of received packets with unknown
protocol
nr of packets in the output queue
MIB II - IP group
ipRouteTable
ipNetToMediaTable
IP routing table
address translation table
ipForwarding
ipAddrTable
if the equipment can forward
IP adresse
ipInReceives
ipInHdrErrors
ipInAddrErrors
ipForwDatagrammes
ipInUnknownProtos
ipInDiscards
ipInDelivers
ipOutRequests
ipOutDiscards
...
ipFragFails
ipFragCreates
nr
nr
nr
nr
nr
nr
nr
nr
nr
of
of
of
of
of
of
of
of
of
datagrammes (input)
packets with header error
packets with address error
forwarded datagrammes
input datag. with protocol error
discarded datagrammes (input)
datagrammes (input)
datagrammes (output)
rejected datagrammes (output)
nr of failed fragmentations
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
read-only
3
3
read-write write-only not-accessible
3
1
1
2
4
1
where classes are defined as follows :
1
no right
3
2
get, get-next, set, trap
4
* used by specific implementations
get, get-next, trap
get, get-next, set, trap *
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-response
4- 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 Community
Version
Number Name
name1 value1
PDU
type
Request error
status
-id
name2 value2 .......
Variable Binding
error
index
variable
binding
namen valuen
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 table
get-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:
version
– 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 trap
community PDU enterprise agent-addr generic-trap specific-trap time-stamp
type
variable
bindings
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 : RMON
It 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" variable
RFC1271 - 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 ::= DisplayString
ASCII 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
etherStatsDataSource
etherStatsDropEvents
···
etherStatsOwner
etherStatsStatus
INTEGER (1..65535),
OBJECT IDENTIFIER,
Counter,
OwnerString,
INTEGER }
The statistics group
etherStatsIndex
OBJECT-TYPE
DESCRIPTION "the
etherStats entry."
value
SYNTAX
ACCESS
STATUS
of this
object
INTEGER (1..65535)
read-only
mandatory
uniquely identifies this
::= {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, partybased 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 classes
GET
GETNEXT
RESPONSE
SET
1
2
4
8
--not used
GETBULK
INFORM 64
SNMP V2 -TRAP
16
32
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
M
– N 'simple' variables
– M variables leading
to R responses
* Inform
A manager can send information about a MIB to an
another manager.
R
Protocol overview
• Simply: v3 wrapper + v2/v1 PDU
global message security
scoped
parameters
header
PDU header
SNMP PDU
SNMPv3 part
crypto-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)
Dispatcher
Message
Processing
Subsystem
Security
Subsystem
Access
Control
Subsystem
Application (s)
Command
Generator
Command
Responder
Notification
Receiver
Notification
Originator
Proxy
Forwarder
Other
SNMP entity (identified by snmpEngineID, example : abcd)
SNMP engine (identified by SNMPEngineID)
Dispatcher
Message
Processing
Subsystem
Access
Control
Subsystem
Security
Subsystem
Command Responder Application
(contextEngineID, example : abcd)
example contextnames :
“bridge 1”
“bridge 2”
“ “ (default)
MIB instrumentation
context
bridge MIB
context
bridge MIB
context
other 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 entity
NOTIFICATION
ORIGINATOR
applications
NOTIFICATION
RECEIVER
applications
COMAND
GENERATOR
applications
Message Processing Subsystem
Dispatcher
PDU Dispatcher
V1MP
Message
Dispatcher
V2cMP
Security subsystem
other security
model
V3MP
Transport
Mapping
UDP
otherMP
IPX
Networ
k
...
other
User-based
security model
SNMP Agent
Network
UDP
IPX
other
Message Processing
Subsystem
Dispatcher
Security
Subsystem
V1MP
Transport
Mapping
V2cMP
Message
Dispatcher
V3MP
otherMP
PDU Dispatcher
COMMAND
RESPONDER
application
ACCESS
CONTROL
MIB Instrumentation
NOTIFICATION
ORIGINATOR
applications
Other
security
model
User-based
Security
Model
PROXY
FORWARDER
applications
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
Cost per
element
Scalability
ISO
Relatively inexpensive to implement since
SNMP, UDP & IP have low to zer o
licence fees, and the code is small. Public
domain implementations ar e available
Mor e expensive to implement due to
additional r esour ces (memor y,
pr ocessor s, etc.) r equir ed.
Polling used by most SNMP-based
management systems r equir es car eful
tuning in lar ge networ ks to avoid
excessive bandwidth consumption.
Simplicity of SNMP agents does not
pr ovide str ong built-in suppor t to
manager -manager inter faces.
Event or ientation of most CMIP-based
management systems allows scaling in
lar ge networ ks using built-in ser vices.
Distr ibution of load between manager and
agent can be used to suppor t manager manager inter faces.
Excessive polling for many MIB var iables
Element to EMS can r esult in high bendwidth consumption.
bandwidth
Effective pollong str ategies and use of
local pr oxies can r educe bandwidth
r equir ements.
Excessive event gener ation and longer
messages can r esult in high bandwidth
consumption. Buit-in logging and event
filter ing ser vices can be used to r educe
bandwidth r equir ements.
Lights out local
intelligence
Most agents ar e r elatively simple and
ther efor e offer little self-management
capability
Incr eased complexity of agents can be
used as the basis for self-management
capability
Element
intelligence
SNMP agents ar e intended to be simple.
Ar bitr ar y complexity to the agents can be
added by extending the MIB in the
Enter pr ise and Extension ar eas
CMIP agents ar e expected to do event
filter ing, and to accept action commands
as defined in the object definitions.
SNMP vs CMIP
INTERNET
Secur ity of
management
Redundancy of
management
Communication
r eliability
Installed base
Standar d
management
applications
ISO
Secur e SNMP offer s authentification and
access contr ol, including a secur ity
violation alar m.
CMIP offer s authentification and access
contr ol, with a full set of secur ity alar ms
and a secur ity audit tr ail ser vice.
SNMP agents implementations may send
tr aps to multiple manager s. SNMP uses
local naming that is r elative to an agent
system and r equir es additional
infor mation to make local names globally
unique.
CMIP offer s a management ser vice to
contr ol event for war ding and logging
which may be distr ibuted to multiple
destinations. CMIP uses global X500 style
naming to facilitate manager -manager
distr ibution.
Typically used over a connectionless
datagr am pr otocol which does not ensur e
r eliability. This puts the bur den on the
manager application to detect and r ecover
fr om lost r equests. Since SNMP tr aps ar e
not acknowledged, ther e is no way to
detect or r ecover fr om lost tr ap aler ts.
Must be used over a connection which
ensur ed r eliable data tr anspor t. This
places the bur den for loss detection and
r ecover y on the under lying tr anspor t, not
on the manager or agent. CMIP is still
vulner able to connection loss when
networ k conditions ar e bad, however .
SNMP has gr eat popular ity and thousands
of agents fave been deployed, par ticular ly
in the distr ibuted LAN ar ea
CMIP implementations ar e just enter ing
ser vice
The best SNMP manager s on the mar ket
pr ovide fault, configur ation and
per for mance applications. Many of these
can suppor t custom extensions,
and/or seamlessly incor por ate vendor specific applications.
Vendor s of integr ating systems and
applications pr ovide configur ation and
faults management applications.
Per for mance applications ar e emer ging
SNMP vs CMIP
INTERNET
Extensibility
ISO
Extensibility is provided through new Object classes used with CMIP may be
MIBs and MIB II extensions ine the designed using extensibility mechanisms
Enterprise
and
Extension
areas. such as inheritance, specialization and
allomorphism. Thses mechanisms allow
existing classes to be refined for extension,
promoting
reuse
of
existing
implementations ans seamless integration
of new features.
Backbone
transport
protocols
Typically used over UDP, can also be used
over TCP. Below the transport layer
usually employed over Internet IP, but
may also be used over OSI, Appeltalk,
NetWare IPX, etc.
Typically used over a full OSI stack, can
also be used over TCP/IP by employing
RFC 1006 to map OSI transport to TCP.
Also may be used over LANs by
employing IEEE 802.1B to map to LLC
Design
complexity
See also cost. Simple and low cost designs
are possible.
CMIP agents and their supporting objects
require a rigorous design approach using
object oriented methodology
Automated
discovery
Automatic discovery is possible through a
number os mechanisms, with additional
information via SNMP-walking
techniques. Secure SNMP may make these
techniques obsolete.
OMNIPoint 1 provides shared
management knowledge services for
CMIP management systems which enables
managers to discover agent capabilities
and objects.
Comparison
CMIP
SNMP V1
SNMP V3
RMON
complexity of
agent
dissemination
high
low
low
high
low
high
medium
security
high
low
low
(increasing)
as requested
complexity of
manager
distributed
architecture
complexity of
API
medium
high
high
medium
yes
no
yes
no
high
low
low
medium
low