![](bg2.png)
2 NETWORK MANAGEMENT
PBNM technologies have been developed to reduce
the configuration complexity of the network and its
nodes. It is desirable that a network management
system technology will be provided with the ability
to automatically manage the network configuration
based upon high-level rules, more or less in the same
way business-oriented requests are issued (Sloman
1994). In fact, policies definition aim at replacing
the dependency on vendor and device specific
configuration commands, thus making network
management a homogenous task independent of the
installed equipment. For example, a management
system should be capable, in a specific management
situation, of offering facilities to reconfigure the
whole system without the network administrator
having to worry about the configuration details of
network equipment.
The policy concept is quite wide (Moore,
Ellesson et al. 2001) – policies can be applied in
QoS management, access control, security or other
areas. Policies are defined by users, such as network
administrators or operators, stored and handled in
policy servers, and deployed on network nodes. The
execution of a policy depends on the evaluation of a
check-action rule that is activated when the implicit
condition or conditions are verified. Although the
main ideas are simple, the development and wide
adoption of policy-based management applications
have been complex. Issues such as policy format,
enforcement mechanisms, conflict avoidance, low
level protocol mapping, user-interface representation
and edition, just to name a few, are being a mater of
research and standardization. Today several
standardization organizations are working on this
subject, namely IETF and DMTF. As the result of
their work new proposals have been developed such
as COPS (Durham, Boyle et al. 2000; Chan,
Seligson et al. 2001), SNMP for Configuration
(MacFaden, Partain et al. 2003), PCIM (Moore,
Ellesson et al. 2001).
These works also stimulate the definition of the
policy framework architecture, composed of four
functional entities namely the Policy Management
Tool (Policy Console), the Policy Repository, the
Policy Decision Point or Policy Server (PDP) and
the Policy Enforcement Points (PEP) (Kosiur 2001).
This model describes the key components but it
does not prescribe any kind of implementation
details such as distribution, platform or language.
Policies and Transactions
The configuration activity and policies execution
causes state changes in network elements and it is
critical that this operation is executed atomically to
maintain the network elements in a consistent state.
PBNM systems must have mechanisms that in
case that the configuration of any equipment fails,
all the other network equipment which is involved in
that configuration must return to the last good
configuration installed.
Considering this situation, PBNM systems must
implement the ACID properties of Distributed
System theory, i.e., the applications must have the
capability of monitoring the execution of
configuration operations. If an operation would
compromise one of the ACID properties the system
must have the ability to return to the previous
configuration state (Gray and Reuter 1994;
Coulouris, Dollimore et al. 2001). We can associate
the term transaction with the term policy, i.e., we
may consider a policy as a transaction, where we
must execute all of the operations (rules –
conditions/actions) or none, in case something fails.
The definition of a transaction mechanism is also
necessary due the wide-nature of the networks, i.e.,
in large networks the time necessary to configure the
whole network, all the network elements, could be
long, running for minutes, hours or even days.
Although the network transportation protocols have
mechanisms, like “timeout” and “keep alive”
messages on COPS, to control the fault-tolerance,
this mechanisms/functions seems to be insufficient
because in certain situations the configuration effort
is too valuable to be undone.
Figure 1: Flow of the proposed fault-tolerance mechanism.
send
policy
start
examine
policy
test
policy
ok
execute
policy
undo
clean
end
start
transaction
end
transaction
not ok
ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING
524