tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 3720


Internet Small Computer Systems Interface (iSCSI)

Part 2 of 9, p. 17 to 42
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 17 
3.  Overview

3.1.  SCSI Concepts

   The SCSI Architecture Model-2 [SAM2] describes in detail the
   architecture of the SCSI family of I/O protocols.  This section
   provides a brief background of the SCSI architecture and is intended
   to familiarize readers with its terminology.

   At the highest level, SCSI is a family of interfaces for requesting
   services from I/O devices, including hard drives, tape drives, CD and
   DVD drives, printers, and scanners.  In SCSI terminology, an
   individual I/O device is called a "logical unit" (LU).

   SCSI is a client-server architecture.  Clients of a SCSI interface
   are called "initiators".  Initiators issue SCSI "commands" to request
   services from components, logical units, of a server known as a
   "target".  The "device server" on the logical unit accepts SCSI
   commands and processes them.

   A "SCSI transport" maps the client-server SCSI protocol to a specific
   interconnect.  Initiators are one endpoint of a SCSI transport.  The
   "target" is the other endpoint.  A target can contain multiple
   Logical Units (LUs).  Each Logical Unit has an address within a
   target called a Logical Unit Number (LUN).

   A SCSI task is a SCSI command or possibly a linked set of SCSI
   commands.  Some LUs support multiple pending (queued) tasks, but the

Top      Up      ToC       Page 18 
   queue of tasks is managed by the logical unit.  The target uses an
   initiator provided "task tag" to distinguish between tasks.  Only one
   command in a task can be outstanding at any given time.

   Each SCSI command results in an optional data phase and a required
   response phase.  In the data phase, information can travel from the
   initiator to target (e.g., WRITE), target to initiator (e.g., READ),
   or in both directions.  In the response phase, the target returns the
   final status of the operation, including any errors.

   Command Descriptor Blocks (CDB) are the data structures used to
   contain the command parameters that an initiator sends to a target.
   The CDB content and structure is defined by [SAM2] and device-type
   specific SCSI standards.

3.2.  iSCSI Concepts and Functional Overview

   The iSCSI protocol is a mapping of the SCSI remote procedure
   invocation model (see [SAM2]) over the TCP protocol.  SCSI commands
   are carried by iSCSI requests and SCSI responses and status are
   carried by iSCSI responses.  iSCSI also uses the request response
   mechanism for iSCSI protocol mechanisms.

   For the remainder of this document, the terms "initiator" and
   "target" refer to "iSCSI initiator node" and "iSCSI target node",
   respectively (see Section 3.4.1 iSCSI Architecture Model) unless
   otherwise qualified.

   In keeping with similar protocols, the initiator and target divide
   their communications into messages.  This document uses the term
   "iSCSI protocol data unit" (iSCSI PDU) for these messages.

   For performance reasons, iSCSI allows a "phase-collapse".  A command
   and its associated data may be shipped together from initiator to
   target, and data and responses may be shipped together from targets.

   The iSCSI transfer direction is defined with respect to the
   initiator.  Outbound or outgoing transfers are transfers from an
   initiator to a target, while inbound or incoming transfers are from a
   target to an initiator.

   An iSCSI task is an iSCSI request for which a response is expected.

   In this document "iSCSI request", "iSCSI command", request, or
   (unqualified) command have the same meaning.  Also, unless otherwise
   specified, status, response, or numbered response have the same

Top      Up      ToC       Page 19 
3.2.1.  Layers and Sessions

   The following conceptual layering model is used to specify initiator
   and target actions and the way in which they relate to transmitted
   and received Protocol Data Units:

      a) the SCSI layer builds/receives SCSI CDBs (Command Descriptor
         Blocks) and passes/receives them with the remaining command
         execute parameters ([SAM2]) to/from

      b) the iSCSI layer that builds/receives iSCSI PDUs and
         relays/receives them to/from one or more TCP connections; the
         group of connections form an initiator-target "session".

   Communication between the initiator and target occurs over one or
   more TCP connections.  The TCP connections carry control messages,
   SCSI commands, parameters, and data within iSCSI Protocol Data Units
   (iSCSI PDUs).  The group of TCP connections that link an initiator
   with a target form a session (loosely equivalent to a SCSI I_T nexus,
   see Section 3.4.2 SCSI Architecture Model).  A session is defined by
   a session ID that is composed of an initiator part and a target part.
   TCP connections can be added and removed from a session.  Each
   connection within a session is identified by a connection ID (CID).

   Across all connections within a session, an initiator sees one
   "target image".  All target identifying elements, such as LUN, are
   the same.  A target also sees one "initiator image" across all
   connections within a session.  Initiator identifying elements, such
   as the Initiator Task Tag, are global across the session regardless
   of the connection on which they are sent or received.

   iSCSI targets and initiators MUST support at least one TCP connection
   and MAY support several connections in a session.  For error recovery
   purposes, targets and initiators that support a single active
   connection in a session SHOULD support two connections during

3.2.2.  Ordering and iSCSI Numbering

   iSCSI uses Command and Status numbering schemes and a Data sequencing

   Command numbering is session-wide and is used for ordered command
   delivery over multiple connections.  It can also be used as a
   mechanism for command flow control over a session.

Top      Up      ToC       Page 20 
   Status numbering is per connection and is used to enable missing
   status detection and recovery in the presence of transient or
   permanent communication errors.

   Data sequencing is per command or part of a command (R2T triggered
   sequence) and is used to detect missing data and/or R2T PDUs due to
   header digest errors.

   Typically, fields in the iSCSI PDUs communicate the Sequence Numbers
   between the initiator and target.  During periods when traffic on a
   connection is unidirectional, iSCSI NOP-Out/In PDUs may be utilized
   to synchronize the command and status ordering counters of the target
   and initiator.

   The iSCSI session abstraction is equivalent to the SCSI I_T nexus,
   and the iSCSI session provides an ordered command delivery from the
   SCSI initiator to the SCSI target.  For detailed design
   considerations that led to the iSCSI session model as it is defined
   here and how it relates the SCSI command ordering features defined in
   SCSI specifications to the iSCSI concepts see [CORD].  Command Numbering and Acknowledging

   iSCSI performs ordered command delivery within a session.  All
   commands (initiator-to-target PDUs) in transit from the initiator to
   the target are numbered.

   iSCSI considers a task to be instantiated on the target in response
   to every request issued by the initiator.  A set of task management
   operations including abort and reassign (see Section 10.5 Task
   Management Function Request) may be performed on any iSCSI task.

   Some iSCSI tasks are SCSI tasks, and many SCSI activities are related
   to a SCSI task ([SAM2]).  In all cases, the task is identified by the
   Initiator Task Tag for the life of the task.

   The command number is carried by the iSCSI PDU as CmdSN
   (Command Sequence Number).  The numbering is session-wide.  Outgoing
   iSCSI PDUs carry this number.  The iSCSI initiator allocates CmdSNs
   with a 32-bit unsigned counter (modulo 2**32).  Comparisons and
   arithmetic on CmdSN use Serial Number Arithmetic as defined in
   [RFC1982] where SERIAL_BITS = 32.

   Commands meant for immediate delivery are marked with an immediate
   delivery flag; they MUST also carry the current CmdSN.  CmdSN does
   not advance after a command marked for immediate delivery is sent.

