There are several ways that the LDAP configuration information can be obtained.
A complete installation may be pre-designed and the full configuration loaded into the LDAP server, with the installation attribute set to false. Then as systems are installed, they acquire their own configurations from the LDAP server. The site administration can set the installation attribute to true when appropriate.
When the LDAP server permits network clients to update the configuration, they can be individually installed and configured. Then after each device is configured, that device uploads its own configuration to the LDAP server.
When the LDAP server does not permit network clients to update configurations, they can be individually installed and configured. Then, instead of uploading their own configuration, they create a standard format file with their configuration objects. This file is then manually added to the LDAP server (complying with local security procedures) and any conflicts resolved manually.
The network may have been designed in advance and the configuration specified in advance. It should be possible to pre-configure the configuration servers prior to other hardware installation. This should not preclude later updates or later configuration at specific devices.
LDAP defines a standard file exchange format for transmitting LDAP database subsets in an ASCII format. This file exchange format can be created by a variety of network configuration tools. There are also systems that use XML tools to create database subsets that can be loaded into LDAP servers. It is out of scope to specify these tools in any detail. The use case simply requires that such tools be available.
When the LDAP database is preconfigured using these tools, it is the responsibility of the tools to ensure that the resulting database entries have unique names. The unique name requirement is common to any LDAP database and not just to DICOM AE-titles. Consequently, most tools have mechanisms to ensure that the database updates that they create do have unique names.
Figure R.1-1 System Installation with Pre-configured Configuration
At an appropriate time, the installed attribute is set on the device objects in the LDAP configuration.
The “unconfigured” device startup begins with use of the pre-configured services from DHCP, DNS, and NTP. It then performs device configuration and updates the LDAP database. This description assumes that the device has been given permission to update the LDAP database directly.
DHCP is used to obtain IP related parameters. The DHCP request can indicate a desired machine name that DHCP can associate with a configuration saved at the DHCP server. DHCP does not guarantee that the desired machine name will be granted because it might already be in use, but this mechanism is often used to maintain specific machine configurations. The DHCP will also update the DNS server (using the DDNS mechanisms) with the assigned IP address and hostname information.Legacy note: A machine with pre-configured IP addresses, DNS servers, and NTP servers may skip this step. As an operational and documentation convenience, the DHCP server database may contain the description of this pre-configured machine.
The list of NTP servers is used to initiate the NTP process for obtaining and maintaining the correct time. This is an ongoing process that continues for the duration of device activity. See Time Synchronization below.
The list of DNS servers is used to obtain the address of the DNS servers at this site. Then the DNS servers are queried to get the list of LDAP servers. This utilizes a relatively new addition to the DNS capabilities that permit querying DNS to obtain servers within a domain that provide a particular service.
The LDAP servers are queried to find the server that provides DICOM configuration services, and then obtain a description for the device matching the assigned machine name. This description includes device specific configuration information and a list of Network AEs. For the unconfigured device there will be no configuration found.
Note: These first four steps are the same as a normal startup (described below).
Through a device specific process it determines its internal AE structure. During initial device installation it is likely that the LDAP database lacks information regarding the device. Using some vendor specific mechanism, e.g. service procedures, the device configuration is obtained. This device configuration includes all the information that will be stored in the LDAP database. The fields for “device name” and “AE Title” are tentative at this point.
Each of the Network AE objects is created by means of the LDAP object creation process. It is at this point that LDAP determines whether the AE Title is in fact unique among all AE Titles. If the title is unique, the creation succeeds. If there is a conflict, the creation fails and “name already in use” is given as a reason.LDAP uses propose/create as an atomic operation for creating unique items. The LDAP approach permits unique titles that comply with algorithms for structured names, check digits, etc. DICOM does not require structured names, but they are a commonplace requirement for other LDAP users. It may take multiple attempts to find an unused name.This multiple probe behavior can be a problem if “unconfigured device” is a common occurrence and name collisions are common. Name collisions can be minimized at the expense of name structure by selecting names such as “AExxxxxxxxxxxxxx” where “xxxxxxxxxxxxxx” is a truly randomly selected number. The odds of collision are then exceedingly small, and a unique name will be found within one or two probes.
The device object is created. The device information is updated to reflect the actual AE titles of the AE objects. As with AE objects, there is the potential for device name collisions.
The network connection objects are created as subordinates to the device object.
The AE objects are updated to reflect the names of the network connection objects.
The “unconfigured device” now has a saved configuration. The LDAP database reflects its present configuration.
In the following example, the new system needs two AE-titles. During its installation another machine is also being installed and takes one of the two AE-titles that the first machine expected to use. The new system then claims another different AE-title that does not conflict.
Figure R.1-2 – Configuring a System when network LDAP updates are permitted
Much of the initial startup is the same for restarting a configured device and for configuring a client first and then updating the server. The difference is two-fold.
The AE-title uniqueness must be established manually, and the configuration information saved at the client onto a file that can then be provided to the LDAP server. There is a risk that the manually assigned AE-title is not unique, but this can be managed and is easier than the present entirely manual process for assigning AE-titles.
Figure R.1-3 Configuring a system when LDAP network updates are not permitted