9 Usage Scenario

32.106-83GPPConfiguration Management (CM)Part 8: Name convention for Managed ObjectsRelease 1999Telecommunication managementTS

9.1 DN prefix usage

This subclause presents recommended steps designer uses to partition the Enterprise name space while building an Alarm IRP compliant NE (the Alarm IRP Agent).

  1. The NE designer specifies the NRM (3G TS 32.106-5 [9]) for the NE. Suppose the NRM is a two level hierarchy with 3 classes like:

Node

|—– Port

|—– CrossConnect

  1. The NE designer, based on the NRM and other design choices, decides that there are 7 instances within the NE that can report alarms, such as

Port=1, Port=2, Port=3, Port=4, Port=5, CrossConnect=1, Node=1.

  1. The NE designer decides on the DN prefix (see Annex C) and configures its system accordingly. Since NE designer will not know the customer’s name space in advance, he would normally configure the DN prefix to reflect his test environment. The DN prefix can be configured to “Network=test”. The Global Root is “Network=test”. The Local Root is “Node=1”. It should be noted that the NE should not hard code the DN prefix but should treat DN prefix as a system configuration parameter, settable, for example, at system start-up time.
  2. When constructing the alarm record (in coding phase), NE designer shall concatenate the name of the alarmed instance with the DN prefix to form the DN of his test environment. The resultant DN (e.g., “Network=test,Node=1,Port=3”) will be placed in the Managed Object Instance (MOI) field of the alarm record.
  3. The NE is sold to a customer. The customer administrator knows his Enterprise name space, the topology of his network and where the NE will be deployed. Based on the information, he configures the DN prefix of the NE. For example, the customer administrator can configure it to:

“DC=CompanyXYZ.com,Net=DS3BackBone,Station=TMR”.

The Global Root in this case is “DC=CompanyXYZ.com”.

  1. At run time, whenever NE is reporting an alarm on Port=3 via the IRP, the following string will be in the MOI field of the alarm record.

“DC=CompanyXYZ.com,Net=DS3BackBone,Station=TMR,Node=1,Port=3”.

Annex A (normative):
Mapping of RDN AttributeType to Strings

NOTE: This annex is normative for users of string representation.

AttributeType of RDN are mapped into strings for use in the DN string representation. This annex specifies the mapping.

The AttributeType shall include all MO classes defined in the Network Resource Model (NRM) of 3G TS 32.106-5 [9].

There is one AttributeType that is not defined in NRM of 3G TS 32.106-5 [9]. This special AttributeType is used to denote the domain component of the DNS. The following partial DN string representations are examples to illustrate the valid use of “DC” strings for the three DNS domain components of “lme.companyZ.se”.

  • DC=se.companyZ.lme,..
  • DC=se,DC=companyZ,DC=lme,..
  • DC=se,DC=companyZ.lme,..
  • DC=se.companyZ,DC=lme,..

Table A.1: Example of RDN AttributeType Strings

String

AttributeType

DC

Domain component of DNS

G3SubNetwork

MO class name G3SubNetwork defined in NRM of 3G TS 32.106-5 [9].

etc.

See note.

NOTE: For each MO class name found in 3GPP set of specifications, its corresponding AttributeType String shall be identical to the class name with the leading character capitalised.

Annex B (normative):
Rule for MO Designers regarding AttributeType interpretation

NOTE: This annex is normative for users of string representation.

This annex discusses the two possible interpretations for the AttributeType of the DN string and recommends a rule for MO designers to avoid ambiguity concerning its usage. It identifies the protocol environment(s) under which each interpretation functions. It then recommends a rule for designing MO classes such that one DN string, regardless of protocol environment (therefore, regardless of interpretation used), will result in the unique reference to the identical network resource.

First interpretation

ITU-T Recommendation X.500 [2] uses the AttributeType (defined for use as the first component of the AttributeTypeAndValue of a RDN, see subclause 3.1.6) to identify one attribute of the subject MO for naming purpose. This AttributeType is called the naming attribute to distinguish itself from other attributes that may be present in the MO.

Suppose the following is the MO class definition in pseudo notation and this MO class is inherited from root.

Class Bsc {

Attribute id;

Attribute ..}

Suppose further that the naming attribute is id.

If this (first) interpretation is used for constructing the DN string, then the DN will be “…,id=123”. MO class name cannot be derived from the DN string. The value of the AttributeValue contains the value of the naming attribute.

Second interpretation

In CORBA protocol environment, it is preferable to use the following interpretation.

The AttributeType (defined for use as the first component of the AttributeTypeAndValue of a RDN) is used to identify the MO class.

If this interpretation is used for constructing the DN string, then the DN will be “…,Bsc=123”. The name of the naming attribute cannot be derived from the DN string. The value of the AttributeValue contains the value of the naming attribute.

Rule

Given the two interpretations, a DN reader cannot know how to interpret the AttributeType, i.e. if the AttributeType identifies class or naming attribute. To avoid ambiguity, the following rules shall apply:

  • If AttributeType of a naming attribute is not a concatenation of MO class name and “Id” (ignoring case for both), then the DN shall use “…,Yyy.zzz =123,..” where “Yyy” is the MO class name and “zzz” is the naming attribute (preserving case for both). For example, if “Bsc” is the MO class name and if its naming attribute is “serialNumber”, then the DN shall be “,,,Bsc.serialNumber=123,..”.
  • If AttributeType of a naming attribute is a concatenation of MO class name and “Id” (ignoring case for both), then the DN shall use “..,Xxx=123,..” where “Xxx” is the MO class name (preserving case). For example, if “Bsc” is the MO class name and if its naming attribute is “bscId”, then the DN shall be “,,,Bsc=123,..”.

