This blog discusses iSCSI session, iSCSI login and the components required for a connection between iSCSI initiator and iSCSI target in detail. The previous blog from this series introduced the basics of iSCSI protocol.
The group of TCP connections that link an initiator with a target form an iSCSI session. The purpose of the iSCSI login is to enable a TCP connection for iSCSI use, authentication of the parties, negotiation of the session’s parameters, and marking of the connection as belonging to an iSCSI session.
A session is established between an iSCSI initiator and an iSCSI target when the iSCSI initiator performs a logon or connects with the target. The link between an initiator and a target which contains the group of TCP connections forms a session. A session is identified by a session ID that includes an initiator part and a target part.
Every connection in a session is identified through a connection ID (CID). Communication between the initiator and the target is carried out over one or more TCP connections. It must support at least one TCP connection between iSCSI targets and initiators, and may support multiple connections in a session. The TCP connections carry control messages, SCSI commands, parameters, and data within iSCSI Protocol Data Units (iSCSI PDUs). In case of failure, two connections are required for error recovery in a session.
There are two types of sessions that can be established:
- Discovery-session: This type of session is used only for target discovery. The iSCSI target may permit SendTargets text requests in such a session.
- Normal operational session: This type of session is typically an unlimited session.
An iSCSI login is used to establish a TCP connection between an initiator node (i.e. client) and a target node (i.e. a storage server) for iSCSI communication, authentication, negotiation of the session’s parameters and establishing the connection belonging to an iSCSI session.
A session enables a target to identify all the connections with a given initiator. The targets uses a TCP port to listen for incoming connections. The initiator starts the login process by connecting to the TCP port. To ensure security, the initiator and target should authenticate at the time of the login process and may set a security association protocol for the session. To protect the TCP connection, an IPsec security association can be used before the login request.
The iSCSI login phase is carried through login requests and responses. Once the authentication is completed successfully and operational parameters are set, the normal login session converts to the Full Feature Phase and the initiator starts sending SCSI commands.
Before the Full Feature Phase between an initiator and target is established, the login request and login response PDUs are allowed. Only login requests and responses are used during login.
The login PDU includes the ISID part of the session ID (SSID). The target portal group services the login. For a new session the TSIH is zero or null. While sending a response, the target generates a TSIH. At the time of session creation, the target identifies the SCSI initiator port (the “I” in the “I_T nexus”) through a value pair (InitiatorName, ISID). The target state associated with the SCSI target port (the “T” in the “I_T nexus”) is identified externally by the TargetName and portal group tag.
A target receiving any PDU except a login request before the login phase has started should terminate the connection on which the PDU was received. Once the login phase has started, if the target receives any PDU except a login request, it should send a login reject (with Status “invalid during login”) and then disconnect. If the initiator receives any PDU except a login response, it should terminate the connection immediately. During the login phase the TCP connection is established immediately. Another login phase should not occur before tearing down a connection.
This blog discussed iSCSI session and login features. There are automated tools available in the market to test iSCSI protocol. Calsoft has also developed a proprietary iSCSI protocol conformance test suite which automates the testing of all iSCSI features. To learn more about Calsoft’s protocol conformance test suite, listen to the podcast in the link below:
Recent search terms:
- june 2017 patchday iscsi issue
- which programming language are used by the calsoft software