There is a one-to-one relationship between a TCP Transport Connection and an Upper Layer Association. Therefore, the following rules apply:
a) Each Upper Layer Association shall be supported by one and only one TCP Transport Connection.
b) Each TCP Transport Connection shall support one and only one Upper Layer Association.
The Services provided by the TCP Transport Services are not formally documented. This section, therefore, makes use of “commonly” used terms in a number of TCP Programming Interface Implementations (e.g. Sockets). However, the following RFCs shall be required for TCP/IP support. They specify the support needed for IPv4.
a) RFC 793, Transmission Control Program - DARPA Internet Protocol Specification
b) RFC 791, Internet Protocol - DARPA Internet Protocol Specification
c) RFC 792, Internet Control Message Protocol - DARPA Internet Program Protocol Specification
d) RFC 950, Internet Subnetting
In addition, devices that support IPv6 shall comply with:
a) RFC 1881, IPv6 Address Allocation Management
b) RFC 2460, Internet Protocol, Version 6 (IPv6) Specification
Note: There are many other RFC’s that may also apply to a particular implementation depending upon specific selections of hardware and software features.
For the establishment of a TCP connection, a TCP port shall be used to serve as the transport selector. A DICOM UL entity is identified on a given system on the network by a port number unique within the scope of this system. Port numbers of remote DICOM UL entities (well known port number or other numbers) shall be configurable on DICOM UL entities.
Note: It is strongly recommended that systems supporting a single DICOM UL entity use as their port the “well known port” registered for the DICOM Upper Layer Protocol: port number 104 (decimal), if the operating system permits access to privileged ports (in the range 0 to 1023), otherwise it is recommended that they use the “registered” port number 11112 (decimal). See “http://www.iana.org/assignments/port-numbers”.
Application Entities may also choose to access the TCP Transport Services via a Secure Transport Connection. The nature of this Secure Transport Connection is specified through Security Profiles (see PS 3.15). Security Profiles select minimum mechanisms needed to support that profile. Other mechanisms may also be used if agreed to during establishment of the Secure Transport Connection.
Notes: 1. DICOM does not specify how a secure transport connection is established, or the significance of any certificates exchanged during peer entity authentication. These issues are left up to the application, which is assumed to be following some security policy. Once the application has established a secure Transport Connection, then an Upper Layer Association can use that secure channel.
2. There may be an interaction between PDU size and record size of the secure Transport Connection that impacts efficiency of transport.
3. Registered ports for Secure Transport Connections are defined in PS3.15.
When an Association is to be established by a DICOM Upper Layer Entity, a TRANSPORT CONNECT request primitive shall be issued to the TCP Transport Service (Active Open). Once the TCP Transport Connection Confirmation is received (Open Completed), an A-ASSOCIATE-RQ PDU shall be sent/written on the now established transport connection.
When a DICOM Upper Layer Entity becomes activated (Association Idle State), it shall wait for TCP Transport Connections in a passive mode by initiating a “listen.” When an incoming TCP Transport Connection Indication is received from the network, it is accepted and a timer ARTIM (Association Request/Reject/Release Timer) shall be set. Any further exchange of PDUs (read/write) shall be performed as specified by the Upper Layer State Machine (including ARTIM Timer expiration before an A-ASSOCIATE-RQ PDU is received, see Section 9.2).
Data exchange of PDUs (read/write) on an established TCP Connection shall follow the specifications of the DICOM Upper Layer Protocol State Machine (see Section 9.2) and the DICOM Upper Layer PDU structure (see Section 9.3).
TCP Transport Connections shall be closed using the “don't linger” option.
A TCP Transport Connection is closed under a number of situations. These are described in the DICOM Upper Layer Protocol State Machine. Some typical cases are discussed below:
a) After an A-RELEASE-RQ has been sent and the A-RELEASE-RP PDU is received
b) When a Transport Connection has been established by the DICOM remote UL Entity and no A-ASSOCIATE-RQ is received before the ARTIM Timer expires
c) When an A-ABORT PDU has been received
d) When an A-ABORT PDU has been sent and the ARTIM Timer expires before the Transport Connection is closed
e) When a TCP connection is being disconnected by the Transport Service Provider (e.g. network failure)
f) When a TCP connection is being disconnected by the remote DICOM UL Entity
Notes 1. Except following the normal completion of an association reject, release or abort and in specific situations such as temporary lack of resources, an Upper Layer State Machine should not disconnect a TCP connection or reject its establishment. The appropriate behavior is to use the Association Reject or Abort services.
2. The ARTIM Timer should not be used to oversee the Association Establishment or Release. Such a mechanism falls under the protocol definition of the layer above the DICOM Upper Layer (i.e. DICOM Application Entity, see PS 3.7).
The value of the ARTIM Timer used to manage the Request, Reject, and Release of associations on a DICOM UL entity shall be configurable to address a wide range of network configurations.