CA Directory r12.0 SP1 and later caters for the LDAP Server Side Sorting control by default when connecting directly to the data DSA that has the information required. There is a specific use case that deals with Router and data DSA's (used in a highly available DSA backbone). This techdoc discusses that high availability use case.
From r12.0 SP1 onwards, the LDAP Server Side Sorting control (1.2.840.1135220.127.116.113) is available when connecting directly to the data DSA to be searched.
In addition to directly connecting to the data DSA, the control is also supported when used in distributed directory backbones (e.g. submit a search to a router DSA that then routes the operation to a data DSA for execution). But please be aware that there is a very specific use case where a server side sorting control is supported when dealing with routers and data DSAs.
The two main use cases for distributed searching are:
Router receives a whole subtree search that has a base DN that falls within a remote data DSAs namespace (prefix)
- The router does not execute the search locally, but instead routes the operation to the single data DSA that can execute the operation.
- The router chains the entire operation, including the SSS (server-side-sort) control, to the data DSA.
- The data DSA executes the search, sorts the results and routes the search results back to the source of the operation (the router DSA in this case).
- As you can see the SSS control has been honored in this case.
- An example of the data DSA receiving a SSS sorting request from a router is below:
>  <- #0 [router] DSP SEARCH-REQ
>  invoke-id = 2147483635 credit = 4
>  Base object:
>  <countryName utf8 "AU">
>  <organizationName utf8 "Democorp">
>  Search subset: Whole subtree
>  Filter:
>  commonName substrings: initial: utf8 "C"
>  Don't Search Aliases
>  Chaining Arguments:
>  Trace Information:
>  DSA:
>  <commonName "router">
>  Operation Progress: Name Resolution Phase: Not Started
>  Controls:
>  server-side-sort surname
- Here is the tail end of the 'sorted' search result being passed back to the router DSA.
>  Entry: 8084
>  <countryName "AU">
>  <organizationName "Democorp">
>  <organizationalUnitName "users">
>  <cosineUserid "000000000006703">
>  Contents:
>  (cosineUserid "000000000006703")
>  (objectClass inetOrgPerson)
>  (surname "Yung")
>  (commonName "Chantalle.Yung")
>  (cosineRfc822Mailbox "[email protected]")
>  (localityName "Melbourne")
>  (telephoneNumber "111-958-6791")
>  (title "Chantalle.Yung")
>  Partial Outcome Qualifier:
>  Limit Problem: Admin limit exceeded
>  Chaining Results:
>  Controls:
>  server-side-sort-resp 0
- Please note the server-side-sort-resp control mentioned in the search results. This shows that the data DSA is honoring the SSS control in the routers search request.
Router receives a whole subtree search that has a base DN that falls within the routers namespace (prefix)
- This entails the router performing the search first.
- Then the router chains the operation to all subordinate DSAs (multi-casting the search).
- The router does not chain the server side sorting control in the search operations that are chained to the multiple data DSAs.
- The data DSAs still execute the search, but do not pass back the search results in sorted order.
- The router then combines the search results from all subordinate DSA's (unsorted) and sends the combined search results back to the LDAP client application (in unsorted order).
As you can see, the first use case performs the SSS search, and the second use case does not perform the SSS search. The second use case still performs the search, but the results are not sorted when sent back to the client app.