![](https://csdnimg.cn/release/download_crawler_static/2297286/bg10.jpg)
Document:
FP7-ICT-2007-1-216041-4WARD/D-4.1
Date:
2009-04-02
Security:
Public
Status:
Final
Version:
2.0
4WARD PUBLIC INFORMATION 15(78)
Chapter 4 Key Issues for In-Network Management
We have identified the following set of general key requirements that a holistic INM
architecture should take into account. Of course, due to time constraints within the project it
might be not possible to address all of them, thus the main part of the work will rather deeply
focus on a set of key requirements than trying to plainly touch all of them. While this
compilation is not exhaustive, it may be used as a background for assessing existing work
related to INM in
Chapter 5 and the scenario descriptions in Chapter 6 as well as a guideline
in the design of the INM framework and algorithms that follow in subsequent deliverables of
Work Package 4.
Scalability: INM must support scalability in terms of network size (i.e. the number of network
components to be managed) and in terms of the number of management tasks, which also
grows with the network size.
Heterogeneity: INM must support heterogeneity on different dimensions, such as
heterogeneous devices (different manufacturers and vendors, proprietary network
components and functionality), heterogeneous network structures (MANETs, WSNs, WMNs,
wireless access networks, hybrid network structures, etc.), and heterogeneous environments
(homes, cars, offices, open country).
Interoperability: INM relies on interoperability between different devices to support
management operations. The coexistence of different interfaces and information models
should be avoided, because it poses a serious limitation to the degree of automation in the
network.
Real-Time-Support: INM should support management operations within limited time
constraints, i.e. real time. The limits of these time constraints may be specific to every
application and refer in general to the absence of mistakes in that application due to delays in
the management operations.
Robustness: INM must be robust with respect to failures in components and subsystems,
with respect to potential attacks (security), and with respect to incomplete or inaccurate
information that is available (data collection).
Small Footprint: INM must have a small footprint with respect to storage space, bandwidth
consumption, energy consumption, and other resources, in order to impact the network to the
least extend possible and avoid side-effects.
Level of Localisation: The localisation of management tasks / control loops to a small subset
of components is a prerequisite for scalability and a small footprint. In other words, the more
localised a management application can be executed, the larger the number of management
tasks that can be executed at the same level of resource utilisation.
Level of Integration: Management tasks need to be tightly integrated within network
components and subsystems (compare to external, partially embedded (e.g. only monitoring),
and fully embedded (inseparable management capabilities in network components)).
Comprehensiveness of Management Information Model: The Information model of INM
must be comprehensive in the sense that it must provide sufficient expressiveness (to capture
various types of management tasks), extensibility with respect to future requirements (e.g.
energy management), and flexibility (e.g. only partial implementations for lightweight
management tasks).
Functional Comprehensiveness: INM must provide functional richness to support a variety
of essential management tasks (e.g. fault detection and remedy), it must be possible to
specify tasks on different levels of abstraction (Æ degree of specification of a task, see
[MartinFlatinEtAl1999a]), and allow tasks to be translated to concrete implementations in
different environments (e.g. WSNs, WMNs).