Top      Up      ToC       Page 21 
   Command numbering starts with the first login request on the first
   connection of a session (the leading login on the leading connection)
   and command numbers are incremented by 1 for every non-immediate
   command issued afterwards.

   If immediate delivery is used with task management commands, these
   commands may reach the target before the tasks on which they are
   supposed to act.  However their CmdSN serves as a marker of their
   position in the stream of commands.  The initiator and target must
   ensure that the task management commands act as specified by [SAM2].
   For example, both commands and responses appear as if delivered in
   order.  Whenever CmdSN for an outgoing PDU is not specified by an
   explicit rule, CmdSN will carry the current value of the local CmdSN
   variable (see later in this section).

   The means by which an implementation decides to mark a PDU for
   immediate delivery or by which iSCSI decides by itself to mark a PDU
   for immediate delivery are beyond the scope of this document.

   The number of commands used for immediate delivery is not limited and
   their delivery for execution is not acknowledged through the
   numbering scheme.  Immediate commands MAY be rejected by the iSCSI
   target layer due to a lack of resources.  An iSCSI target MUST be
   able to handle at least one immediate task management command and one
   immediate non-task-management iSCSI command per connection at any

   In this document, delivery for execution means delivery to the SCSI
   execution engine or an iSCSI protocol specific execution engine
   (e.g., for text requests with public or private extension keys
   involving an execution component).  With the exception of the
   commands marked for immediate delivery, the iSCSI target layer MUST
   deliver the commands for execution in the order specified by CmdSN.
   Commands marked for immediate delivery may be delivered by the iSCSI
   target layer for execution as soon as detected.  iSCSI may avoid
   delivering some commands to the SCSI target layer if required by a
   prior SCSI or iSCSI action (e.g., CLEAR TASK SET Task Management
   request received before all the commands on which it was supposed to

   On any connection, the iSCSI initiator MUST send the commands in
   increasing order of CmdSN, except for commands that are retransmitted
   due to digest error recovery and connection recovery.

   For the numbering mechanism, the initiator and target maintain the
   following three variables for each session:

Top      Up      ToC       Page 22 
      -  CmdSN - the current command Sequence Number, advanced by 1 on
         each command shipped except for commands marked for immediate
         delivery.  CmdSN always contains the number to be assigned to
         the next Command PDU.
      -  ExpCmdSN - the next expected command by the target.  The target
         acknowledges all commands up to, but not including, this
         number.  The initiator treats all commands with CmdSN less than
         ExpCmdSN as acknowledged.  The target iSCSI layer sets the
         ExpCmdSN to the largest non-immediate CmdSN that it can deliver
         for execution plus 1 (no holes in the CmdSN sequence).
      -  MaxCmdSN - the maximum number to be shipped.  The queuing
         capacity of the receiving iSCSI layer is MaxCmdSN - ExpCmdSN +

   The initiator's ExpCmdSN and MaxCmdSN are derived from
   target-to-initiator PDU fields.  Comparisons and arithmetic on
   ExpCmdSN and MaxCmdSN MUST use Serial Number Arithmetic as defined in
   [RFC1982] where SERIAL_BITS = 32.

   The target MUST NOT transmit a MaxCmdSN that is less than
   ExpCmdSN-1.  For non-immediate commands, the CmdSN field can take any
   value from ExpCmdSN to MaxCmdSN inclusive.  The target MUST silently
   ignore any non-immediate command outside of this range or non-
   immediate duplicates within the range.  The CmdSN carried by
   immediate commands may lie outside the ExpCmdSN to MaxCmdSN range.
   For example, if the initiator has previously sent a non-immediate
   command carrying the CmdSN equal to MaxCmdSN, the target window is
   closed.  For group task management commands issued as immediate
   commands, CmdSN indicates the scope of the group action (e.g., on
   ABORT TASK SET indicates which commands are aborted).

   MaxCmdSN and ExpCmdSN fields are processed by the initiator as

      -  If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial
         Arithmetic Sense), they are both ignored.
      -  If the PDU MaxCmdSN is greater than the local MaxCmdSN (in
         Serial Arithmetic Sense), it updates the local MaxCmdSN;
         otherwise, it is ignored.
      -  If the PDU ExpCmdSN is greater than the local ExpCmdSN (in
         Serial Arithmetic Sense), it updates the local ExpCmdSN;
         otherwise, it is ignored.

   This sequence is required because updates may arrive out of order
   (e.g., the updates are sent on different TCP connections).

   iSCSI initiators and targets MUST support the command numbering

