Re: some numbering clarifications

[julian_satran@il.ibm.com]

Pierre,

- Command numbering. Initiator sets InitCmdRN to 0. All the others can also
be 0.
   is there any drawback?

- Data

   the numbering is per task! (I will try to make that  clear)

Julo

Pierre Labat <pierre_labat@hp.com> on 19/10/2000 21:18:02

Please respond to Pierre Labat <pierre_labat@hp.com>

To:   ips@ece.cmu.edu
cc:
Subject:  Re: some numbering clarifications




julian_satran@il.ibm.com wrote:


Julian,

Thank you for these clarifications.
Below are some questions to clarify a bit more.

Regards,

Pierre

>
> 1.1.1     Ordering and iSCSI numbering
>
>    The NOP message PDUs are not associated with a task, are meant for
>    immediate delivery, and their only purpose is synchronizing the
ordering
>    registers of the target and initiator.
>
> 1.1.1.1   Command numbering
>
>    iSCSI supports ordered command delivery within a session.  All
commands
>    (initiator-to-target) and responses (target-to-initiator) are
numbered.
>    Any SCSI activity is related to a task (SAM-2). The task is identified
>    by the Initiator Task Tag for the life of the task.  Commands in
transit
>    from the initiator SCSI layer to the target SCSI layer are numbered by
>    iSCSI and the number is carried by the iSCSI PDU as CmdRN
>    (Command-Reference-Number).
>    The numbering is session-wide.  All iSCSI PDUs that have a task
>    association carry this number. CmdRNs are allocated by the initiator
>    iSCSI within a 32 bit unsigned counter (modulo 2**32).  The value 0 is
>    reserved and used to mean immediate delivery. Comparisons and
arithmetic
>    on CmdRN SHOULD use Serial Number Arithmetic as defined in [RFC1982]
>    where SERIAL_BITS = 32.
>    The target may choose to deliver some task management commands for
>    immediate delivery.  The means by which the SCSI layer may request
>    immediate delivery for a command or by which iSCSI will decide by
itself
>    to mark a PDU for immediate delivery are outside the scope of this
>    document.
>    CmdRNs are significant only during command delivery to the target.
Once
>    the device serving part of the target SCSI has received a command,
CmdRN
>    ceases to be significant.  During command delivery to the target, the
>    allocated numbers are unique session wide.  The initiator and target
are
>    assumed to have three registers that define the allocation mechanism -
>    CmdRN - the current command reference number advanced by 1 on each
>    command shipped; ExpCmdRN - the next expected command by the target -
>    acknowledges all commands up to it; MaxCmdRN - the maximum number to
be
>    shipped - MaxCmdRN - ExpCmdRN defines the queuing capacity of the
>    receiving iSCSI layer.
>    The target SHOULD NOT transmit a MaxCmdRN that is more than 2**31 - 1
>    above the last ExpCmdRN.  CmdRN can take any value from ExpCmdRN to
>    MaxCmdRN except 0. The target will reject any command outside this
range
>    or duplicates within the range not flagged with the retry bit (the X
bit
>    in the opcode).  The target and initiator registers MUST uphold causal
>    ordering.
>
>    iSCSI initiators MUST implement the command/request numbering scheme
>    only if they support more than one connection.

In the case where initiators support only one connection:
1) does the initiator have to inform the target that it will not implement
the

numbering? How does it do?

2) if the initiator doesn't implement the command numbering, what is the
value

in the numbering fields (CmdRn and ExpCmdRN)? Is it  0? Is it undefined?

3) in the case it is undefined and the target is not informed that the
initiator
 does implement the command numbering, how can the target calculate
the ExpCmdRN and MaxCmdRN on undefined values? From what you said
below the targets must in any case provide ExpCmdRN and MaxCmdRN values.

>
>
>    iSCSI targets MAY use the command/request numbering scheme for ordered
>    delivery when they support multiple connections. However, they MUST
>    provide ExpCmdRN and MaxCmdRN values that will enable the initiator to
>    make progress.
>
> 1.1.1.2   Response/Status numbering
>
>    Responses in transit from the target to the initiator are numbered.
The
>    StatRN (Status Reference Number) is used for this purpose.  To enable
>    command recovery the target MAY maintain enough state to enable data
and
>    status recovery after a connection failure.
>    A target can discard all the state information maintained for recovery
>    after the status delivery is acknowledged through ExpStatRN.
>    A large difference between StatRN and ExpStatRN indicates a failed
>    connection.
>
>    Initiators and Targets MUST support the response-numbering scheme
>    regardless of the support for command recovery.
>
> 1.1.1.3   Data PDU numbering
>
>    Incoming Data PDUs MAY be numbered by a target to enable fast recovery
>    of long running READ commands.

This numbering is session wide or task wide?
I don't see the interest to have it session wide. If you agree, could you
specify that it is task wide?

>
>    Data PDUs are numbered with DataRN.  NOP command PDUs carrying the
same
>    Initiator Tag as the Data PDUs are used to acknowledge the incoming
Data
>    PDUs.  Support for Data PDU acknowledgement and the
>    maximum number of unacknowledged data PDUs are negotiated at login.
>    In a PDU carrying both data and status the number refers to the Status
>    and the last set of data blocks is implicitly acknowledged when Status
>    is acknowledged.