tion protocol neutral fashion. Protocol specific
constructs for the communication protocol cho-
sen are added in the Engineering Viewpoint. The
parameters are defined in the ASN.1 language
[ASN.1].
The computational objects provide the finest
granularity of objects referenced in the mapping
to the Engineering Viewpoint.
3.2.4 The Engineering Viewpoint
TheEngineering Viewpointdescribes the ele-
ments actually chosen for distribution and in
terms that enable the introduction of a number
of distribution transparencies such as location
transparency, migration transparency, etc. The
most salient engineering constructs are the clus-
ter for co-locating sets of engineering objects
and the capsule for the allocation of clusters to
computing nodes.
The engineering viewpoint specifies operations
for specific communications protocols such as
CMIP and CORBA IIOP.
3.2.5 The Technology Viewpoint
The Technology Viewpointdescribes the imple-
mentation aspects of the system. It will not be
further described here.
4 Functional Model
A functional model has been defined for IP
topology management in [genIPmodel]. The
management requirements are defined in the
enterprise viewpoint of this functional model.
The requirements are expressed as a set of poli-
cies associated with the topology management
community as a whole, and a set of actions
applicable to the various network resources
managed by the community.
4.1 Community Purpose, Roles and
General Policies
The topology management community shall
manage the topology of a layer network domain
and the relationships between the network
resources of this layer network domain. Services
are offered to create and delete the following
resources: subnetwork, link, topological link,
and connection termination point group. These
creation and deletion events may be reported
to potential notification receivers by use of the
offered reporting actions. Services are also
offered to create and delete associations between
connection termination points and connection
termination point groups, and between connec-
tion termination points and subnetworks. The
community supports subnetwork partitioning.
Several roles are defined in the topology manage-
ment community. The network resource roles are
the following: layer network domain, subnet-
work, link, topological link, connection termina-
tion point, and connection termination point
group. With the exception of connection termina-
tion point group, these roles represent resources
as defined in [G.852.2]. The network resources
represented are described in Section 3. Addi-
tional roles defined are those of the caller (i.e.
the client invoking the community actions), the
provider (i.e. the server performing the commu-
nity actions), and the notification receiver (i.e.
a receiver of the community reporting actions).A set of general policies has been defined for
the community. Some of these policies may be
termed “generic”, in the sense that they apply to
communities in general, not specifically to the IP
topology management community. An example
is “OBLIGATION viewingCapabilities”, in
which the provider is obliged to support a view
of resource properties and relationships suffi-
cient for the caller to request the contracted ser-
vices. Another example is “OBLIGATION ser-
viceRejection”, in which the provider is obliged
to identify the policy (obligation or prohibition)
that has not been fulfilled in case of service
rejection.In addition to the generic community policies,
several community-specific policies have been
defined. These policies define fundamental rules
and options for subnetwork partitioning.4.2 Community Actions
This section describes the various actions
offered by the topology management commu-
nity. In general, all action requests will be re-
jected by the provider if a community policy
is violated.4.2.1 Actions Related to Subnetworks
The create subnetworkaction creates a subnet-
work inside a layer network domain. The caller
may provide a unique identifier to be applied to
the created subnetwork. If the provided identifier
is not unique within the layer network domain,
the action request will be rejected. The caller
may also provide a user-friendly label for his
own use. This user label need not be unique
within the layer network domain. When the sub-
network has been created, the provider returns a
subnetwork identifier. A list of connection ter-
mination point groups that are associated with
the created subnetwork may also be returned,
if this is part of the provider policy.The delete subnetworkaction deletes a subnet-
work inside a layer network domain. A request
for subnetwork deletion will be rejected if the
subnetwork in question is associated with any
connection termination point groups or subnet-
works (i.e. in a subnetwork partitioning hierar-
chy).