Top      Up      ToC       Page 23 
   A numbered iSCSI request will not change its allocated CmdSN,
   regardless of the number of times and circumstances in which it is
   reissued (see Section 6.2.1 Usage of Retry).  At the target, CmdSN is
   only relevant when the command has not created any state related to
   its execution (execution state); afterwards, CmdSN becomes
   irrelevant.  Testing for the execution state (represented by
   identifying the Initiator Task Tag) MUST precede any other action at
   the target.  If no execution state is found, it is followed by
   ordering and delivery.  If an execution state is found, it is
   followed by delivery.

   If an initiator issues a command retry for a command with CmdSN R on
   a connection when the session CmdSN value is Q, it MUST NOT advance
   the CmdSN past R + 2**31 -1 unless the connection is no longer
   operational (i.e., it has returned to the FREE state, see Section
   7.1.3 Standard Connection State Diagram for an Initiator), the
   connection has been reinstated (see Section 5.3.4 Connection
   Reinstatement), or a non-immediate command with CmdSN equal or
   greater than Q was issued subsequent to the command retry on the same
   connection and the reception of that command is acknowledged by the
   target (see Section 9.4 Command Retry and Cleaning Old Command

   A target MUST NOT issue a command response or Data-In PDU with status
   before acknowledging the command.  However, the acknowledgement can
   be included in the response or Data-In PDU.  Response/Status Numbering and Acknowledging

   Responses in transit from the target to the initiator are numbered.
   The StatSN (Status Sequence Number) is used for this purpose.  StatSN
   is a counter maintained per connection.  ExpStatSN is used by the
   initiator to acknowledge status.  The status sequence number space is
   32-bit unsigned-integers and the arithmetic operations are the
   regular mod(2**32) arithmetic.

   Status numbering starts with the Login response to the first Login
   request of the connection.  The Login response includes an initial
   value for status numbering (any initial value is valid).

   To enable command recovery, the target MAY maintain enough state
   information for data and status recovery after a connection failure.
   A target doing so can safely discard all of the state information
   maintained for recovery of a command after the delivery of the status
   for the command (numbered StatSN) is acknowledged through ExpStatSN.

   A large absolute difference between StatSN and ExpStatSN may indicate
   a failed connection.  Initiators MUST undertake recovery actions if

Top      Up      ToC       Page 24 
   the difference is greater than an implementation defined constant
   that MUST NOT exceed 2**31-1.

   Initiators and Targets MUST support the response-numbering scheme.  Data Sequencing

   Data and R2T PDUs transferred as part of some command execution MUST
   be sequenced.  The DataSN field is used for data sequencing.  For
   input (read) data PDUs, DataSN starts with 0 for the first data PDU
   of an input command and advances by 1 for each subsequent data PDU.
   For output data PDUs, DataSN starts with 0 for the first data PDU of
   a sequence (the initial unsolicited sequence or any data PDU sequence
   issued to satisfy an R2T) and advances by 1 for each subsequent data
   PDU.  R2Ts are also sequenced per command.  For example, the first
   R2T has an R2TSN of 0 and advances by 1 for each subsequent R2T.  For
   bidirectional commands, the target uses the DataSN/R2TSN to sequence
   Data-In and R2T PDUs in one continuous sequence (undifferentiated).
   Unlike command and status, data PDUs and R2Ts are not acknowledged by
   a field in regular outgoing PDUs.  Data-In PDUs can be acknowledged
   on demand by a special form of the SNACK PDU.  Data and R2T PDUs are
   implicitly acknowledged by status for the command.  The DataSN/R2TSN
   field enables the initiator to detect missing data or R2T PDUs.

   For any read or bidirectional command, a target MUST issue less than
   2**32 combined R2T and Data-In PDUs.  Any output data sequence MUST
   contain less than 2**32 Data-Out PDUs.

3.2.3.  iSCSI Login

   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 used to identify to a target all the connections with a
   given initiator that belong to the same I_T nexus.  (For more details
   on how a session relates to an I_T nexus, see Section 3.4.2 SCSI
   Architecture Model).

   The targets listen on a well-known TCP port or other TCP port for
   incoming connections.  The initiator begins the login process by
   connecting to one of these TCP ports.

   As part of the login process, the initiator and target SHOULD
   authenticate each other and MAY set a security association protocol
   for the session.  This can occur in many different ways and is
   subject to negotiation.

Top      Up      ToC       Page 25 
   To protect the TCP connection, an IPsec security association MAY be
   established before the Login request.  For information on using IPsec
   security for iSCSI see Chapter 8 and [RFC3723].

   The iSCSI Login Phase is carried through Login requests and
   responses.  Once suitable authentication has occurred and operational
   parameters have been set, the session transitions to the Full Feature
   Phase and the initiator may start to send SCSI commands.  The
   security policy for whether, and by what means, a target chooses to
   authorize an initiator is beyond the scope of this document.  For a
   more detailed description of the Login Phase, see Chapter 5.

   The login PDU includes the ISID part of the session ID (SSID).  The
   target portal group that services the login is implied by the
   selection of the connection endpoint.  For a new session, the TSIH is
   zero.  As part of the response, the target generates a TSIH.

   During session establishment, the target identifies the SCSI
   initiator port (the "I" in the "I_T nexus") through the value pair
   (InitiatorName, ISID).  We describe InitiatorName later in this
   section.  Any persistent state (e.g., persistent reservations) on the
   target that is associated with a SCSI initiator port is identified
   based on this value pair.  Any state associated with the SCSI target
   port (the "T" in the "I_T nexus") is identified externally by the
   TargetName and portal group tag (see Section 3.4.1 iSCSI Architecture
   Model).  ISID is subject to reuse restrictions because it is used to
   identify a persistent state (see Section 3.4.3 Consequences of the

   Before the Full Feature Phase is established, only Login Request and
   Login Response PDUs are allowed.  Login requests and responses MUST
   be used exclusively during Login.  On any connection, the login phase
   MUST immediately follow TCP connection establishment and a subsequent
   Login Phase MUST NOT occur before tearing down a connection.

   A target receiving any PDU except a Login request before the Login
   phase is started MUST immediately 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 MUST send a Login
   reject (with Status "invalid during login") and then disconnect.  If
   the initiator receives any PDU except a Login response, it MUST
   immediately terminate the connection.

3.2.4.  iSCSI Full Feature Phase

   Once the initiator is authorized to do so, the iSCSI session is in
   the iSCSI Full Feature Phase.  A session is in Full Feature Phase
   after successfully finishing the Login Phase on the first (leading)

Top      Up      ToC       Page 26 
   connection of a session.  A connection is in Full Feature Phase if
   the session is in Full Feature Phase and the connection login has
   completed successfully.  An iSCSI connection is not in Full Feature

      a) when it does not have an established transport connection,


      b) when it has a valid transport connection, but a successful
         login was not performed or the connection is currently logged

   In a normal Full Feature Phase, the initiator may send SCSI commands
   and data to the various LUs on the target by encapsulating them in
   iSCSI PDUs that go over the established iSCSI session.  Command Connection Allegiance

   For any iSCSI request issued over a TCP connection, the corresponding
   response and/or other related PDU(s) MUST be sent over the same
   connection.  We call this "connection allegiance".  If the original
   connection fails before the command is completed, the connection
   allegiance of the command may be explicitly reassigned to a different
   transport connection as described in detail in Section 6.2 Retry and
   Reassign in Recovery.

   Thus, if an initiator issues a READ command, the target MUST send the
   requested data, if any, followed by the status to the initiator over
   the same TCP connection that was used to deliver the SCSI command.
   If an initiator issues a WRITE command, the initiator MUST send the
   data, if any, for that command over the same TCP connection that was
   used to deliver the SCSI command.  The target MUST return Ready To
   Transfer (R2T), if any, and the status over the same TCP connection
   that was used to deliver the SCSI command.  Retransmission requests
   (SNACK PDUs) and the data and status that they generate MUST also use
   the same connection.

   However, consecutive commands that are part of a SCSI linked
   command-chain task (see [SAM2]) MAY use different connections.
   Connection allegiance is strictly per-command and not per-task.
   During the iSCSI Full Feature Phase, the initiator and target MAY
   interleave unrelated SCSI commands, their SCSI Data, and responses
   over the session.

