Contents

1   Introduction

This document describes the Ericsson reference data model for the basic and initial data maintained in the Ericsson Centralized User Database (CUDB), providing a detailed description of Lightweight Directory Access Protocol (LDAP) data model information, such as CUDB directory entries, object and attribute descriptions, formats, and allowed value ranges.

This document also provides an overview of supported LDAP operations and LDAP users that can be used to manage, provision and access the data stored in CUDB.

1.1   Scope

This document covers the following:

• CUDB data model description
• Attributes and objects classes
• CUDB DIT entries
• Operations to handle CUDB data

This document provides the necessary information and understanding of the basic structures of CUDB data model and how to use the LDAP interface to manage stored data to facilitate the integration of application Front Ends (FEs) data into CUDB.

The description of specific application FE data models or internal-only CUDB data is out of the scope of this document.

1.2   Revision Information

Rev. A

Rev. B

Rev. C

Rev. D

Rev. E

Rev. F

Rev. G

Rev. H

Rev. J

Rev. K

1.3   Target Groups

This document is intended for users working with CUDB LDAP schemas. This document assumes the general knowledge of the LDAP standard.

1.4   Typographic Conventions

Typographic conventions can be found in the following document:

• Typographic Conventions

2   Overview

CUDB is the network entity in a layered architecture providing a central data storage point for application FE data (Home Location Register (HLR) FE data, IP Multimedia Subsystem (IMS) data, and so on). Stored data is exposed and accessed through LDAP v3 protocol.

LDAP is a client-server based directory access protocol that provides both read and update access. The LDAP data information model provides the structures and data types necessary for building an LDAP directory tree.

This document describes the LDAP data provided in the following LDAP schemas:

• /cluster/home/cudb/dataAccess/ldapAccess/ldapFe/config/schema/cudb.schema
• /cluster/home/cudb/dataAccess/ldapAccess/ldapFe/config/schema/application_counters.schema

3   CUDB Data Model Description

The following sections describe CUDB data model. For more information on LDAP data model, refer to CUDB LDAP Data Access, Reference [1].

3.1   CUDB Main Directory Information Tree

In CUDB, from the LDAP data modeling perspective, the upper levels of the Directory Information Tree (DIT) are divided into the following branches:

• CUDB root entry
• Administrative LDAP user data (out of the scope of this document)
• Application Identity data.
• Multi Service Consumer (MSC) data.
• Association data.
• MSC common data.
• Service common data.
• Application Counters data (read only)
• dsgLocks data

Figure 1 shows CUDB LDAP DIT.

CUDB Data is distributed across data partitions. To achieve data distribution, CUDB provides a special type of entry, called a Distribution Entry (DE). CUDB DE are regular LDAP entries, but contains additional metadata to store and find the entries and their sub-trees in a given data partition

CUDB, by default, has three built-in DEs, but allows defining custom DEs, if necessary. The build in DEs are MSCs, Associations, and CUDBLockDistribution.

Custom DEs must fulfill the following requirements:

• When a DE is provisioned, the following two optional attributes must be defined in any included object class that is part of the DE:
  • ZoneId.
  • DSUnitGroup.

For more information, refer to CUDB Node Configuration Data Model Description, Reference [3].

3.1.1   CUDB Root Entry

The CUDB root entry is the top level entry of the directory tree.

The Distinguished Name (DN) and Relative Distinguished Name (RDN) of the CUDB root entry are fully configurable at CUDB installation time.

3.1.2   CUDB LDAP Users and Groups

For an application FE to access the data stored in CUDB through LDAP interfaces, authentication must be completed before a session is established. Therefore, applications must create or use one or more LDAP users with the corresponding credentials and configuration parameters.

Once the LDAP user has been created, application FEs can bind to the LDAP interface and send LDAP operations to CUDB. Optionally, user groups can be defined to share access control rules. For more information on how LDAP users and LDAP users groups are defined in CUDB, refer to CUDB System Administrator Guide, Reference [5].

