In regular LDAP search operations, a query with scope set to 'wholeSubtree' requires to fully scan the complete subtree of descendant entries before applying the filter expression to those child objects. Those kind of queries usually have a performance impact as the size of the subtree gets bigger (more time and resources for drilling down all the populated descendants).

The Optimized Subtree Searches function can be used to selectively specify and refine the original request to be performed over a given set of descendant entries of the baseObject or branches instead of scanning everything below the search base.

Optimized subtree queries are configured individually for those application frontends/LDAP users who would benefit from them.

This feature could also help to reduce number of queries issued to retrieve a group of entries by using a single subtree operations but restricted to look up a subset of the entries in the subtree instead.

Figure 1 describes how subtree search works: A subtree query starting at mscId level would require to scan and evaluate the filter against all the entries in the orange box, even if the wanted entries are just the ones in the blue boxes.

With the Optimized Subtree searches it is possible to configure what entries evaluate instead of scanning the whole subtree, therefore performing the operation more efficiently.

Optimize Subtree Searches function is defined in configuration YAML file with following structure which follows subtree request from Figure 1:

hints:
   - hint:  HINT-1
     BaseDnPattern:  mscId=*,ou=multiscs,*
     Scope:               sub
     Filter:              (|(|(objectClass=EpsStaticInf)(objectClass=EpsDynInf))(objectClass=mscIdentities)(objectClass=AU1))
     staticTargets:
       - srdn:            serv=identities
       - srdn:            EpsStaInfId=EpsStaInf,serv=EPS
       - srdn:            EpsDynInfId=EpsDynInf,EpsStaInfId=EpsStaInf,serv=eps
       - srdn:            IMSI=*,serv=Auth
   - hint:  HINT-2
		.
		.
		.			

Configuration is defined with the following fields:

• There can be only one hints section with multiple hint sections. Each hint has a unique name inside its file, for example HINT-1.

• BaseDnPattern has value that matches baseObject dn in search request and it must not include alias entries. It supports wildcards for variable rdn value that are defined with '*' character e.g. mscid=*. Root dn of incoming request is likely to be different for different operators, so it may be a good idea to have BaseDnPattern ending with a wildcard also like in example above. That way the optimized subtree search configuration can be used in any operator.

• Scope represents the search scope of the incoming request .

• Filter represents the filter of the incoming request. It can contain a wildcard, but it will only work if the application sends a filter with a wildcard. It cannot match a fixed value with a wildcard like in case of BaseDnPattern.

• Section staticTargets contains srdn keys which are the relative RDNs starting from the baseObject in the searchRequest (or the BaseDnPattern here) where the entries of interest are, that is the entries where the wanted data is. Only entries specifed in this section will be returned, thus the base object will not be returned even if it fullfils filter. Attribute name in RDN must be known in advance, but RDN value can be unknown. In that case wildcard can be used for RDN value e.g. IMSI=*,serv=Auth. Such definition will return all entries one level below serv=Auth that have rdn attribute name IMSI.

Optimization will be applied under the following conditions:

1. Ldap user is configured with a subtree optimization.

2. Scope and filter of the incoming request are matching one of the hint definitions in the configuration file connected with the user.

3. The baseObject (possibly dereferenced) in the SearchRequest, matches BaseDnPattern of hint found in condition 2.

Standard behavior is applied if one of above conditions is not fulfilled.

Optimization is only applied to entries stored in DS, thus the srdn keys can only contain entries stored in DS. In case the wanted entry is non-distributed data (data stored in PLDB) accessed through DSG alias entry, then srdn section must contain DSG alias entry itself.

BaseDnPattern:  mscId=*,ou=multiscs,* 
- srdn:            AvgStaticInfId=AvgStaticInf,serv=Auth
- srdn:            AvgDynInfId=AvgDynInf, AvgStaticInfId=AvgStaticInf,serv=Auth