Top      Up      ToC       Page 27  Data Transfer Overview

   Outgoing SCSI data (initiator to target user data or command
   parameters) is sent as either solicited data or unsolicited data.
   Solicited data are sent in response to R2T PDUs.  Unsolicited data
   can be sent as part of an iSCSI command PDU ("immediate data") or in
   separate iSCSI data PDUs.

   Immediate data are assumed to originate at offset 0 in the initiator
   SCSI write-buffer (outgoing data buffer).  All other Data PDUs have
   the buffer offset set explicitly in the PDU header.

   An initiator may send unsolicited data up to FirstBurstLength as
   immediate (up to the negotiated maximum PDU length), in a separate
   PDU sequence or both.  All subsequent data MUST be solicited.  The
   maximum length of an individual data PDU or the immediate-part of the
   first unsolicited burst MAY be negotiated at login.

   The maximum amount of unsolicited data that can be sent with a
   command is negotiated at login through the FirstBurstLength key.  A
   target MAY separately enable immediate data (through the
   ImmediateData key) without enabling the more general (separate data
   PDUs) form of unsolicited data (through the InitialR2T key).

   Unsolicited data on write are meant to reduce the effect of latency
   on throughput (no R2T is needed to start sending data).  In addition,
   immediate data is meant to reduce the protocol overhead (both
   bandwidth and execution time).

   An iSCSI initiator MAY choose not to send unsolicited data, only
   immediate data or FirstBurstLength bytes of unsolicited data with a
   command.  If any non-immediate unsolicited data is sent, the total
   unsolicited data MUST be either FirstBurstLength, or all of the data
   if the total amount is less than the FirstBurstLength.

   It is considered an error for an initiator to send unsolicited data
   PDUs to a target that operates in R2T mode (only solicited data are
   allowed).  It is also an error for an initiator to send more
   unsolicited data, whether immediate or as separate PDUs, than

   An initiator MUST honor an R2T data request for a valid outstanding
   command (i.e., carrying a valid Initiator Task Tag) and deliver all
   the requested data provided the command is supposed to deliver
   outgoing data and the R2T specifies data within the command bounds.
   The initiator action is unspecified for receiving an R2T request that
   specifies data, all or part, outside of the bounds of the command.

Top      Up      ToC       Page 28 
   A target SHOULD NOT silently discard data and then request
   retransmission through R2T.  Initiators SHOULD NOT keep track of the
   data transferred to or from the target (scoreboarding).  SCSI targets
   perform residual count calculation to check how much data was
   actually transferred to or from the device by a command.  This may
   differ from the amount the initiator sent and/or received for reasons
   such as retransmissions and errors.  Read or bidirectional commands
   implicitly solicit the transmission of the entire amount of data
   covered by the command.  SCSI data packets are matched to their
   corresponding SCSI commands by using tags specified in the protocol.

   In addition, iSCSI initiators and targets MUST enforce some ordering
   rules.  When unsolicited data is used, the order of the unsolicited
   data on each connection MUST match the order in which the commands on
   that connection are sent.  Command and unsolicited data PDUs may be
   interleaved on a single connection as long as the ordering
   requirements of each are maintained (e.g., command N+1 MAY be sent
   before the unsolicited Data-Out PDUs for command N, but the
   unsolicited Data-Out PDUs for command N MUST precede the unsolicited
   Data-Out PDUs of command N+1).  A target that receives data out of
   order MAY terminate the session.  Tags and Integrity Checks

   Initiator tags for pending commands are unique initiator-wide for a
   session.  Target tags are not strictly specified by the protocol.  It
   is assumed that target tags are used by the target to tag (alone or
   in combination with the LUN) the solicited data.  Target tags are
   generated by the target and "echoed" by the initiator.  These
   mechanisms are designed to accomplish efficient data delivery along
   with a large degree of control over the data flow.

   As the Initiator Task Tag is used to identify a task during its
   execution, the iSCSI initiator and target MUST verify that all other
   fields used in task-related PDUs have values that are consistent with
   the values used at the task instantiation based on the Initiator Task
   Tag (e.g., the LUN used in an R2T PDU MUST be the same as the one
   used in the SCSI command PDU used to instantiate the task).  Using
   inconsistent field values is considered a protocol error.  Task Management

   SCSI task management assumes that individual tasks and task groups
   can be aborted solely based on the task tags (for individual tasks)
   or the timing of the task management command (for task groups), and
   that the task management action is executed synchronously - i.e., no
   message involving an aborted task will be seen by the SCSI initiator
   after receiving the task management response.  In iSCSI initiators

Top      Up      ToC       Page 29 
   and targets interact asynchronously over several connections.  iSCSI
   specifies the protocol mechanism and implementation requirements
   needed to present a synchronous view while using an asynchronous

3.2.5.  iSCSI Connection Termination

   An iSCSI connection may be terminated by use of a transport
   connection shutdown or a transport reset.  Transport reset is assumed
   to be an exceptional event.

   Graceful TCP connection shutdowns are done by sending TCP FINs.  A
   graceful transport connection shutdown SHOULD only be initiated by
   either party when the connection is not in iSCSI Full Feature Phase.
   A target MAY terminate a Full Feature Phase connection on internal
   exception events, but it SHOULD announce the fact through an
   Asynchronous Message PDU.  Connection termination with outstanding
   commands may require recovery actions.

   If a connection is terminated while in Full Feature Phase, connection
   cleanup (see section 7) is required prior to recovery.  By doing
   connection cleanup before starting recovery, the initiator and target
   will avoid receiving stale PDUs after recovery.