LDAP users have additional configuration parameters. Using the LDAP Data Views function, LDAP users are assigned an LDAP data view to access the data through a custom DIT defined for the view. Users without an assigned LDAP data view access the data through the default DIT.

Note:  

The LDAP Data Views function requires the Application Facilitator Value Package.

LDAP users and user groups are defined through configuration. For more information, refer to CUDB Node Configuration Data Model Description, Reference [3].

The administrative data entries defined in CUDB are the following:

• Admin container: "ou=admin,<CUDB root entry>"
• LDAP User data: "cudbUser=<CUDB LDAP user>,ou=admin,<CUDBroot entry>"
• LDAP Group data: "ou=<CUDB LDAP group>,ou=admin,<CUDBroot entry>"
• LDAP User data belonging to a LDAP Group: "cudbUser=<CUDB LDAP user>,ou=<CUDB LDAP group>,ou=admin,<CUDBroot entry>"

3.1.3   Identity Data

Identities are LDAP entries containing a reference to find and access subscriber data, typically MSC or Association, data. Identity entries are placed under ou="identities" container level entry below the CUDB root entry.

There are two types of identity entries, depending on how they reference an MSC or an Association DE.

• Primary identities: These entries are always LDAP aliases referencing another entry (typically to an MSC, an Association, or to a secondary identity). As primary identities serve this specific purpose, they are special entries in CUDB, as each type must be defined at installation and the entries are stored to optimize the space taken up by each entry. Primary identities can only be stored directly below its type container, which is populated at installation time. Even though primary identities are LDAP aliases, CUDB supports a non-standard LDAP modify operation, that allows modifying the target entry through alias de-referencing, if the entry to be modified is addresses through a primary identity. For more details, see Section 6.
• Secondary identities: These entries are similar to primary identities, as they are usually used to references other entries, but the alias does not have to be in the identity itself, but can also be below it. Unlike primary identities, these are not special entries in CUDB. For example, a secondary identity could be an entry that contains subentries for different services where each subentry contains an alias referencing to a different MSC or Association.

Figure 2 provides an example of primary and secondary identity entries.

A primary identity data entry, defined in CUDB:

• Identity container: "ou = identities, <CUDBroot entry>"

Separate containers for different identity types of identities can be defined based on identity data:

• Identity domain container: "dc=<identity type>, ou= identities, <CUDB root entry>"

  <identity type> can take any value. For example, msisdn, imsi, impi, impu, ipaddress, and so on.

  The entry must contain at least one LDAP object class containing the attribute dc. For example, dcObject.

  Following is an example of container for MSISDN:

  "dc = msisdn, ou = identities, <CUDB root entry>"

Under each different identity type container, alias entries per identity can be defined:

• Identity alias: "<identity type attribute name>=<identity value>, dc=<identity type>, ou = identities, <CUDB root entry>"

  <identity type attribute name> can take any name. For example, msisdn, imsi, impi, impu, ipaddress, and so on.

  This attribute, its type, syntax, and the object-class are defined in an LDAP schema, which is provided by CUDB LDAP client application. On the schema provided, the object-class type must be specified as auxiliary and not as structural.

  The entry must contain the alias object class containing the attribute aliasedObjectName. For example, alias.

  Note:  

  As the alias object class is a structural class, the <identity type attribute> can be added using the extensibleObject object class. If an auxiliary object class is present in an entry the entry can optionally hold any attribute. The list of allowed attributes for this class is implicitly the set of all known server attributes.

  
  

  Following is an example of MSISDN alias:

  "MSISDN =<MSISDNnumber>, dc = msisdn, ou = identities, <CUDB root entry>"

  The identity type attribute name must be the same as the identity type. In the above example, the identity type attribute name MSISDN matches the identity type msisdn.

3.1.4   Multi Service Consumer and Association Data

Specific data for each Multi Service Consumer (MSC) can be placed under separate entries identified by rdn: "mscId = <msc identifier>". Entries under this level are created for the services the MSC uses.

