rfc3720.txt

一个学习iSCSI协议的文档

   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
   recovery.

3.2.2.  Ordering and iSCSI Numbering

   iSCSI uses Command and Status numbering schemes and a Data sequencing
   scheme.

   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.






Satran, et al.              Standards Track                    [Page 19]

RFC 3720                         iSCSI                        April 2004


   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].

3.2.2.1.  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.





Satran, et al.              Standards Track                    [Page 20]

RFC 3720                         iSCSI                        April 2004


   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
   time.

   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
   act).

   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:





Satran, et al.              Standards Track                    [Page 21]

RFC 3720                         iSCSI                        April 2004


      -  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 +
         1.

   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
   follows:

      -  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
   scheme.



Satran, et al.              Standards Track                    [Page 22]

RFC 3720                         iSCSI                        April 2004


   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
   Instances).

   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.

3.2.2.2.  Response/Status Numbering and Acknowledging

   Responses in transit from the target to the initiator are numbered.
   The StatSN (Status Sequence Number) is use