3.2.6.  iSCSI Names

   Both targets and initiators require names for the purpose of
   identification.  In addition, names enable iSCSI storage resources to
   be managed regardless of location (address).  An iSCSI node name is
   also the SCSI device name of an iSCSI device.  The iSCSI name of a
   SCSI device is the principal object used in authentication of targets
   to initiators and initiators to targets.  This name is also used to
   identify and manage iSCSI storage resources.

   iSCSI names must be unique within the operational domain of the end
   user.  However, because the operational domain of an IP network is
   potentially worldwide, the iSCSI name formats are architected to be
   worldwide unique.  To assist naming authorities in the construction
   of worldwide unique names, iSCSI provides two name formats for
   different types of naming authorities.

   iSCSI names are associated with iSCSI nodes, and not iSCSI network
   adapter cards, to ensure that the replacement of network adapter
   cards does not require reconfiguration of all SCSI and iSCSI resource
   allocation information.

Top      Up      ToC       Page 30 
   Some SCSI commands require that protocol-specific identifiers be
   communicated within SCSI CDBs.  See Section 3.4.2 SCSI Architecture
   Model for the definition of the SCSI port name/identifier for iSCSI

   An initiator may discover the iSCSI Target Names to which it has
   access, along with their addresses, using the SendTargets text
   request, or other techniques discussed in [RFC3721].  iSCSI Name Properties

   Each iSCSI node, whether an initiator or target, MUST have an iSCSI

   Initiators and targets MUST support the receipt of iSCSI names of up
   to the maximum length of 223 bytes.

   The initiator MUST present both its iSCSI Initiator Name and the
   iSCSI Target Name to which it wishes to connect in the first login
   request of a new session or connection.  The only exception is if a
   discovery session (see Section 2.3 iSCSI Session Types) is to be
   established.  In this case, the iSCSI Initiator Name is still
   required, but the iSCSI Target Name MAY be omitted.

   iSCSI names have the following properties:

      a) iSCSI names are globally unique.  No two initiators or targets
         can have the same name.
      b) iSCSI names are permanent.  An iSCSI initiator node or target
         node has the same name for its lifetime.
      c) iSCSI names do not imply a location or address.  An iSCSI
         initiator or target can move, or have multiple addresses.  A
         change of address does not imply a change of name.
      d) iSCSI names do not rely on a central name broker; the naming
         authority is distributed.
      e) iSCSI names support integration with existing unique naming
      f) iSCSI names rely on existing naming authorities.  iSCSI does
         not create any new naming authority.

   The encoding of an iSCSI name has the following properties:

      a) iSCSI names have the same encoding method regardless of the
         underlying protocols.
      b) iSCSI names are relatively simple to compare.  The algorithm
         for comparing two iSCSI names for equivalence does not rely on
         an external server.