Association data specific entries are identified by rdn:"assocId=<associdentifier>". Similarly to the MSCs, entries under this level are created for the services the MSC uses.

Figure 3 provides an example of the MSC and association data.

The following MSC data entries are defined in CUDB:

• MSC container: "ou = multiSCs,<CUDB root entry>"
• MSCs: "mscId = <mscId>, ou=multiSCs, <CUDBroot entry>"
• MSC data for services can be placed under mscId entry in "serv=<service>, mscId = <mscId>, ou=multiSCs, <CUDB root entry>>", where <service> can take any value. For example, CSPS, Auth and so on.

The following association data entries are defined in CUDB:

• Association container: "ou = associations, <CUDBroot entry>"
• Associations: "assocId = <assocId>, ou=associations,<CUDB root entry>"
• Association data for services can be placed under assocId entry in "serv=<service>, assocId = <assocID>, ou=associations,<CUDB root entry>>", where <service> can take any value. For example, CSPS, EPS and so on.

Container entries "ou = multiSCs,<CUDB root entry>" and "ou = associations, <CUDBroot entry>" cannot be deleted, as they are CUDB DE parent entries. For more information, refer to the DEs section of CUDB LDAP Data Access, Reference [1].

3.1.5   MSC Common Data

MSC common data contains data shared by a group of MSCs, placed under the container level entry "ou = mscCommonData". Entries under this level are created for the services the MSC uses. Each entry is referenced by all the MSCs that share this common data using LDAP alias.

Figure 4 shows an example of MSC common data.

The following MSC common data entries are defined in CUDB:

• MSC common data: "ou=mscCommonData, <CUDBroot entry>"

MSC common data for different services is placed under the mscCommonData entry in specific MSC common entry data placed under "serv=<service>,ou=mscCommonData, <CUDB root entry>".

3.1.6   Service Common Data

Service common data contains data shared on application FE level. Entries under this level are created for different services.

Figure 5 shows an example of service common data.

The following entries are defined in CUDB:

• Service common data: "ou=servCommonData, <CUDB root entry>"

MSC common data for services can be placed under mscCommonData entry.

• Service specific common data is placed under "serv=<service>,ou=servCommonData, <CUDB root entry>"

3.1.7   CUDB Application Counters Directory Information Tree

CUDB provides read-only access though the LDAP interface to the set of Application Counters by exposing those counters in a separate branch in the LDAP DIT:

• Root Entry: "ou=ApplicationCounter"
• Application Counters Group entries that host no data: "dn: cn=<Counters Group Name>, ou=ApplicationCounter"
• Application Counters entries are organized below their respective Application Counters Group parent entry, and host the counter name and value: "dn: cn=<Application Counter Name>,cn=<Counters Group Name>, ou=ApplicationCounter"

For more information, refer to CUDB Application Counters, Reference [4].

Figure 6 shows the Application Counters DIT.

The new LDAP FE Back End (BE) for counters fetches the value of the column <Application Counter Name> from the table <Counters Group Name>, and puts it in the generic value LDAP attribute. To fetch a counter value, the following LDAP search operation is used:

• Basedn: "ou=ApplicationCounter, cn=<CountersGroupId>, cn=<CounterId>"
• Scope: any, base/one/subtree will return the same.
• Filter: "objectclass=*" or "cn=<CounterId>" or "CounterValue=*" can be used.

An example of an LDAP search operation is shown below:

 # ldapsearch -Y CUDB-CRYPTO -h pl_2_3 -U manager -W -b "cn=NSUBSCNT,cn=GRP_HLRSUBS,ou=ApplicationCounter" //
