The Application Configuration Management Profile applies to the actors LDAP Server, LDAP Client, and DNS Server. The mandatory and optional transactions are described in the table and sections below.
The normative definition of the schema can be found in Section H.1.3. This section gives additional informative descriptions of the objects and information defined in that schema and makes normative statements regarding DICOM system behavior.
The Application Configuration Data Model has the following component objects:
In addition there are a number of other objects used in the LDAP schema (see Section H.1.2 and Figure H.1-2) :
LDAP permits extensions to schema to support local needs (i.e., an object may implement a single structural and multiple auxiliary LDAP classes). DICOM does not mandate client support for such extensions. Servers may support such extensions for local purposes. DICOM Clients may accept or ignore extensions and shall not consider their presence an error.
The "device" is set of components organized to perform a task rather than a specific physical instance. For simple devices there may be one physical device corresponding to the Data Model device. But for complex equipment there may be many physical parts to one "device".
The "device" is the collection of physical entities that supports a collection of Application Entities. It is uniquely associated with these entities and vice versa. It is also uniquely associated with the network connections and vice versa. In a simple workstation with one CPU, power connection, and network connection the "device" is the workstation.
An example of a complex device is a server built from a network of multiple computers that have multiple network connections and independent power connections. This would be one device with one application entity and multiple network connections. Servers like this are designed so that individual component computers can be replaced without disturbing operations. The Application Configuration Data Model does not describe any of this internal structure. It describes the network connections and the network visible Application Entities. These complex devices are usually designed for very high availability, but in the unusual event of a system shutdown the "device" corresponds to all the parts that get shut down.
Table H.1-2. Attributes of Device Object
|
A unique name (within the scope of the LDAP database) for this device. It is restricted to legal LDAP names, and not constrained by DICOM AE Title limitations. |
||
|
Should be the same as the Value of Manufacturer (0008,0070) in SOP instances created by this device. |
||
|
Should be the same as the Value of Manufacturer Model Name (0008,1090) in SOP instances created by this device. |
||
|
Should be the same as the Values of Software Versions (0018,1020) in SOP instances created by this device. |
||
|
Should be the same as the Value of Station Name (0008,1010) in SOP instances created by this device. |
||
|
Should be the same as the Value of Device Serial Number (0018,1000) in SOP instances created by this device. |
||
|
Represents the kind of device and is most applicable for acquisition modalities. Types should be selected from the list of codes for Code Value (0008,0100) for CID 30 “DICOM Device” when applicable. |
||
|
Should be the same as the Value of Institution Name (0008,0080) in SOP Instances created by this device. |
||
|
Should be the same as the Value of Institution Address (0008,0081) attribute in SOP Instances created by this device. |
||
|
Should be the same as the Value of Institutional Department Name (0008,1040) in SOP Instances created by this device. |
||
|
Should be the same as the Value of Institutional Department Type Code Sequence (0008,1041) in SOP Instances created by this device. |
||
|
Default Value for the Issuer of Patient ID (0010,0021) for SOP Instances created by this device. May be overridden by the values received in a worklist or other source. |
||
|
The DNs of related device descriptions outside the DICOM Configuration hierarchy. Can be used to link the DICOM Device object to additional LDAP objects instantiated from other schema and used for separate administrative purposes. |
||
|
The DNs for the certificates of nodes that are authorized to connect to this device. The DNs need not be within the DICOM configuration hierarchy. |
||
|
The DNs of the public certificate(s) for this node. The DNs need not be within the DICOM configuration hierarchy. |
||
|
Boolean to indicate whether this device is presently installed on the network. (This is useful for pre-configuration, mobile vans, and similar situations.) |
The "Authorized Node Certificate Reference" is intended to allow the LDAP server to provide the list of certificates for nodes that are authorized to communicate with this device. These should be the public certificates only. This list need not be complete. Other network peers may be authorized by other mechanisms.
The "This Node Certificate Reference" is intended to allow the LDAP server to provide the certificate(s) for this node. These may also be handled independently of LDAP.
Note
A device may have multiple Primary Device Type entries. It may be a multifunctional device, e.g., combined PET and CT. It may be a cascaded device, e.g., image capture and ultrasound.
Table H.1-3. Child Objects of Device Object
|
The application entities available on this device (see Section H.1.1.2) |
||
|
The network connections for this device (see Section H.1.1.3) |
A Network AE is an application entity that provides services on a network. A Network AE will have the same functional capability regardless of the particular network connection used. If there are functional differences based on selected network connection, then these are separate Network AEs. If there are functional differences based on other internal structures, then these are separate Network AEs.
Table H.1-4. Attributes of Network AE Object
|
Locally defined names for a subset of related applications. E.g. "neuroradiology". |
||
|
A Boolean value. True if the Network AE can accept associations, false otherwise. |
||
|
A Boolean value. True if the Network AE can accept associations, false otherwise. |
||
|
The Character Set(s) supported by the Network AE for Data Sets it receives. The value shall be selected from the Defined Terms for Specific Character Set (0008,0005) in PS3.3. If no values are present, this implies that the Network AE supports only the default character repertoire (ISO IR 6). |
||
|
A Boolean value. True if the AE is installed on network. If not present, information about the installed status of the AE is inherited from the device |
The "Application Cluster" concept provides the mechanism to define local clusters of systems. The use cases for Configuration Management require a "domain" capability for DICOM applications that would be independent of the network topology and administrative domains that are used by DNS and other TCP level protocols. The Application Cluster is multi-valued to permit multiple clustering concepts for different purposes. It is expected to be used as part of a query to limit the scope of the query.
The "Preferred Called AE Title" concept is intended to allow a site administrator to define a limited default set of AEs that are preferred for use as communication partners when initiating associations. This capability is particularly useful for large centrally administered sites to simplify the configuration possibilities and restrict the number of configured AEs for specific workflow scenarios. For example, the set of AEs might contain the AE Titles of assigned Printer, Archive, RIS and QA Workstations so that the client device could adapt its configuration preferences accordingly. The "Preferred Called AE Title" concept does not prohibit association initiation to unlisted AEs. Associations to unlisted AEs can be initiated if necessary.
The "Preferred Calling AE Title" concept is intended to allow a site administrator to define a default set of AEs that are preferred when accepting assocations. The "Preferred Calling AE Title" concept does not prohibit accepting associations from unlisted AEs.
The "Network Connection Reference" is a link to a separate Network Connection object. The referenced Network Connection object is a sibling the AE object (i.e., both are children of the same Device object).
Table H.1-5. Child Objects of Network AE Object
|
The Transfer Capabilities for this Network AE. See Section H.1.4 |
The "network connection" describes one TCP port on one network device. This can be used for a TCP connection over which a DICOM association can be negotiated with one or more Network AEs. It specifies the hostname and TCP port number. A network connection may support multiple Network AEs. The Network AE selection takes place during association negotiation based on the called and calling AE-titles.
Table H.1-6. Attributes of Network Connection Object
|
An arbitrary name for the Network Connections object. Can be a meaningful name or any unique sequence of characters. Can be used as the RDN. |
||
|
This is the DNS name for this particular connection. This is used to obtain the current IP address for connections. Hostname must be sufficiently qualified to be unambiguous for any client DNS user. |
||
|
The TCP port that the AE is listening on. (This may be missing for a network connection that only initiates associations.) |
||
|
The TLS CipherSuites that are supported on this particular connection. TLS CipherSuites shall be described using an [RFC 2246] string representation (e.g., "TLS_RSA_WITH_RC4_128_SHA") |
||
|
A Boolean value. True if the Network Connection is installed on the network. If not present, information about the installed status of the Network Connection is inherited from the device. |
Inclusion of a TLS CipherSuite in a Network Connection capable of accepting associations implies that the TLS protocol must be used to successfully establish an association on the Network Connection.
A single Network AE may be available on multiple network connections. This is often done at servers for availability or performance reasons. For example, at a hospital where each floor is networked to a single hub per floor, the major servers may have direct connections to each of the hubs. This provides better performance and reliability. If the server does not change behavior based on the particular physical network connection, then it can be described as having Network AEs that are available on all of these multiple network connections. A Network AE may also be visible on multiple TCP ports on the same network hardware port, with each TCP port represented as a separate network connection. This would allow, e.g., a TLS-secured DICOM port and a classical un-secured DICOM port to be supported by the same AE.
Each Network AE object has one or more Transfer Capabilities. Each transfer capability specifies the SOP class that the Network AE can support, the mode that it can utilize (SCP or SCU), and the Transfer Syntax(es) that it can utilize. A Network AE that supports the same SOP class in both SCP and SCU modes will have two Transfer Capabilities objects for that SOP class.
Table H.1-7. Attributes of Transfer Capability Object
This structural object class represents the root of the DICOM Configuration Hierarchy. Only a single object of this type should exist within an organizational domain. Clients can search for an object of this class to locate the root of the DICOM Configuration Hierarchy.
This structural object class represents the root of the DICOM Devices Hierarchy. Only a single object of this type should exist as a child of DICOM Configuration Root. Clients can search for an object of this class to locate the root of the DICOM Devices Hierarchy.
This structural object class represents the root of the Unique AE-Titles Registry Hierarchy. Only a single object of this type should exist as a child of the DICOM Configuration Root. Clients can search for an object of this class to locate the root of the Unique AE Titles Registry.
Table H.1-13. Child Objects of Unique AE Titles Registry Root Object
|
The unique AE Titles installed within this organizational domain (see Section H.1.1.8) |
This structural object class represents a Unique Application Entity Title. Objects of this type should only exist as children of the Unique AE-Titles Registry Root. The sole purpose of this object class is to enable allocation of unique AE Titles. All operational information associated with an AE Title is maintained within a separate Network AE object.
The LDAP structure is built upon a hierarchy of named objects. This hierarchy can vary from site to site. The DICOM configuration management function needs to find its objects within this hierarchy in a predictable manner. For this reason, three specific object classes are defined for the three objects at the top of the DICOM hierarchy. These three object classes must not be used in this tree relationship anywhere else in the LDAP hierarchy.
The DICOM portion of the hierarchy shall begin at a root object of class dicomConfigurationRoot with a Common Name of "DICOM Configuration". Below this object shall be two other objects:
-
An object of class dicomDevicesRoot with a Common Name of "Devices". This is the root of the tree of objects that correspond to the Application Configuration Data Model structure of Section H.1.1.
-
An object of class dicomUniqueAETitlesRegistryRoot with a common name of "Unique AE Titles Registry". This is the root of a flat tree of objects. Each of these objects is named with one of the AE titles that are presently assigned. This is the mechanism for finding available AE titles.
The three object classes dicomConfigurationRoot, dicomDevicesRoot, and dicomUniqueAETitleRegistryRoot are used by LDAP clients to establish the local root of the DICOM configuration information within an LDAP hierarchy that may be used for many other purposes.
Note
During system startup it is likely that the DICOM configuration application will do an LDAP search for an entry of object class dicomConfigurationRoot and then confirm that it has the dicomDevicesRoot and dicomUniqueAETitlesRegistryRoot entries directly below it. When it finds this configuration, it can then save the full location within the local LDAP tree and use that as the root of the DICOM tree.
The objects underneath the dicomUniqueAETitlesRegistryRoot are used to provide the uniqueness required for DICOM AE-titles. The dicomUniqueAETitle objects have a single attribute representing a unique AE Title. When a new AE-Title is required, a tentative new name is selected. The new name is reserved by using the LDAP create facility to create an object of class dicomUniqueAETitle with the new name under the AE-Title object. If this name is already in use, the create will fail. Otherwise, this reserves the name. LDAP queries can be used to obtain the list of presently assigned AE-titles by obtaining the list of all names under the dicomUniqueAETitlesRegistryRoot object.
Note
-
LDAP uses a root and relative hierarchical naming system for objects. Every object name is fully unique within the full hierarchy. This means that the names of the objects beneath "Unique AE Titles Registry" will be unique. It also means that the full names of Network AEs and Connections will be within their hierarchy context. E.g., the DN for one of the Network AEs in Figure H.1-2 would be:
-
In theory, multiple independent DICOM configuration hierarchies could exist within one organization. The LDAP servers in such a network should constrain local device accesses so that DICOM configuration clients have only one DICOM Configuration Hierarchy visible to each client.
-
The merger of two organizations will require manual configuration management to merge DICOM Configuration hierarchies. There are likely to be conflicts in AE-titles, roles, and other conflicts.
The individual LDAP attribute information is summarized in the comments at the beginning of the schema below. The formal definition of the objects and the attributes is in the schema below. This schema may be extended by defining an additional schema that defines auxiliary classes, sub-classes derived from this schema, or both.
The formal LDAP schema for the Application Configuration Data Model and the DICOM Configuration Hierarchy is:
# 3 Attribute Type Definitions
#
# The following attribute types are defined in this document:
#
# Name Syntax Multiplicity
# -------------------------------- ------ ------------
# dicomDeviceName string Single
# dicomDescription string Single
# dicomManufacturer string Single
# dicomManufacturerModelName string Single
# dicomSoftwareVersion string Multiple
# dicomVendorData binary Multiple
# dicomAETitle string Single
# dicomNetworkConnectionReference DN Multiple
# dicomApplicationCluster string Multiple
# dicomAssociationInitiator bool Single
# dicomAssociationAcceptor bool Single
# dicomHostname string Single
# dicomPort integer Single
# dicomSOPClass OID Single
# dicomTransferRole string Single
# dicomTransferSyntax OID Multiple
# dicomPrimaryDeviceType string Multiple
# dicomRelatedDeviceReference DN Multiple
# dicomPreferredCalledAETitle string Multiple
# dicomTLSCipherSuite string Multiple
# dicomAuthorizedNodeCertificateReference DN Multiple
# dicomThisNodeCertificateReference DN Multiple
# dicomInstalled bool Single
# dicomStationName string Single
# dicomDeviceSerialNumber string Single
# dicomInstitutionName string Multiple
# dicomInstitutionAddress string Multiple
# dicomInstitutionDepartmentName string Multiple
# dicomIssuerOfPatientID string Single
# dicomPreferredCallingAETitle string Multiple
# dicomSupportedCharacterSet string Multiple
# dicomInstitutionDepartmentType string Multiple
#
# 3.1 dicomDeviceName string Single
#
# This attribute stores the unique name (within the scope of the LDAP database)
# for a DICOM Device.
#
# It is a single-valued attribute.
# This attribute's syntax is 'Directory String'.
# Its case is not significant for equality and substring matches.
#
attributetype ( 1.2.840.10008.15.0.3.1
NAME 'dicomDeviceName'
DESC 'The unique name for the device'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
# 3.2 dicomDescription string Single
#
# This attribute stores the (unconstrained) textual description for a DICOM entity.
#
# It is a single-valued attribute.
# This attribute's syntax is 'Directory String'.
# Its case is not significant for equality and substring matches.
#
attributetype ( 1.2.840.10008.15.0.3.2
NAME 'dicomDescription'
DESC 'Textual description of the DICOM entity'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
# 3.3 dicomManufacturer string Single
#
# This attribute stores the Manufacturer name for a DICOM Device.
# Should be identical to the Value of the DICOM attribute Manufacturer (0008,0070) [VR=LO]
# contained in SOP Instances created by this device.
#
# It is a single-valued attribute.
# This attribute's syntax is 'Directory String'.
# Its case is not significant for equality and substring matches.
#
attributetype ( 1.2.840.10008.15.0.3.3
NAME 'dicomManufacturer'
DESC 'The device Manufacturer name'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
# 3.4 dicomManufacturerModelName string Single
#
# This attribute stores the Manufacturer Model Name for a DICOM Device.
# Should be identical to the Value of the DICOM attribute Manufacturer
# Model Name (0008,1090) [VR=LO]
# contained in SOP Instances created by this device.
#
# It is a single-valued attribute.
# This attribute's syntax is 'Directory String'.
# Its case is not significant for equality and substring matches.
#
attributetype ( 1.2.840.10008.15.0.3.4
NAME 'dicomManufacturerModelName'
DESC 'The device Manufacturer Model Name'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
# 3.5 dicomSoftwareVersion string Multiple
#
# This attribute stores the software version of the device and/or its subcomponents.
# Should be the same as the Values of Software Versions (0018,1020) in
# SOP instances created by this device.
#
# It is a multi-valued attribute.
# This attribute's syntax is 'Directory String'.
# Its case is not significant for equality and substring matches.
#
attributetype ( 1.2.840.10008.15.0.3.5
NAME 'dicomSoftwareVersion'
DESC 'The device software version. Should be the same as the Values of Software
Versions (0018,1020) in SOP instances created by this device.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# 3.6 dicomVendorData binary Multiple
#
# This attribute stores vendor specific configuration information.
#
# It is a multi-valued attribute.
# This attribute's syntax is 'Binary'.
# Neither equality nor substring matches are applicable to binary data.
#
attributetype ( 1.2.840.10008.15.0.3.6
NAME 'dicomVendorData'
DESC 'Arbitrary vendor-specific configuration information (binary data)'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
# 3.7 dicomAETitle name Single
#
# This attribute stores an Application Entity (AE) title.
#
# It is a single-valued attribute.
# This attribute's syntax is 'IA5 String'.
# Its case is significant.
#
attributetype ( 1.2.840.10008.15.0.3.7
NAME 'dicomAETitle'
DESC 'Application Entity (AE) title'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )
# 3.8 dicomNetworkConnectionReference DN Multiple
#
# This attribute stores the DN of a dicomNetworkConnection object
# used by an Application Entity.
#
# It is a multi-valued attribute.
# This attribute's syntax is 'Distinguished Name'.
#
attributetype ( 1.2.840.10008.15.0.3.8
NAME 'dicomNetworkConnectionReference'
DESC 'The DN of a dicomNetworkConnection object used by an Application Entity'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
# 3.9 dicomApplicationCluster string Multiple
#
# This attribute stores an application cluster name for an Application
# Entity (e.g., "Neuroradiology Research")
#
# It is a multi-valued attribute.
# This attribute's syntax is 'Directory String'.
# Its case is not significant for equality and substring matches.
#
attributetype ( 1.2.840.10008.15.0.3.9
NAME 'dicomApplicationCluster'
DESC 'Application cluster name for an Application Entity (e.g., "Neuroradiology Research")'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# 3.10 dicomAssociationInitiator bool Single
#
# This attribute indicates if an Application Entity is capable of initiating
# network associations.
#
# It is a single-valued attribute.
# This attribute's syntax is 'Boolean'.
#
attributetype ( 1.2.840.10008.15.0.3.10
NAME 'dicomAssociationInitiator'
DESC 'Indicates if an Application Entity is capable of initiating network associations'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
# 3.11 dicomAssociationAcceptor bool Single
#
# This attribute indicates if an Application Entity is capable of accepting
# network associations.
#
# It is a single-valued attribute.
# This attribute's syntax is 'Boolean'.
#
attributetype ( 1.2.840.10008.15.0.3.11
NAME 'dicomAssociationAcceptor'
DESC 'Indicates if an Application Entity is capable of accepting network associations'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
# 3.12 dicomHostname string Single
#
# This attribute stores a DNS hostname for a connection.
#
# It is a single-valued attribute.
# This attribute's syntax is 'Directory String'.
# Its case is not significant for equality and substring matches.
#
attributetype ( 1.2.840.10008.15.0.3.12
NAME 'dicomHostname'
DESC 'DNS hostname'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
# 3.13 dicomPort integer Single
#
# This attribute stores a TCP port number for a connection.
#
# It is a single-valued attribute.
# This attribute's syntax is 'Integer'.
#
attributetype ( 1.2.840.10008.15.0.3.13
NAME 'dicomPort'
DESC 'TCP Port number'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
# 3.14 dicomSOPClass OID Single
#
# This attribute stores a SOP Class UID
#
# It is a single-valued attribute.
# This attribute's syntax is 'OID'.
#
attributetype ( 1.2.840.10008.15.0.3.14
NAME 'dicomSOPClass'
DESC 'A SOP Class UID'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
SINGLE-VALUE )
# 3.15 dicomTransferRole String Single
#
# This attribute stores a transfer role (either "SCU" or "SCP").
#
# It is a single-valued attribute.
# This attribute's syntax is 'Directory String'.
# Its case is not significant for equality and substring matches.
#
attributetype ( 1.2.840.10008.15.0.3.15
NAME 'dicomTransferRole'
DESC 'Transfer role (either "SCU" or "SCP")'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
# 3.16 dicomTransferSyntax OID Multiple
#
# This attribute stores a Transfer Syntax UID
#
# It is a multi-valued attribute.
# This attribute's syntax is 'OID'.
#
attributetype ( 1.2.840.10008.15.0.3.16
NAME 'dicomTransferSyntax'
DESC 'A Transfer Syntax UID'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
# 3.17 dicomPrimaryDeviceType string Multiple
#
# This attribute stores the primary type for a DICOM Device.
# Types should be selected from the list of code values (0008,0100)
# for Context ID 30 in DICOM Part 16 when applicable.
#
# It is a multiple-valued attribute.
# This attribute's syntax is 'IA5 String'.
# Its case is significant.
#
attributetype ( 1.2.840.10008.15.0.3.17
NAME 'dicomPrimaryDeviceType'
DESC 'The device Primary Device type'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
# 3.18 dicomRelatedDeviceReference DN Multiple
#
# This attribute stores a reference to a related device description outside
# the DICOM Configuration Hierachy. Can be used to link the DICOM Device object to
# additional LDAP objects instantiated from other schema and used for
# separate administrative purposes.
#
# This attribute's syntax is 'Distinguished Name'.
# It is a multiple-valued attribute.
#
attributetype ( 1.2.840.10008.15.0.3.18
NAME 'dicomRelatedDeviceReference'
DESC 'The DN of a related device description outside the DICOM Configuration Hierachy'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
# 3.19 dicomPreferredCalledAETitle string Multiple
#
# AE Title(s) to which associations may be preferably initiated.
#
# It is a multiple-valued attribute.
# This attribute's syntax is 'IA5 String'.
# Its case is significant.
#
attributetype ( 1.2.840.10008.15.0.3.19
NAME 'dicomPreferredCalledAETitle'
DESC 'AE Title(s) to which associations may be preferably initiated.'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
# 3.20 dicomTLSCipherSuite string Multiple
#
# The attribute stores the supported TLS CipherSuites.
# TLS CipherSuites shall be described using a RFC-2246 string representation
# (e.g., "TLS_RSA_WITH_RC4_128_SHA").
#
# It is a multiple-valued attribute.
# This attribute's syntax is 'IA5 String'.
# Its case is significant.
#
attributetype ( 1.2.840.10008.15.0.3.20
NAME 'dicomTLSCipherSuite'
DESC 'The supported TLS CipherSuites'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
# 3.21 dicomAuthorizedNodeCertificateReference DN Multiple
#
# This attribute stores a reference to a TLS public certificate for a DICOM
# node that is authorized to connect to this node. The certificate
# is not necessarily stored within the DICOM Hierarchy
#
# This attribute's syntax is 'Distinguished Name'.
# It is a multiple-valued attribute.
#
attributetype ( 1.2.840.10008.15.0.3.21
NAME 'dicomAuthorizedNodeCertificateReference'
DESC 'The DN of a Certificate for a DICOM node that is authorized to connect to this node'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
# 3.22 dicomThisNodeCertificateReference DN Multiple
#
# This attribute stores a reference to a TLS public certificate for
# this node. It is not necessarily stored as part of
# the DICOM Configuration Hierachy.
#
# This attribute's syntax is 'Distinguished Name'.
# It is a multiple-valued attribute.
#
attributetype ( 1.2.840.10008.15.0.3.22
NAME 'dicomThisNodeCertificateReference'
DESC 'The DN of a related device description outside the DICOM Configuration Hierachy'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
# 3.23 dicomInstalled bool Single
#
# This attribute indicates whether the object is presently installed.
#
# It is a single-valued attribute.
# This attribute's syntax is 'Boolean'.
#
attributetype ( 1.2.840.10008.15.0.3.23
NAME 'dicomInstalled'
DESC 'Indicates if the DICOM object (device, Network AE, or Port) is presently installed'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
# 3.24 dicomStationName string Single
#
# This attribute stores the station name of the device.
# Should be the same as the value of Station Name (0008,1010) in
# SOP instances created by this device.
#
# It is a single-valued attribute.
# This attribute's syntax is 'Directory String'.
#
attributetype ( 1.2.840.10008.15.0.3.24
NAME 'dicomStationName'
DESC 'Station Name of the device. Should be the same as the value of Station
Name (0008,1010) in SOP instances created by this device.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE)
# 3.25 dicomDeviceSerialNumber string Single
#
# This attribute stores the serial number of the device.
# Should be the same as the value of Device Serial Number (0018,1000)
# in SOP instances created by this device.
#
# It is a single-valued attribute.
# This attribute's syntax is 'Directory String'.
#
attributetype ( 1.2.840.10008.15.0.3.25
NAME 'dicomDeviceSerialNumber'
DESC 'Serial number of the device. Should be the same as the value of Device Serial
Number (0018,1000) in SOP instances created by this device.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE)
# 3.26 dicomInstitutionName string Multiple
#
# This attribute stores the institution name of the device.
# Should be the same as the value of Institution Name (0008,0080)
# in SOP Instances created by this device.
#
# It is a multi-valued attribute.
# This attribute's syntax is 'Directory String'.
#
attributetype ( 1.2.840.10008.15.0.3.26
NAME 'dicomInstitutionName'
DESC 'Institution name of the device. Should be the same as the value of Institution
Name (0008,0080) in SOP Instances created by this device.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# 3.27 dicomInstitutionAddress string Multiple
#
# This attribute stores the institution address of the device.
# Should be the same as the value of Institution Address (0008,0081)
# attribute in SOP Instances created by this device.
#
# It is a multi-valued attribute.
# This attribute's syntax is 'Directory String'.
#
attributetype ( 1.2.840.10008.15.0.3.27
NAME 'dicomInstitutionAddress'
DESC 'Institution address of the device. Should be the same as the value of Institution
Address (0008,0081) attribute in SOP Instances created by this device.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# 3.28 dicomInstitutionDepartmentName string Multiple
#
# This attribute stores the institution department name of the device.
# Should be the same as the value of Institutional Department Name (0008,1040)
# in SOP Instances created by this device.
#
# It is a multi-valued attribute.
# This attribute's syntax is 'Directory String'.
#
attributetype ( 1.2.840.10008.15.0.3.28
NAME 'dicomInstitutionDepartmentName'
DESC 'Institution department name of the device. Should be the same as the value of Institutional
Department Name (0008,1040) in SOP Instances created by this device.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# 3.29 dicomIssuerOfPatientID string Single
#
# This attribute stores the Default value for the Issuer of Patient ID (0010,0021)
# for SOP Instances created by this device. May be overridden by the values
# received in a worklist or other source.
#
# It is a multi-valued attribute.
# This attribute's syntax is 'Directory String'.
#
attributetype ( 1.2.840.10008.15.0.3.29
NAME 'dicomIssuerOfPatientID'
DESC 'Default value for the Issuer of Patient ID (0010,0021) for SOP Instances created by this device.
May be overridden by the values received in a worklist or other source.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# 3.30 dicomPreferredCallingAETitle string Multiple
#
# AE Title(s) to which associations may be preferably accepted.
#
# It is a multiple-valued attribute.
# This attribute's syntax is 'IA5 String'.
# Its case is significant.
#
attributetype ( 1.2.840.10008.15.0.3.30
NAME 'dicomPreferredCallingAETitle'
DESC 'AE Title(s) to which associations may be preferably accepted.'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
# 3.31 dicomSupportedCharacterSet string Multiple
#
# The Character Set(s) supported by the Network AE for Data Sets it receives.
# Contains one of the Defined Terms for Specific Character Set (0008,0005).
# If not present, this implies that the Network AE supports only the default
# character repertoire (ISO IR 6).
#
# It is a multiple-valued attribute.
# This attribute's syntax is 'IA5 String'.
# Its case is significant.
#
attributetype ( 1.2.840.10008.15.0.3.31
NAME 'dicomSupportedCharacterSet'
DESC 'The Character Set(s) supported by the Network AE for Data Sets it receives.'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
# 3.31 dicomInstitutionDepartmentType string Multiple
#
# This attribute stores the institution department type of the device.
# Should be the same as the value of Institutional Department Type Code
# Sequence (0008,1041) in SOP Instances created by this device.
# Types should be selected from the list of code values (0008,0100)
# for Context ID 7030 in DICOM Part 16 when applicable.
#
# It is a multi-valued attribute.
# This attribute's syntax is 'IA5 String'.
#
attributetype ( 1.2.840.10008.15.0.3.31
NAME 'dicomInstitutionDepartmentType'
DESC 'Institution department type of the device. Should be the same as the value of Institutional
Department Type Code Sequence (0008,1041) in SOP Instances created by this device.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
# 4 Object Class Definitions
#
# The following object classes are defined in this document. All are
# structural classes.
#
# Name Description
# --------------------------- --------------------------
# dicomConfigurationRoot root of the DICOM Configuration Hierarchy
# dicomDevicesRoot root of the DICOM Devices Hierarchy
# dicomUniqueAETitlesRegistryRoot root of the Unique DICOM AE-Titles Registry Hierarchy
# dicomDevice Devices
# dicomNetworkAE Network AE
# dicomNetworkConnection Network Connections
# dicomUniqueAETitle Unique AE Title
# dicomTransferCapability Transfer Capability
#
# 4.1 dicomConfigurationRoot
#
# This structural object class represents the root of the DICOM Configuration Hierarchy.
# Only a single object of this type should exist within an organizational domain.
# Clients can search for an object of this class to locate the root of the
# DICOM Configuration Hierarchy.
#
objectclass ( 1.2.840.10008.15.0.4.1
NAME 'dicomConfigurationRoot'
DESC 'Root of the DICOM Configuration Hierarchy'
SUP top
STRUCTURAL
MUST ( cn )
MAY ( description ) )
#
# 4.2 dicomDevicesRoot
#
# This structural object class represents the root of the DICOM Devices Hierarchy.
# Only a single object of this type should exist as a child of dicomConfigurationRoot.
#
objectclass ( 1.2.840.10008.15.0.4.2
NAME 'dicomDevicesRoot'
DESC 'Root of the DICOM Devices Hierarchy'
SUP top
STRUCTURAL
MUST ( cn )
MAY ( description ) )
#
# 4.3 dicomUniqueAETitlesRegistryRoot
#
# This structural object class represents the root of the Unique DICOM AE-Titles
# Registry Hierarchy.
# Only a single object of this type should exist as a child of dicomConfigurationRoot.
#
objectclass ( 1.2.840.10008.15.0.4.3
NAME 'dicomUniqueAETitlesRegistryRoot'
DESC 'Root of the Unique DICOM AE-Title Registry Hierarchy'
SUP top
STRUCTURAL
MUST ( cn )
MAY ( description ) )
#
# 4.4 dicomDevice
#
# This structural object class represents a DICOM Device.
#
objectclass ( 1.2.840.10008.15.0.4.4
NAME 'dicomDevice'
DESC 'DICOM Device related information'
SUP top
STRUCTURAL
MUST (
dicomDeviceName $
dicomInstalled )
MAY (
dicomDescription $
dicomManufacturer $
dicomManufacturerModelName $
dicomSoftwareVersion $
dicomStationName $
dicomDeviceSerialNumber $
dicomInstitutionName $
dicomInstitutionAddress $
dicomInstitutionDepartmentName $
dicomIssuerOfPatientID $
dicomVendorData $
dicomPrimaryDeviceType $
dicomRelatedDeviceReference $
dicomAuthorizedNodeCertificateReference $
dicomThisNodeCertificateReference) )
#
# 4.5 dicomNetworkAE
#
# This structural object class represents a Network Application Entity
#
objectclass ( 1.2.840.10008.15.0.4.5
NAME 'dicomNetworkAE'
DESC 'DICOM Network AE related information'
SUP top
STRUCTURAL
MUST (
dicomAETitle $
dicomNetworkConnectionReference $
dicomAssociationInitiator $
dicomAssociationAcceptor )
MAY (
dicomDescription $
dicomVendorData $
dicomApplicationCluster $
dicomPreferredCalledAETitle $
dicomPreferredCallingAETitle $
dicomSupportedCharacterSet $
dicomInstalled ) )
#
# 4.6 dicomNetworkConnection
#
# This structural object class represents a Network Connection
#
objectclass ( 1.2.840.10008.15.0.4.6
NAME 'dicomNetworkConnection'
DESC 'DICOM Network Connection information'
SUP top
STRUCTURAL
MUST ( dicomHostname )
MAY (
cn $
dicomPort $
dicomTLSCipherSuite $
dicomInstalled ) )
#
# 4.7 dicomUniqueAETitle
#
# This structural object class represents a Unique Application Entity Title
#
objectclass ( 1.2.840.10008.15.0.4.7
NAME 'dicomUniqueAETitle'
DESC 'A Unique DICOM Application Entity title'
SUP top
STRUCTURAL
MUST ( dicomAETitle ) )
#
# 4.8 dicomTransferCapability
#
# This structural object class represents Transfer Capabilities for an Application Entity
#
objectclass ( 1.2.840.10008.15.0.4.8
NAME 'dicomTransferCapability'
DESC 'Transfer Capabilities for an Application Entity'
SUP top
STRUCTURAL
MUST (
dicomSOPClass $
dicomTransferRole $
dicomTransferSyntax)
MAY (
cn) )
The [RFC 2782] A DNS RR for specifying the location of services (DNS SRV) specifies a mechanism for requesting the names and rudimentary descriptions for machines that provide network services. The DNS client requests the descriptions for all machines that are registered as offering a particular service name. In this case the service name requested will be "LDAP". The DNS server may respond with multiple names for a single request.
[RFC 2181] Clarifications to the DNS Specification
[RFC 2219] Use of DNS Aliases for Network Services
[RFC 2782] A DNS RR for specifying the location of services (DNS SRV)
other RFC's are included by reference from [RFC 2181], [RFC 2219], and [RFC 2782].
The DNS client shall request a list of all the LDAP servers available. It will use the priority, capacity, and location information provided by DNS to select a server ([RFC 2782] recommends the proper use of these parameters). It is possible that there is no LDAP server, or that the DNS server does not support the SRV RR request.
Note
-
Multiple LDAP servers providing access to a common replicated LDAP database is a commonly supported configuration. This permits LDAP servers to be located where appropriate for best performance and fault tolerance. The DNS server response information provides guidance for selecting the most appropriate server.
-
There may also be multiple LDAP servers providing different databases. In this situation the client may have to examine several servers to find the one that supports the DICOM configuration database. Similarly a single LDAP server may support multiple base DNs, and the client will need to check each of these DNs to determine which is the DICOM supporting tree.
The [RFC 2251] "Lightweight Directory Access Protocol (v3)" specifies a mechanism for making queries of a database corresponding to an LDAP schema. The LDAP client can compose requests in the LDAP query language, and the LDAP server will respond with the results for a single request.
[RFC 2251] Lightweight Directory Access Protocol (v3). LDAP support requires compliance with other RFC's invoked by reference.
The LDAP client may make a wide variety of queries and cascaded queries using LDAP. The LDAP client and server shall support the Application Configuration Data Model .
Note
Multiple LDAP servers providing access to a common replicated LDAP database is a commonly supported configuration. This permits LDAP servers to be located where appropriate for best performance and fault tolerance. The replications rules chosen for the LDAP servers affect the visible data consistency. LDAP permits inconsistent views of the database during updates and replications.
The [RFC 2251] "Lightweight Directory Access Protocol (v3)" specifies a mechanism for making updates to a database corresponding to an LDAP schema. The LDAP client can compose updates in the LDAP query language, and the LDAP server will respond with the results for a single request. Update requests may be refused for security reasons.
[RFC 2251] Lightweight Directory Access Protocol (v3). LDAP support requires compliance with other RFC's invoked by reference.
The LDAP client may make a request to update the LDAP database. The LDAP client shall support the data model described above. The LDAP server may choose to refuse the update request for security reasons. If the LDAP server permits update requests, is shall support the data model described above.
Note
Multiple LDAP servers providing access to a common replicated LDAP database is a commonly supported configuration. This permits LDAP servers to be located where appropriate for best performance and fault tolerance. Inappropriate selection of replication rules in the configuration of the LDAP server will result in failure for AE-title uniqueness when creating the AE-titles objects.
The creation of a new Network AE requires special action. The following steps shall be followed:
-
A tentative AE title shall be selected. Various algorithms are possible, ranging from generating a random name to starting with a preset name template and incrementing a counter field. The client may query the Unique AE Titles Registry sub-tree to obtain the complete list of names that are presently in use as part of this process.
-
A new Unique AE Title object shall be created in the Unique AE Titles Registry portion of the hierarchy with the tentative name. The LDAP server enforces uniqueness of names at any specific point in the hierarchy.
-
If the new object creation was successful, this shall be the AE Title used for the new Network AE.
-
If the new object creation fails due to non-unique name, return to a) and select another name.
The LDAP server shall support a separate manual or automated means of maintaining the LDAP database contents. The LDAP server shall support the [RFC 2849] file format mechanism for updating the LDAP database. The LDAP Client or service installation tools shall provide [RFC 2849] formatted files to update LDAP server databases manually. The LDAP server may refuse client network updates for security reasons. If this is the case, then the maintenance process will be used to maintain the LDAP database.
The manual update procedures are not specified other than the requirement above that at least the minimal LDAP information exchange file format from [RFC 2849] be supported. The exact mechanisms for transferring this information remain vendor and site specific. In some situations, for example the creation of AE-titles, a purely manual update mechanism may be easier than exchanging files.
The conformance statement shall document the mechanisms available for transferring this information. Typical mechanisms include:
Note
-
There are many automated and semi-automatic tools for maintaining LDAP databases. Many LDAP servers provide GUI interfaces and updating tools. The specifics of these tools are outside the scope of DICOM. The LDAP [RFC 2849] requires at least a minimal data exchange capability. There are also XML based tools for creating and maintaining these files.
-
This mechanism may also be highly effective for preparing a new network installation by means of a single pre-planned network configuration setup rather than individual machine updates.
The threat and value for the LDAP based configuration mechanisms fall into categories:
These each pose different vulnerabilities to attack. These are:
-
-
The AE-title uniqueness mechanism could be attacked by creating vast numbers of spurious AE-titles. This could be a Denial of Service (DoS) attack on the LDAP server. It has a low probability of interfering with DICOM operations.
-
The Network AE information could be maliciously updated. This would interfere with DICOM operations by interfering with finding the proper server. It could direct connections to malicious nodes, although the use of TLS authentication for DICOM connections would detect such misdirection. When TLS authentication is in place this becomes a DoS attack.
-
The device descriptions could be maliciously modified. This would interfere with proper device operation.
-
-
-
There is no apparent value to an attacker in obtaining the current list of AE-titles. This does not indicate where these AE-titles are deployed or on what equipment.
-
The Network AE information and device descriptions might be of value in determining the location of vulnerable systems. If it is known that a particular model of equipment from a particular vendor is vulnerable to a specific attack, then the Network AE Information can be used to find that equipment.
-
The security mechanisms for LDAP are highly variable in actual implementations. They are a mixture of administrative restrictions and protocol implementations. The widely available options for security methods are:
-
Anonymous access, where there is no restriction on performing this function over the network.
-
Basic, where there is a username and password exchange prior to granting access to this function. The exchange is vulnerable to snooping, spoofing, and man in the middle attacks.
-
TLS, where there is an SSL/TLS exchange during connection establishment.
-
Manual, where no network access is permitted and the function must be performed manually at the server, or semi-automatically at the server. The semi-automatic means permit the use of independently exchanged files (e.g., via floppy) together with manual commands at the server.
The categories of functions that may be independently controlled are:
Finally, these rules may be applied differently to different subtrees within the overall LDAP structure. The specific details of Access Control Lists (ACLs), functional controls, etc. vary somewhat between different LDAP implementations.
The LDAP server should be able to specify different restrictions for the AE-Title list and for the remainder of the configuration information. To facilitate interoperability, Table H.1-15 defines several patterns for access control. They correspond to different assessments of risk for a network environment.
- TLS
-
This pattern provides SSL/TLS authentication and encryption between client and server. It requires additional setup during installation because the TLS certificate information needs to be installed onto the client machines and server. Once the certificates are installed the clients may then perform full updating operations.
- TLS-Manual
-
This pattern provides SSL/TLS controls for read access to information and require manual intervention to perform update and creation functions.
- Basic
-
This pattern utilizes the LDAP basic security to gain access to the LDAP database. It requires the installation of a password during client setup. It does not provide encryption protection. Once the password is installed, the client can then perform updates.
- Basic-Manual
-
This pattern utilizes basic security protection for read access to the configuration information and requires manual intervention to perform update and creation functions.
- Anonymous
-
This pattern permits full read/update access to all machines on the network.
- Anonymous-Manual
-
This pattern permits full read access to all machines on the network, but requires manual intervention to perform update and creation.
A client or server implementation may be capable of being configured to support multiple patterns. This should be documented in the conformance claim. The specific configuration in use at a specific site can then be determined at installation time.
The LDAP database can be used as a documentation tool. Documenting the configuration for both managed and legacy machines makes upgrading easier and reduces the error rate for manually configured legacy equipment.
There are various possible implementation strategies for clients performing lookups within the LDAP database. For example, before initiating a DICOM association to a specific AE, a client implementation could either:
The advantages of maintaining a local cache include performance (by avoiding frequent lookups) and reliability (should the LDAP server be temporarily unavailable). The disadvantage of a cache is that it can become outdated over time. Client implementations should provide appropriate mechanisms to purge locally cached information.
Client caches may cause confusion during updates. Manual steps may be needed to trigger immediate updates. LDAP database replication also may introduce delays and inconsistencies. Database replication may also require manual intervention to force updates to occur immediately.
One strategy to reduce client cache problems is to re-acquire new DNS and LDAP information after any network association information. Often the first symptom of stale cache information is association failures due to the use of obsolete configuration information.
Some LDAP servers do not support a "modify DN" operation. For example, in the case of renaming a device on such a server, a tree copy operation may be needed to create a new object tree using the new name, followed by removal of the old object tree. After such a rename the device may need to search using other attributes when finding its own configuration information, e.g., the device serial number.