Top      Up      ToC       Page 31 
      c) iSCSI names are composed only of displayable characters.  iSCSI
         names allow the use of international character sets but are not
         case sensitive.  No whitespace characters are used in iSCSI
      d) iSCSI names may be transported using both binary and
         ASCII-based protocols.

   An iSCSI name really names a logical software entity, and is not tied
   to a port or other hardware that can be changed.  For instance, an
   initiator name should name the iSCSI initiator node, not a particular
   NIC or HBA.  When multiple NICs are used, they should generally all
   present the same iSCSI initiator name to the targets, because they
   are simply paths to the same SCSI layer.  In most operating systems,
   the named entity is the operating system image.

   Similarly, a target name should not be tied to hardware interfaces
   that can be changed.  A target name should identify the logical
   target and must be the same for the target regardless of the physical
   portion being addressed.  This assists iSCSI initiators in
   determining that the two targets it has discovered are really two
   paths to the same target.

   The iSCSI name is designed to fulfill the functional requirements for
   Uniform Resource Names (URN) [RFC1737].  For example, it is required
   that the name have a global scope, be independent of address or
   location, and be persistent and globally unique.  Names must be
   extensible and scalable with the use of naming authorities.  The name
   encoding should be both human and machine readable.  See [RFC1737]
   for further requirements.  iSCSI Name Encoding

   An iSCSI name MUST be a UTF-8 encoding of a string of Unicode
   characters with the following properties:

      -  It is in Normalization Form C (see "Unicode Normalization
         Forms" [UNICODE]).
      -  It only contains characters allowed by the output of the iSCSI
         stringprep template (described in [RFC3722]).
      -  The following characters are used for formatting iSCSI names:

            - dash ('-'=U+002d)
            - dot ('.'=U+002e)
            - colon (':'=U+003a)

      -  The UTF-8 encoding of the name is not larger than 223 bytes.

Top      Up      ToC       Page 32 
   The stringprep process is described in [RFC3454]; iSCSI's use of the
   stringprep process is described in [RFC3722].  Stringprep is a method
   designed by the Internationalized Domain Name (IDN) working group to
   translate human-typed strings into a format that can be compared as
   opaque strings.  Strings MUST NOT include punctuation, spacing,
   diacritical marks, or other characters that could get in the way of
   readability.  The stringprep process also converts strings into
   equivalent strings of lower-case characters.

   The stringprep process does not need to be implemented if the names
   are only generated using numeric and lower-case (any character set)
   alphabetic characters.

   Once iSCSI names encoded in UTF-8 are "normalized" they may be safely
   compared byte-for-byte.  iSCSI Name Structure

   An iSCSI name consists of two parts--a type designator followed by a
   unique name string.

   The iSCSI name does not define any new naming authorities.  Instead,
   it supports two existing ways of designating naming authorities: an
   iSCSI-Qualified Name, using domain names to identify a naming
   authority, and the EUI format, where the IEEE Registration Authority
   assists in the formation of worldwide unique names (EUI-64 format).

   The type designator strings currently defined are:

     iqn.       - iSCSI Qualified name
     eui.       - Remainder of the string is an IEEE EUI-64
                  identifier, in ASCII-encoded hexadecimal.

   These two naming authority designators were considered sufficient at
   the time of writing this document.  The creation of additional naming
   type designators for iSCSI may be considered by the IETF and detailed
   in separate RFCs.  Type "iqn." (iSCSI Qualified Name)

   This iSCSI name type can be used by any organization that owns a
   domain name.  This naming format is useful when an end user or
   service provider wishes to assign iSCSI names for targets and/or

   To generate names of this type, the person or organization generating
   the name must own a registered domain name.  This domain name does
   not have to be active, and does not have to resolve to an address; it

Top      Up      ToC       Page 33 
   just needs to be reserved to prevent others from generating iSCSI
   names using the same domain name.

   Since a domain name can expire, be acquired by another entity, or may
   be used to generate iSCSI names by both owners, the domain name must
   be additionally qualified by a date during which the naming authority
   owned the domain name.  For this reason, a date code is provided as
   part of the "iqn." format.

   The iSCSI qualified name string consists of:

      -  The string "iqn.", used to distinguish these names from "eui."
         formatted names.
      -  A date code, in yyyy-mm format.  This date MUST be a date
         during which the naming authority owned the domain name used in
         this format, and SHOULD be the first month in which the domain
         name was owned by this naming authority at 00:01 GMT of the
         first day of the month.  This date code uses the Gregorian
         calendar.  All four digits in the year must be present.  Both
         digits of the month must be present, with January == "01" and
         December == "12".  The dash must be included.
      -  A dot "."
      -  The reversed domain name of the naming authority (person or
         organization) creating this iSCSI name.
      -  An optional, colon (:) prefixed, string within the character
         set and length boundaries that the owner of the domain name
         deems appropriate.  This may contain product types, serial
         numbers, host identifiers, or software keys (e.g., it may
         include colons to separate organization boundaries).  With the
         exception of the colon prefix, the owner of the domain name can
         assign everything after the reversed domain name as desired.
         It is the responsibility of the entity that is the naming
         authority to ensure that the iSCSI names it assigns are
         worldwide unique.  For example, "Example Storage Arrays, Inc.",
         might own the domain name "".

   The following are examples of iSCSI qualified names that might be
   generated by "EXAMPLE Storage Arrays, Inc."

                   Naming     String defined by
      Type  Date    Auth      "" naming authority
     +--++-----+ +---------+ +--------------------------------+
     |  ||     | |         | |                                |

Top      Up      ToC       Page 34  Type "eui." (IEEE EUI-64 format)

   The IEEE Registration Authority provides a service for assigning
   globally unique identifiers [EUI].  The EUI-64 format is used to
   build a global identifier in other network protocols.  For example,
   Fibre Channel defines a method of encoding it into a WorldWideName.
   For more information on registering for EUI identifiers, see [OUI].

   The format is "eui." followed by an EUI-64 identifier (16
   ASCII-encoded hexadecimal digits).

   Example iSCSI name:

        Type  EUI-64 identifier (ASCII-encoded hexadecimal)
        |  ||              |

   The IEEE EUI-64 iSCSI name format might be used when a manufacturer
   is already registered with the IEEE Registration Authority and uses
   EUI-64 formatted worldwide unique names for its products.

   More examples of name construction are discussed in [RFC3721].

3.2.7.  Persistent State

   iSCSI does not require any persistent state maintenance across
   sessions.  However, in some cases, SCSI requires persistent
   identification of the SCSI initiator port name (See Section 3.4.2
   SCSI Architecture Model and Section 3.4.3 Consequences of the Model).

   iSCSI sessions do not persist through power cycles and boot

   All iSCSI session and connection parameters are re-initialized upon
   session and connection creation.

   Commands persist beyond connection termination if the session
   persists and command recovery within the session is supported.
   However, when a connection is dropped, command execution, as
   perceived by iSCSI (i.e., involving iSCSI protocol exchanges for the
   affected task), is suspended until a new allegiance is established by
   the 'task reassign' task management function.  (See Section 10.5 Task
   Management Function Request.)

Top      Up      ToC       Page 35 
3.2.8.  Message Synchronization and Steering

   iSCSI presents a mapping of the SCSI protocol onto TCP.  This
   encapsulation is accomplished by sending iSCSI PDUs of varying
   lengths.  Unfortunately, TCP does not have a built-in mechanism for
   signaling message boundaries at the TCP layer.  iSCSI overcomes this
   obstacle by placing the message length in the iSCSI message header.
   This serves to delineate the end of the current message as well as
   the beginning of the next message.

   In situations where IP packets are delivered in order from the
   network, iSCSI message framing is not an issue and messages are
   processed one after the other.  In the presence of IP packet
   reordering (i.e., frames being dropped), legacy TCP implementations
   store the "out of order" TCP segments in temporary buffers until the
   missing TCP segments arrive, upon which the data must be copied to
   the application buffers.  In iSCSI, it is desirable to steer the SCSI
   data within these out of order TCP segments into the pre-allocated
   SCSI buffers rather than store them in temporary buffers.  This
   decreases the need for dedicated reassembly buffers as well as the
   latency and bandwidth related to extra copies.

   Relying solely on the "message length" information from the iSCSI
   message header may make it impossible to find iSCSI message
   boundaries in subsequent TCP segments due to the loss of a TCP
   segment that contains the iSCSI message length.  The missing TCP
   segment(s) must be received before any of the following segments can
   be steered to the correct SCSI buffers (due to the inability to
   determine the iSCSI message boundaries).  Since these segments cannot
   be steered to the correct location, they must be saved in temporary
   buffers that must then be copied to the SCSI buffers.

   Different schemes can be used to recover synchronization.  To make
   these schemes work, iSCSI implementations have to make sure that the
   appropriate protocol layers are provided with enough information to
   implement a synchronization and/or data steering mechanism.  One of
   these schemes is detailed in Appendix A.  - Sync and Steering with
   Fixed Interval Markers -.

   The Fixed Interval Markers (FIM) scheme works by inserting markers in
   the payload stream at fixed intervals that contain the offset for the
   start of the next iSCSI PDU.

   Under normal circumstances (no PDU loss or data reception out of
   order), iSCSI data steering can be accomplished by using the
   identifying tag and the data offset fields in the iSCSI header in
   addition to the TCP sequence number from the TCP header.  The

Top      Up      ToC       Page 36 
   identifying tag helps associate the PDU with a SCSI buffer address
   while the data offset and TCP sequence number are used to determine
   the offset within the buffer.

   When the part of the TCP data stream containing an iSCSI PDU header
   is delayed or lost, markers may be used to minimize the damage as

     - Markers indicate where the next iSCSI PDU starts and enable
       continued processing when iSCSI headers have to be dropped due to
       data errors discovered at the iSCSI level (e.g., iSCSI header CRC

     - Markers help minimize the amount of data that has to be kept by
       the TCP/iSCSI layer while waiting for a late TCP packet arrival
       or recovery, because later they might help find iSCSI PDU headers
       and use the information contained in those to steer data to SCSI
       buffers.  Sync/Steering and iSCSI PDU Length

   When a large iSCSI message is sent, the TCP segment(s) that contain
   the iSCSI header may be lost.  The remaining TCP segment(s), up to
   the next iSCSI message, must be buffered (in temporary buffers)
   because the iSCSI header that indicates to which SCSI buffers the
   data are to be steered was lost.  To minimize the amount of
   buffering, it is recommended that the iSCSI PDU length be restricted
   to a small value (perhaps a few TCP segments in length).  During
   login, each end of the iSCSI session specifies the maximum iSCSI PDU
   length it will accept.

3.3.  iSCSI Session Types

   iSCSI defines two types of sessions:

       a) Normal operational session - an unrestricted session.
       b) Discovery-session - a session only opened for target
          discovery.  The target MUST ONLY accept text requests with the
          SendTargets key and a logout request with the reason "close
          the session".  All other requests MUST be rejected.

   The session type is defined during login with the key=value parameter
   in the login command.