-s base # extended LDIF
 #
 # LDAPv3
 # base <cn=NSUBSCNT,cn=GRP_HLRSUBS,ou=ApplicationCounter> with scope baseObject
 # filter: (objectclass=*)
 # requesting: ALL
 #
 # NSUBSCNT, GRP_HLRSUBS, ApplicationCounter
 dn: cn=NSUBSCNT,cn=GRP_HLRSUBS,ou=ApplicationCounter
 objectClass: ApplicationCounter
 cn: NSUBSCNT
 CounterValue: 3924600
 # search result
 search: 2
 result: 0 Success
 # numResponses: 2
 # numEntries: 1

Note:  

A prompt to enter the LDAP root user password is shown.

3.1.8   dsgLocks

This LDAP DIT branch is used primarily by the CUDB system to allocate temporarily information during internal CUDB subscribers reallocation procedures. For more information, refer to CUDB Subscription Reallocation, Reference [6]. Typically, external client applications do not need to read or modify data on this subtree. The entry has the following format: "ou=dsgLocks,<CUDBroot entry>".

Figure 7 shows an example of the dsgLocks branch.

The following dsgLocks entries are defined in CUDB:

• dsgLocks container: "ou=dsgLocks,<CUDBroot entry>"
• dsgIds: "dsgId=<dsgId>,ou=dsgLocks,<CUDBroot entry>"
• cudbDsgLockedBy entries: "cudbDsgLockedBy=<processId>,dsgId=<dsgId>,ou=dsgLocks,<CUDBroot entry>"

3.2   LDAP Views

Note:  

The LDAP Data Views requires function the Application Facilitator Value Package.

CUDB supports LDAP data views to support flexible data organization. If an LDAP user has an LDAP view assigned to it, then the user will access the data through that view.

Each LDAP data view has its own LDAP schema in the CUDB, building a custom DIT and a mapping file, describing how the virtual entries of the specific view are constructed from the core DIT attributes. The CUDB LDAP Data Views allows the data to be shown in different DITs accessible through the LDAP interface.

For more information, refer to CUDB LDAP Data Views, Reference [2].

3.2.1   Concepts

The following list contains the LDAP Data Views concepts:

• Core DIT: The current way the data stored in the database cluster is accessible through the LDAP interface in CUDB.
• Real entry: An entry in the CUDB core DIT.
• LDAP Data View (View): A configurable, tree-like alternative representation of the stored database cluster data. Entries are defined from attributes mapped from entries the core DIT.
• Virtual entry: An entry in a view, the attributes of which are mapped from one or several real entries.
• One-to-one mapped entries: Fully writable virtual entries that have a direct matching entry in the core DIT, with the same content as their core DIT counterparts.

4   Attributes and Object Classes

The following sections describe CUDB attributes and object classes defined in the default LDAP schema.

4.1   Attributes

Table 1 lists the attributes defined by CUDB, both for internal use and for the applications to store data inside CUDB.

(1)   For the CDC mechanism to work all LDAP clients accessing the entry must use the CDC attribute using the same option from those described in Section 6.1. The CDC attribute is defined in the schema as a multi-value integer type to support providing several values in the LDAP write requests, although one only value is written and persistent in the database. In practice, the CDC attribute is stored as single-value, but handled as multi-valued while processing LDAP requests. Therefore, it should be defined as multi-valued.

(2)  For more information about CUDB node configuration, refer to CUDB Node Configuration Data Model Description, Reference [3]

(3)  This attribute must be defined in any object class included in the DE.

(4)  For more information, refer to CUDB Multiple Geographical Areas, Reference [7].

4.2   Object Classes

An object class identifies a set of attributes in an entry in the DIT. Table 2 shows the LDAP object classes used in CUDB.

For more information on syntaxes and matching rules, refer to RFC 4517 LDAP: Syntaxes and Matching Rules, Reference [11].

4.3   Operational Attributes

The CUDB LDAP server supports the following operational attributes, detailed in Table 3:

• structuralObjectClass.
• createTimestamp.
• modifyTimestamp.

For more information about these attributes, refer to RFC 4512 LDAP: Directory Information Models, Reference [12].

(1)  These attributes may not be returned for all entries, check CUDB LDAP Data Access, Reference [1] for more information.