Annex C (informative):
DN Prefix and Local Distinguished Name (LDN)

A Distinguished Name (DN) is used to uniquely identify a MO within a name space. A DN is built from a series of “name components”, referred to as Relative Distinguished Names (RDNs).

DNs within a name space are arranged in hierarchy similar to concepts of naming files in UNIX file system. A file name, in the context of a local subdirectory, contains the path (series of subdirectory names) of the file starting from the local subdirectory. The same file, in the global context, contains the path of the file starting from the root directory. Similar concept applies to naming MOs. From a particular (local) context, the name of a MO is the Local Distinguished Name (LDN). From a global context, the name of the same MO is the DN. LDN is a proper subset of DN. In the context of a particular local context, a DN prefix is defined such that all LDNs in that particular context, if attached behind the DN prefix of that context, will yield the DNs of the MOs.

The concepts of DN Prefix and LDN support the partitioning of large name space into smaller ones for efficient name space implementation. DN design, the subject of the present document, does not depend on these concepts. There exist other concepts that support partitioning of large name space as well. Although these concepts are independent from DN design, their use is wide spread and this Annex illustrates their use in partitioning large name space.

In modern network management, it is expected that the Enterprise name space be partitioned for implementations in multiple hosts. The following are reasons for the partitioning.

  • The Enterprise name space can be large (e.g., containing millions of objects). Partition of a large name space facilitates name space management. For example, it may be easier to manage two name spaces of 1 million objects each than to manage one name space with two million objects.
  • Separate IRPAgents manage sub-set of the Enterprise name space relevant to their own local environment. For example, one NE manages a name space (subset of the Enterprise name space) containing names of its MOs representing its own network resources. Another NE manages another sub-set, etc.
  • For reasons such as security, replication, back-up policy and performance, sub-sets of the Enterprise name space are managed by separate systems. For example, Operation and Marketing departments may want to manage their name spaces using their respective management policies. Partitioning of Enterprise name space according to departmental jurisdiction may facilitate deployment of independent management policies.

Suppose the Enterprise name space is organized hierarchically and is partitioned into 4 sub-sets as shown in figure C.1.

Figure C.1: Name space partitions

NS (name space)-A contains 5 objects. DN prefix is NULL. The Global Root and Local Root of NS‑A is “DC=se.companyZ.lmc” (see the Note below). DN of top object is “DC=se.companyZ.lmc”. RDNs of the other four objects are, from bottom left to bottom right, “A=1”, “A=7”, “ A=3” and “A=9”. DNs of the same four objects are “DC=se.companyZ.lmc,A=1”, “DC=se.companyZ.lmc,A=7”, “DC=se.companyZ.lmc,A=3” and “DC=se.companyZ.lmc,A=9”. The second and fourth objects are reference objects to MOs in NS-B.

NS-B contains two branches. They have the same DN prefix that is “DC=se.companyZ.lmc”. The Global Root is “DC=se.companyZ.lmc”.

The Local Root and RDN of top object of the right branch is “A=9”. Its DN is “DC=se.companyZ.lmc,A=9”. RDNs of other objects are shown in figure C.1.
DN of the bottom object is “DC=se.companyZ.lmc,A=9,F=1,G=1,H=2”. This object refers to object of another name space called NS‑D.

The Local Root and RDN of the top object of the left branch is “A=7”. Its DN is “DC=se.companyZ.lmc,A=7”. RDNs of other objects are shown in figure C.1.
DN of the bottom object is “DC=se.companyZ.lmc,A=7,X=1,Y=1”. This object refers to object of another name space called NS-C.

NS-C contains a branch of 4 objects. Its DN prefix is “DC=se.companyZ.lmc,A=7,X=1”. The Local Root an RDN of the top object is “Y=1”.

NS‑D contains a branch of 5 objects. Its DN prefix is “DC=se.companyZ.lmc,A=9,F=1,G=1”. The Local Root and RDN of the top object is “H=2”.

In figure C.1, the bottom object of NS‑B right branch has the following names:

  • DN is “DC=se.companyZ.lmc,A=9,F=1,G=1,H=2”.
  • LDN is “A=9,F=1,G=1,H=2”.
  • RDN is “H=2”.

With this example, we can see that DN of an object is a series of RDNs spanning the global name space. LDN of an object is a series of RDNs spanning the local name space where the subject MO resides.

The concatenation of the LDN with DN prefix of that (partitioned) name space shall produce the DN of the global name space.

NOTE: Use of “DC” in “DC=se.companyZ.lmc” is an attempt to align the RDN with DNS name associated with the named organisation. The “DC” stands for Domain Component and is an attribute name defined by IETF for use in directory work. Annex A specifies other valid ways to align RDN with DNS as well. Equally valid, the example can choose to align the RDN with the X.500 convention. In such case, the subject string can be “C=se,O=CompanyZ,L=lmc” where C, O and L are X.500 standard attributes denoting country, organisation and location respectively. The alignment choice belongs to the name space designer of each operator. The choice will be reflected in the value of the DN prefix, probably a product configuration parameter. See Clause 7 for more information.

Annex D (informative):
Change history

This annex lists all change requests approved for this document since the specification was first approved by 3GPP TSG-SA.

Change history

Date

TSG #

TSG Doc.

CR

Rev

Subject/Comment

Old

New

Mar 2000

S_07

SP-000012

Approved at TSG SA #7 and placed under Change Control

2.0.0

3.0.0

Mar 2000

cosmetic

3.0.0

3.0.1

Jun 2000

S_08

SP-000245

005

Split of TS 32.106 – Part 8: Name Convention for Managed Objects

3.0.1

3.1.0

Jun 2001

S_12

SP-010284

001

Correct errors in DN name convention for Managed Objects

3.1.0

3.2.0