In this chapter, we use the very high level approach of Open
Distributed Systems modeling to look at Network Management. We choose
this high level approach here, since there is
a great deal of material available on the lower level aspects of
network management. In other chapters, we have already looked more
closely at lower level, engineering aspects of other applications of
Distributed Systems. For example, network managment standards
cover the defintion of managed objects, and the standard interfaces to
management agents (or servers) through SNMP or CMIP, and using
ASN.1. Many network
management standards include mechanisms to deal with heterogeneity,
such as <#2212#> proxy<#2212#> servers and remote access to different protocols
through translating gateways such as the <#2213#>em rmon<#2213#> or remote
monitoring. What is not specified by network management standards is
precisely the nature of the distribution of funcationality. In fact,
from all the standards it would appear that a first cut at how to
build a management application would be essentially centralised.
There is a clear need for an Open Network Management Architecture.
Networks are becoming very widespread, and heterogeneous, and
it is becoming vital to control and make them useful
as they evolves.
The model of an open network that admits of multiple providers and
multiple subscribers, arbitrarily nested, provides Virtual Private Networks.
The Internet is a very good example of a VPN. Another type of VPN
commonly found is the so-called Enterprise Network, used by many large
corporations to connect together different services (ranging from
teleophony through to data) at different
sites, but drawing transmission capacity (and switching, and
possibly other services) from Public Network Operators.
There are two ways that ODP can inform network managements.
Firstly, ODP modeling can be used to design the management functions.
We look at this when applied to VPNs in the first part of this
chapter. Secondly, we can use ODP (for example through CORBA) to
implement service management directly. This has several advanatages
over simply enhancing existing network management platforms that are
based on CMIP or SNMP, espcially when applied to telecommuncaitions
networks such as the Plain Old Telephone Service or the ISDN. In
particular, the creation of new services becomes a matter for
software, and is not the tremendously complex task that it is now.
To see how hard it is in monolithic systerms, you need only look at
the compleixty of adding the simplest services in so-called
;SPM_quot;Intelligent Networks;SPM_quot; that are being slowly provided in telephone
systems - the effort to deploy something as easy as call forwarding,
or number portability across providers is astounding.
An Open Network Management Architecture (see #fn91#2214>) must address the following
requirements:
-
Flexibility
It must be flexible enough to be applied effectively to the
management of large or small communications networks that consist of a
variety of equipment types and that provide a variety of services.
It must accommodate change.
-
Extensibility
It should be able to follow trends in technology
and systems. At the simplest level, this means accommodating new
transmission technology, and new performance ranges. At the extreme, we might ask that a network management system admit of new network architectures (e.g. B-ISDN as well as OSI and TCP/IP, for example).
-
Scaling
It must scale such that it can be applied to
real systems and with realistic performance. The
design should make clear where there are limits to scaling that
constrain the applicability of particular components.
-
Interoperability and Interworking
The primary goal is to provide a framework for
network management products and services from different
suppliers to work together to manage communications and computer networks.
For example, a system from one supplier must be able to manage or be
managed by a system from a different supplier, or act in both of these roles.
An open architecture should be able to interwork with other network
management architectures if possible. In other words, it must be a
superset of all possible, sensible network architectures.
their structure.
-
Generic Model
When network management systems interoperate, it is necessary for each
system to be able to call meaningfully on the management functions supported
or required by the others, and the underlying physical or logical
components on which they operate. This is provided by an object-oriented
paradigm, and the facilities provided by <#2216#> genericity<#2216#>.
Of course, the overall system model
may differ markedly from the internal operation of any or all of the
management systems.
-
Implementation Freedom
It must not unduly put limits on the internal design or
implementation of a management system. In the commercial world,
an Open System will only gain acceptance if it also ensure that there are
always opportunities for competitive differentiation of network management
products that conform to implementors' agreements.
This objective must be balanced with the previous objectives: the
architecture must be described in enough detail to allow interoperability
and interworking, but not so much that all conformant systems must be
identical, and that a particular implementation cannot add value.
-
Performance
It should allow for stripping of all unnecessary functionality to
permit new levels of performance and simplicity.
The working definition of an Architecture (taken from the UK ANSA work[#APM##1#]) is
an engineering discipline of design with a <#2219#> common framework<#2219#> and a
consistency of style.
The following is a review and a synthesis of the description of the
functions and conceptual architecture which fully identify the
problem space.