The following CUDB-specific operational attributes also exist:

• nodeID: the ID of the node from where the entry was returned, relevant in case of proxied requests.
• entryDS: the DS from which the entry was read.

4.4   Limitations

The limitations on attributes and object classes used in CUDB are the following:

• The maximum number of object classes defined per entry is 100.
• Inheritance between object classes is not supported.
• An object class cannot have more than 121 attributes.
• Object class capacity is limited to 8 KB. This limit does not include possible binary large objects (BLOBs) in the object class.
• Attributes can store up to 4 KB, except for octet string attributes that can hold up to 4 GB.

  Note:  

  The default maximum size for octetString and string attributes in CUDB is 255 octets. All attributes larger or significantly smaller may indicate the minimum upper bound for the size between curly brackets "{ }" after the syntax Object Identifier (OID). For more information, refer to RFC 4512 LDAP: Directory Information Models, Reference [12].

  DirectoryString and DN attributes use 3 bytes per character.

  
  
• DEs cannot contain multi-valued attributes.
• The depth of the DIT, that is, the number of sublevels including the root is 12.
• The RDNs of any DN are limited to 80 unicode characters.
• The maximum length of any DN is 512 unicode characters.
• Alias de-referencing in subtree or onelevel searches is not supported if the aliases are in subentries under the base DN.
• Aliases in entries under DEs that point to other entries under DEs are supported only if both are allocated in the same DS Unit Group (DSG). For more information, refer to CUDB LDAP Data Access, Reference [1].
• The maximum length of BASE64 encoded LDAP Data Interchangeable Format (LDIF) for LDAP extended operation is limited to 512 KB. This equals to 384 KB limit for decoded content.

5   CUDB DIT Entries

The following sections describe the predefined entries of the CUDB DIT created at installation time. It also contains entries that are expected to be created under the predefined entries using LDAP schema.

5.1   CUDB Admin Entry

The CUDB admin container entry holds the data for CUDB LDAP users. Table 4 shows the CUDB admin entry.

5.2   Identities Container Entry

The identities container entry holds the identities for the MSCs grouped by identity domains. Table 5 shows the identities container entry.

5.3   Multi Service Consumer Container Entry

The MSC container entry holds the entries containing the data for all the MSCs in CUDB. Table 6 shows the MSC container entry.

5.3.1   Multi Service Consumer Data Entry

The MSC data container entry contains an MSC. Sub-entries under this level are created for the services the MSC uses. Table 7 shows an MSC consumer data entry.

5.3.2   Multi Service Consumer Data Service Entry

The MSC data service entry is the container for the service-specific multi service consumer data in CUDB. Table 8 shows an MSC data service entry.

5.4   Associations Container Entry

The associations container entry is the container for the entries containing data for all the associations in CUDB. Table 9 shows the associations container entry.

5.4.1   Association Data Entry

An association data entry contains an association. Sub-entries under this level are created for the services the association uses. Table 10 shows an association data entry.

5.4.2   Association Data Service Entry

An association data service entry is the container for the service-specific association data in CUDB. Table 11 shows an association data service entry.

5.5   Multi Service Consumer Common Data Container Entry

An MSC common data container entry is the container for MSC common data in CUDB. Table 12 shows an MSC common data container entry.

5.5.1   Multi Service Consumer Common Data Service Entry

An MSC common data service entry is the container for the service-specific service common data in CUDB. Table 13 shows an MSC common data service entry.

5.6   Service Common Data Container Entry

A service common data container entry is the container for the service common data in CUDB. Table 14 shows service a common data container entry.

5.6.1   Service Common Data Service Entry

A service common data service entry is the container for the service specific related service common data in CUDB. Table 15 shows a service common data service entry.

5.7   dsgLocks Container Entry

The dsgLocks container entry is the container for the entries containing data for all of the cudbReallocate locking entries. Table 16 shows the dsgLocks container entry