Top      Up      ToC       Page 37 
3.4.  SCSI to iSCSI Concepts Mapping Model

   The following diagram shows an example of how multiple iSCSI Nodes
   (targets in this case) can coexist within the same Network Entity and
   can share Network Portals (IP addresses and TCP ports).  Other more
   complex configurations are also possible.  For detailed descriptions
   of the components of these diagrams, see Section 3.4.1 iSCSI
   Architecture Model.

                  |  Network Entity (iSCSI Client)    |
                  |                                   |
                  |         +-------------+           |
                  |         | iSCSI Node  |           |
                  |         | (Initiator) |           |
                  |         +-------------+           |
                  |            |       |              |
                  | +--------------+ +--------------+ |
                  | |Network Portal| |Network Portal| |
                  | |  | |  | |
                           |               |
                           |  IP Networks  |
                           |               |
                  | |Network Portal| |Network Portal| |
                  | |  | |  | |
                  | | TCP Port 3260| | TCP Port 3260| |
                  | +--------------+ +--------------+ |
                  |        |               |          |
                  |        -----------------          |
                  |           |         |             |
                  |  +-------------+ +--------------+ |
                  |  | iSCSI Node  | | iSCSI Node   | |
                  |  |  (Target)   | |  (Target)    | |
                  |  +-------------+ +--------------+ |
                  |                                   |
                  |   Network Entity (iSCSI Server)   |

3.4.1.  iSCSI Architecture Model

   This section describes the part of the iSCSI architecture model that
   has the most bearing on the relationship between iSCSI and the SCSI
   Architecture Model.

Top      Up      ToC       Page 38 
      a)  Network Entity - represents a device or gateway that is
          accessible from the IP network.  A Network Entity must have
          one or more Network Portals (see item d), each of which can be
          used by some iSCSI Nodes (see item (b)) contained in that
          Network Entity to gain access to the IP network.

      b)  iSCSI Node - represents a single iSCSI initiator or iSCSI
          target.  There are one or more iSCSI Nodes within a Network
          Entity.  The iSCSI Node is accessible via one or more Network
          Portals (see item d).  An iSCSI Node is identified by its
          iSCSI Name (see Section 3.2.6 iSCSI Names and Chapter 12).
          The separation of the iSCSI Name from the addresses used by
          and for the iSCSI node allows multiple iSCSI nodes to use the
          same addresses, and the same iSCSI node to use multiple

      c)  An alias string may also be associated with an iSCSI Node.
          The alias allows an organization to associate a user friendly
          string with the iSCSI Name.  However, the alias string is not
          a substitute for the iSCSI Name.

      d)  Network Portal - a component of a Network Entity that has a
          TCP/IP network address and that may be used by an iSCSI Node
          within that Network Entity for the connection(s) within one of
          its iSCSI sessions.  In an initiator, it is identified by its
          IP address.  In a target, it is identified by its IP address
          and its listening TCP port.

      e)  Portal Groups - iSCSI supports multiple connections within the
          same session; some implementations will have the ability to
          combine connections in a session across multiple Network
          Portals.  A Portal Group defines a set of Network Portals
          within an iSCSI Node that collectively supports the capability
          of coordinating a session with connections that span these
          portals.  Not all Network Portals within a Portal Group need
          to participate in every session connected through that Portal
          Group.  One or more Portal Groups may provide access to an
          iSCSI Node.  Each Network Portal, as utilized by a given iSCSI
          Node, belongs to exactly one portal group within that node.
          Portal Groups are identified within an iSCSI Node by a portal
          group tag, a simple unsigned-integer between 0 and 65535 (see
          Section 12.3 SendTargets).  All Network Portals with the same
          portal group tag in the context of a given iSCSI Node are in
          the same Portal Group.

Top      Up      ToC       Page 39 
          Both iSCSI Initiators and iSCSI Targets have portal groups,
          though only the iSCSI Target Portal Groups are used directly
          in the iSCSI protocol (e.g., in SendTargets).  For references
          to the initiator Portal Groups, see Section 9.1.1 Conservative
          Reuse of ISIDs.

      f)  Portals within a Portal Group should support similar session
          parameters, because they may participate in a common session.

   The following diagram shows an example of one such configuration on a
   target and how a session that shares Network Portals within a Portal
   Group may be established.

     ----------------------------IP Network---------------------
            |               |                    |
       +----|---------------|-----+         +----|---------+
       | +---------+  +---------+ |         | +---------+  |
       | | Network |  | Network | |         | | Network |  |
       | | Portal  |  | Portal  | |         | | Portal  |  |
       | +--|------+  +---------+ |         | +---------+  |
       |    |               |     |         |    |         |
       |    |    Portal     |     |         |    | Portal  |
       |    |    Group 1    |     |         |    | Group 2 |
       +--------------------------+         +--------------+
            |               |                    |
   |        |               |                    |                    |
   |  +----------------------------+  +-----------------------------+ |
   |  | iSCSI Session (Target side)|  | iSCSI Session (Target side) | |
   |  |                            |  |                             | |
   |  |       (TSIH = 56)          |  |       (TSIH = 48)           | |
   |  +----------------------------+  +-----------------------------+ |
   |                                                                  |
   |                     iSCSI Target Node                            |
   |             (within Network Entity, not shown)                   |

3.4.2.  SCSI Architecture Model

   This section describes the relationship between the SCSI Architecture
   Model [SAM2] and the constructs of the SCSI device, SCSI port and I_T
   nexus, and the iSCSI constructs described in Section 3.4.1 iSCSI
   Architecture Model.

   This relationship implies implementation requirements in order to
   conform to the SAM2 model and other SCSI operational functions.
   These requirements are detailed in Section 3.4.3 Consequences of the

