Content for TS 32.107 Word version: 18.0.0
7 Name Convention for class instances (managed objects)
7.1 Background
7.1.1 Name
7.1.2 Name space
7.1.3 Unique names
7 Name Convention for class instances (managed objects) p. 18
7.1 Background p. 18
FMC NM involves a federation of models, which are designed and maintained by different SDOs or standard organizations including expert groups. The model(s) contain classes of managed resources. Instances of these classes are identified by an identifier (called name in this document).
To maintain integrity of the class instances of the federated model, the names of all instances, whose classes are defined under the federated model, must be unambiguous, i.e. an (unambiguous) name can only refer to one instance and an instance may have more than one (unambiguous) name.
For simplicity, FMC NM employs unique names, i.e. one name can only refer to one instance and one instance have at most one name.
7.1.1 Name p. 18
A name is a unique identification of an FMC FNIM specified managed resource instance.
7.1.2 Name space p. 18
A name space (NS) is a collection of names. This name convention uses a hierarchical containment structure, including its simplest form - the one-level, flat NS (the rightmost NS of Figure 7). This name convention does not support an arbitrarily connected NS, or graph structure, in which a named managed resource can be both child and parent of another named managed resource.
The Figure below shows some examples of supported NSs.
7.1.3 Unique names p. 19
Names in a NS can be organised as one or more inverted tree hierarchies (see the left-most two NSs of Figure 7). A managed resource instance that contains another one is referred to as the superior (parent), whereas the contained managed resource instance is referred to as the subordinate (child).
FMC NM involves a federation of models, which are designed and maintained by different SDOs or standard organizations including expert groups technology-domain-specific-models. The model(s) contain classes of managed resources. Each instance has a name.
From the perspective of FMC NM, the FMC NS is partitioned into various (sub) NSs. Each (sub) NS is a collection of names of instances, whose classes are defined by the corresponding technology-domain-specific-model.
For illustration, suppose the following Figure 8 shows the (sub) NSs for names of instances whose classes are defined by, say 3GPP/SA5 [4] (the one on the left) and MEF [5] (the one on the right of the Figure).
This document does not specify the following, since they are specified already by specifications of various technology-domain-specific-models:
- The method by which the names within a (sub) NS can be made unique;
- Register itself with a domain name (e.g. "acme.com") with a domain name registrar that is accredited by the Internet Corporation for Assigned Names and Numbers (ICANN), the organization charged with overseeing the name and number systems of the Internet.
-
For each (sub) NS it manages, construct a naming-path using the two domain components (dc=acme, dc=com) from its registered domain name.
- The name-path may contain just the two domain components from its registered domain name. It may also contain more domain components such as organization units, e.g. (dc=FixedNetwork, dc=acme, dc=com; dc=mobileNetwork, dc=acme, dc=com) or localities, e.g. (dc=montreal, dc=acme, dc=com; dc=Sorrento, dc=acme, dc=com).
- Use name-path as the root of its (sub) NSs.