5.7.1   dsgLocks Data Entry

A dsgLocks data entry contains a dsgId where the entries holding the distribution entries that are locked during the cudbReallocate procedure will be placed. Table 17 shows a dsgLocks data entry.

5.7.2   dsgLocks Data Distribution Entry

A dsgLocks data distribution entry contains information about the distribution entries locked by the specified blade. Table 18 shows a dsgLocks data distribution entry.

6   Operations

The following LDAP operations are used to handle CUDB data:

• Bind
• Add
• Delete
• Modify
• Search
• Unbind

The following LDAP extended operations, detailed in Table 19, are used to handle CUDB data:

• Ldapbundled
• Ldapbundledadd

The LDAP Data Views function uses the following LDAP operations when accessing data through view:

• Modify-add: add an attribute to a virtual entry, resulting in a new attribute in the existing real entry.
• Modify-delete: delete an optional attribute from a virtual entry, resulting in a deleted existing attribute in the real entry.
• Modify-replace: replace an attribute in a virtual entry, resulting in a replaced attribute in the existing real entry. If the attribute does not exist, the request is handled as modify-add. If no value is provided, the request is handled as modify-delete.
• Search: searches involving data from both Processing Layer Database (PLDB) and DSG are not supported.

When accessing data through LDAP data views, special entries can be used, called one-to-one mapped entries.

One-to-one mapped entries are real entries with the exact the same contents as the virtual entries. They can be created, deleted, and their contents modified through views without any restriction other than the ones that apply to a real entry.

Note:  

The LDAP Data Views function requires the Application Facilitator Value Package.

There are certain special provisions in CUDB regarding standard LDAP operations.

• CUDB does not support including the abstract objectClass top in LDAP modify operations. The abstract objectClass top in modify operations is optional, according to LDAP RFCs. In such case, CUDB returns the following error:

  err=80, msgText=Object class not configured in OBJECT_CLASSES table

• Alias de-referencing in LDAP modify operations for primary identities is a non-standard behavior offered by CUDB. This behavior implies that the aliases found when resolving the target DN specified in an LDAP modify operation are always de-referenced if the original DN of the object to be modified contains a primary identity.

  Two examples for alias de-referencing with a DN that contains a primary identity are as follows:

  • serv=csps,IMSI=123456789,dc=imsi,ou=identities, <suffix>
  • serv=csps,MSISDN=346162681,dc=msisdn,ou=identities, <suffix>

  A CUDB LDAP modify operation on these two entries will result in the modification of the two entries being referenced by the IMSI=123456789 and MSISDN=346162681 aliases. It means that both, mscId=id and assocId=id are going to be modified through their corresponding aliases, as depicted in Figure 8:

A standard behavior of the LDAP modify would not de-reference the query and in the example above, no modification would take place in mscId=id and assocId=id. In such case, the LDAP modify query returns an error saying that the required entry does not exist.

6.1   CDC

Client Applications can have the Collection Detection Counter (CDC) attribute in LDAP entries to avoid race conditions when several clients access LDAP entries at the same time. An example for such race condition is LDAP client B performing a write operation on an entry between a previous read operation and a subsequent write operation by LDAP client A on the same entry. If both clients use the same CDC method from the options described below, the first client can assert that no other client accessed the entry after it read that entry.

There are two alternative ways to implement collisions detection using the CDC attribute within an entry:

6.1.1   Option 1

1. Client A reads the LDAP entry, along with its CDC value.
2. Client A modifies the LDAP entry and the CDC attribute the following way:
   1. Add multiple new values with the add attribute operation to the multi-valued CDC attribute, the values ranging from <CDC_read_value>+1 to <CDC_read_value>+N, N being the tolerance factor detecting up to N potential changes made by other clients in the time since the read was done.

      The LDAP modify operation:

      [add/modify/replace/delete operations on attributes belonging to the entry]
      
      add: CDC: <CDC_read_value>+1
      
      add: CDC: <CDC_read_value>+2
      
      ...
      
      add: CDC: <CDC_read_value>+N

   2. In the same LDAP request, use a modify-replace operation on the CDC attribute CDC: <CDC_read_value>+1:

      replace: <CDC_read_value>+1

   3. Perform any other add/modify/replace/delete operations in the same LDAP request on attributes in that LDAP entry.