Top      Up      ToC       Page 40 
   The following list outlines mappings of SCSI architectural elements
   to iSCSI.

      a)  SCSI Device - the SAM2 term for an entity that contains one or
          more SCSI ports that are connected to a service delivery
          subsystem and supports a SCSI application protocol.  For
          example, a SCSI Initiator Device contains one or more SCSI
          Initiator Ports and zero or more application clients.  A SCSI
          Target Device contains one or more SCSI Target Ports and one
          or more logical units.  For iSCSI, the SCSI Device is the
          component within an iSCSI Node that provides the SCSI
          functionality.  As such, there can be one SCSI Device, at
          most, within an iSCSI Node.  Access to the SCSI Device can
          only be achieved in an iSCSI normal operational session (see
          Section 3.3 iSCSI Session Types).  The SCSI Device Name is
          defined to be the iSCSI Name of the node and MUST be used in
          the iSCSI protocol.

      b)  SCSI Port - the SAM2 term for an entity in a SCSI Device that
          provides the SCSI functionality to interface with a service
          delivery subsystem or transport.  For iSCSI, the definition of
          SCSI Initiator Port and SCSI Target Port are different.

          SCSI Initiator Port: This maps to one endpoint of an iSCSI
          normal operational session (see Section 3.3 iSCSI Session
          Types).  An iSCSI normal operational session is negotiated
          through the login process between an iSCSI initiator node and
          an iSCSI target node.  At successful completion of this
          process, a SCSI Initiator Port is created within the SCSI
          Initiator Device.  The SCSI Initiator Port Name and SCSI
          Initiator Port Identifier are both defined to be the iSCSI
          Initiator Name together with (a) a label that identifies it as
          an initiator port name/identifier and (b) the ISID portion of
          the session identifier.

          SCSI Target Port: This maps to an iSCSI Target Portal Group.
          The SCSI Target Port Name and the SCSI Target Port Identifier
          are both defined to be the iSCSI Target Name together with (a)
          a label that identifies it as a target port name/identifier
          and (b) the portal group tag.

          The SCSI Port Name MUST be used in iSCSI.  When used in SCSI
          parameter data, the SCSI port name MUST be encoded as:
           - The iSCSI Name in UTF-8 format, followed by
           - a comma separator (1 byte), followed by
           - the ASCII character 'i' (for SCSI Initiator Port) or the
             ASCII character 't' (for SCSI Target Port) (1 byte),
             followed by

Top      Up      ToC       Page 41 
           - a comma separator (1 byte), followed by
           - a text encoding as a hex-constant (see Section 5.1 Text
             Format) of the ISID (for SCSI initiator port) or the portal
             group tag (for SCSI target port) including the initial 0X
             or 0x and the terminating null (15 bytes).

          The ASCII character 'i' or 't' is the label that identifies
          this port as either a SCSI Initiator Port or a SCSI Target

      c)  I_T nexus - a relationship between a SCSI Initiator Port and a
          SCSI Target Port, according to [SAM2].  For iSCSI, this
          relationship is a session, defined as a relationship between
          an iSCSI Initiator's end of the session (SCSI Initiator Port)
          and the iSCSI Target's Portal Group.  The I_T nexus can be
          identified by the conjunction of the SCSI port names or by the
          iSCSI session identifier SSID.  iSCSI defines the I_T nexus
          identifier to be the tuple (iSCSI Initiator Name + 'i' + ISID,
          iSCSI Target Name + 't' + Portal Group Tag).

          NOTE: The I_T nexus identifier is not equal to the session
          identifier (SSID).

3.4.3.  Consequences of the Model

   This section describes implementation and behavioral requirements
   that result from the mapping of SCSI constructs to the iSCSI
   constructs defined above.  Between a given SCSI initiator port and a
   given SCSI target port, only one I_T nexus (session) can exist.  No
   more than one nexus relationship (parallel nexus) is allowed by
   [SAM2].  Therefore, at any given time, only one session can exist
   between a given iSCSI initiator node and an iSCSI target node, with
   the same session identifier (SSID).

   These assumptions lead to the following conclusions and requirements:

   ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal
   Group (SCSI target port), there can only be one session with a given
   value for ISID that identifies the SCSI initiator port.  See Section
   10.12.5 ISID.

   The structure of the ISID that contains a naming authority component
   (see Section 10.12.5 ISID and [RFC3721]) provides a mechanism to
   facilitate compliance with the ISID rule.  (See Section 9.1.1
   Conservative Reuse of ISIDs.)

Top      Up      ToC       Page 42 
   The iSCSI Initiator Node should manage the assignment of ISIDs prior
   to session initiation.  The "ISID RULE" does not preclude the use of
   the same ISID from the same iSCSI Initiator with different Target
   Portal Groups on the same iSCSI target or on other iSCSI targets (see
   Section 9.1.1 Conservative Reuse of ISIDs).  Allowing this would be
   analogous to a single SCSI Initiator Port having relationships
   (nexus) with multiple SCSI target ports on the same SCSI target
   device or SCSI target ports on other SCSI target devices.  It is also
   possible to have multiple sessions with different ISIDs to the same
   Target Portal Group.  Each such session would be considered to be
   with a different initiator even when the sessions originate from the
   same initiator device.  The same ISID may be used by a different
   iSCSI initiator because it is the iSCSI Name together with the ISID
   that identifies the SCSI Initiator Port.

   NOTE: A consequence of the ISID RULE and the specification for the
   I_T nexus identifier is that two nexus with the same identifier
   should never exist at the same time.

   TSIH RULE: The iSCSI Target selects a non-zero value for the TSIH at
   session creation (when an initiator presents a 0 value at Login).
   After being selected, the same TSIH value MUST be used whenever the
   initiator or target refers to the session and a TSIH is required.  I_T Nexus State

   Certain nexus relationships contain an explicit state (e.g.,
   initiator-specific mode pages) that may need to be preserved by the
   device server [SAM2] in a logical unit through changes or failures in
   the iSCSI layer (e.g., session failures).  In order for that state to
   be restored, the iSCSI initiator should reestablish its session
   (re-login) to the same Target Portal Group using the previous ISID.
   That is, it should perform session recovery as described in Chapter
   6. This is because the SCSI initiator port identifier and the SCSI
   target port identifier (or relative target port) form the datum that
   the SCSI logical unit device server uses to identify the I_T nexus.

(page 42 continued on part 3)

Next RFC Part