Next: 3.2 Requirements Analysis
Up: 3 Managing Management Systems
Previous: 3 Managing Management Systems
The way how MSs are deployed today is by establishing well-defined,
central points of control, termed management platforms. As
outlined in several publications (e.g. [3], [22]),
platforms tend to become bottlenecks in large networks and a solution
to this problem is to distribute their functionality (e.g., topology
functions, event filtering mechanisms, logging facilities) in order to
reduce the load on the central MS. This can be done by introducing
MSs acting in the role of Mid-Level Managers (MLMs) that are
located closer to the managed resources and execute management
functions on behalf of other MSs. Their main purpose is to condense
raw data stemming from the resources into meaningful management
information that can then be used by another MS. This may also include
caching of frequently accessed information like topology data of the
underlying systems. These properties obviously reduce the amount of
overall traffic that is sent through the network for management
purposes. MLMs are an effective mechanism for structuring networks
into domains and can be used for establishing management hierarchies.
An extension of this concept is to delegate (and withdraw) management
functionality to MLMs at runtime. This delegation may either be
initiated by the MLM itself (pull model) or by another MS (push
model). The interworking between MSs of different service providers as
described in section 1 can be seen as a special case
of interactions between different MLMs. Consequently, the above
mentioned principles apply also to independent MSs operated by
different authorities.
As motivated in section 2, further complexity is
introduced by the heterogeneity of the deployed management
architectures. MGs are a convenient mechanism for achieving
interoperability between heterogeneous MSs. They are obviously located
on the boundaries of different (architectural) management domains and
act in the role of an MLM w.r.t. other MSs. As MGs are aware of the
architectural specifics of the underlying resources, it therefore
makes sense to provide them with the same management functionality as
MLMs. Such an enhanced MG could e.g., condense several SNMP-traps into
one CORBA-event instead of translating every trap into one event and
leaving the filtering of these events to the MS one level above in the
service provider hierarchy. This implies that providers need an
instrumentation for these systems in order to present a unified view
on their management data to customers; the amount of accessible
information may be specified in a service contract.
Next: 3.2 Requirements Analysis
Up: 3 Managing Management Systems
Previous: 3 Managing Management Systems
Copyright Munich Network Management Team