The LDAP operation fails if one or up to N other LDAP clients changed the LDAP entry and its CDC value between the read and the write operations by client A. The way the LDAP modify operation is evaluated makes the CDC add operation fail if CDC already includes any of the values to add to and returns LDAP errorCode=20 attributeOrValueExists. If 1 to up to N other LDAP clients changed the LDAP entry between the read and the write operations by client A, CDC would also change to a value equal to one of the values in the add operations, <CDC_read_value>+1 to <CDC_read_value>+N, specified by client A, and the write operation will not succeed.

If the add check passes, the CDC replace operation in the same request will successfully write one single value of the <CDC_read_value>+1 into the CDC, and the rest of the add/modify/replace operations on the entry will go through.

Note:  

The replace operation within the LDAP modify/write request sets only one value of the multi-valued CDC attribute.

6.1.2   Option 2

1. Client A reads the entry, along with its CDC value.
2. Client A updates LDAP entry as needed, and at the end of the modify operation, includes a delete attribute operation on the read CDC value.

   The LDAP modify operation:

   [add/modify/replace/delete operations on attributes belonging to the entry]
   
   delete: CDC: <CDC_read_value>

The LDAP operation fails if any other LDAP client changed the entry and the CDC value between the read and write operations by client A. The LDAP modify operation is evaluated so that the check if the CDC includes the value to be deleted is the first step. If any client changed the CDC to a newer value, then the delete attribute operation on the former value will fail.

In the same write request, use a modify-replace operation on the CDC attribute CDC: <CDC_read_value>+1:

replace: CDC: <CDC_read_value>+1

If the delete check passes, the replace operation in the same request writes the next value of the CDC.

Option 2 is recommended, as it works irrespective of the number of other LDAP clients that attempted to modify the LDAP entry between the read and the write operations by client A. It does not limit the number to N potential CDC changes.

Note:  

The replace operation within the LDAP modify/write request sets only one value of the multi-valued CDC attribute.

6.2   Base DN Transformation in LDAP operations over Authentication Data Operations (serv=Auth)

CUDB handles certain situations for application FEs uniquely, such as in requests from UDM applications, baseDn transformations are applied transparently to cover these use cases.

Therefore, when a search operation is received from any CUDB LDAP client with the following

"baseObject: dn: serv=Auth, IMSI =<IMSInumber>, dc = imsi, ou = identities, <CUDB root entry>"

and alias de-referencing is equal to finding or always, the operation is interpreted as if the following

"baseObject: dn: IMSI =<IMSInumber>, serv=Auth, IMSI =<IMSInumber>, dc = imsi, ou = identities, <CUDB root entry>" was received instead.

The same applies for any LDAP modify operations for the above baseObject.

6.3   Performing LDAP Search Below the DE

The CUDB subscriber-centric data model, depicted in Figure 1, enables data consolidation through storing application service profiles right below a DE, in an mscId or an asscoId.

Client applications retrieve only their own service profiles data, that is, their own application data, below their serv=<service> entries) and are unaware of other populated profiles created at the same level below the DE.

The CUDB search engine is optimized for LDAP search operations that target individual entries that use the entry DN as search base object. Use this type of search for the best performance.

To enhance the performance of LDAP subtree searches, the CUDB search engine implements an index optimization for search operations that look through the LDAP DIT starting downwards from a base entry and fetch different LDAP entries. For more information, refer to the LDAP Massive Search Indexes section in CUDB Application Integration Guide, Reference [9].

To take full advantage of search index optimization, choose the best possible search base for the LDAP operation, such as the location in the directory tree from which the LDAP subtree search begins.

As a general recommendation, always start application subtree searches from a serv=<service> entry or any other entry below it as the search base object. Do not use start subtree searches starting from the DE, otherwise the scanning of every other service profiles and their child entries can cause significant performance drop.

In case of using subtree searches starting from the DE, those can be optimized and executed faster by configuring the Optimized Subtree Searches function. With that feature it is possible to narrow the scope of the subtree search down to a list of specified targets. For more information refer to the Optimized Subtree Searches section inCUDB System Administrator Guide, Reference [5].

6.4   Error Codes

The CUDB LDAP interface supports the LDAP result codes defined in the LDAP protocol specifications. For more information, refer to RFC 4511 LDAP: The Protocol, Reference [13].

Table 20 shows the LDAP result codes in CUDB, describing the possible causes for each error and possible actions about how to handle these errors from the client application perspective.

Note:  

The "Description" provides the most common reasons why the corresponding error is received. This description does not provide all possible causes. The message diagnostic text may provide more specific information about the error.

For additional information on overload-related causes, mastership change, unavailability, or unreachability, refer to the following Facility Descriptions:

• CUDB LDAP Data Access, Reference [1]
• CUDB High Availability, Reference [8]

For more information on error codes, refer to CUDB LDAP Data Access, Reference [1].

6.5   LDAP Controls

LDAPv3 allows clients and servers to use controls as a mechanism for extending an LDAP operation. A control is a way to specify additional parameters as part of a request and a response. For more information, refer to RFC 4511 LDAP: The Protocol, Reference [13].

6.5.1   ReadMode Control

The CUDB LDAP interface supports ReadMode control with Object ID=1.3.6.1.4.1.193.169.3.3, which is used to temporarily override the LDAP read preferences for PLDB and DSG.

The ReadMode LDAP control is not supported for LDAP write operations, such as modify, add, or delete. If the Extension Control criticality in the write request is set to FALSE, the ReadMode control is ignored and operation is processed normally. If the Extension Criticality is set to TRUE, the LDAP request will receive an err=12, msgText=critical extension is unavailable message.

In case of distributed or massive searches, that is, search requests distributed to various DSGs, ReadMode control content is always ignored.

When ReadMode control is used, the recommended setting for criticality is FALSE.

For more information, refer to RFC 4511 LDAP: The Protocol, Reference [13].

The ReadMode control has an ASCII string value, indicating a combination of readModeinPL and readModeinDS that is to be applied to particular LDAP search request.

When a search request with ReadMode control is received, the read mode control values extracted take precedence over readModeInDS and readModeInPL values configured for the LDAP user.

6.6   CUDB LDAP Extended Operations

CUDB LDAP interface supports two additional LDAP extended operations that allows packing multiple write operations that are bundled into one single LDAP request.

Extended operations are defined by its OID identifier and they allow adding an LDIF payload with the multiple batched operations. There are two different operation types, which are used in different use cases as described in Table 19.

If any of the bundled operations fails, the entire LDAP operation will fail.

Generic write request operation allows executing batches of multiple add, modify, and delete operations.

Provisioning write request operation only supports batches of add operations.

For generic writes LDAP extended operation will return a "matchedDN" field (along with error code and description text) to point out on which entry in the batch the operation failed.

Data to be processed must comply with the following validation rules:

• All entries are targeting either one of PL or DS. No mix is allowed.
• When targeting a DS, all DS entries are under the same DE.
• If provisioning operation type, all entries must be siblings and/or in parent-child relationship.
• If provisioning operation type, the change type for all operations in LDIF file must be ADD.
• Alias dereferencing is not supported.
• Parent must be added before its children.
• Children in the LDIF must be deleted before the parent.
• Size of bulk data must not exceed 512 KB when BASE64 encoded (384KB when decoded).

Glossary

For the terms, definitions, acronyms and abbreviations used in this document, refer to CUDB Glossary of Terms and Acronyms, Reference [10].

Reference List