[storm] Proposed text changes for the connection allocation problem

[Michael Ko <[e-mail]>]

These are the changes I intend to incorporate into the existing draft to
solve the connection allocation problem by using the iSER Hello exchanges.
Please comment.

5.1.1  Initiator Behavior

original:

If the outcome of the iSCSI negotiation is to enable iSER-assisted mode,
then on the initiator side, prior to sending the Login Request with the T
(Transit) bit set to 1 and the NSG (Next Stage) field set to
FullFeaturePhase, the iSCSI Layer MUST request the iSER Layer to allocate
the connection resources necessary to support RCaP by invoking the
Allocate_Connection_Resources Operational Primitive.

replacement:

If the outcome of the iSCSI negotiation is to enable iSER-assisted mode,
then on the initiator side, prior to sending the Login Request with the T
(Transit) bit set to 1 and the NSG (Next Stage) field set to
FullFeaturePhase, the iSCSI Layer SHOULD request the iSER Layer to allocate
the connection resources necessary to support RCaP by invoking the
Allocate_Connection_Resources Operational Primitive.

deleted:

If the iSER Layer at the initiator is successful in allocating the
connection resources necessary to support RCaP, the following events MUST
occur in the specified sequence:  [The numbered items will be retained but
without the numbering.]

new:

If the iSCSI Layer on the initiator side allocates the connection resources
to support RCaP only after it receives the final Login Response PDU from
the target, then it may not be able to handle the number of unexpected
iSCSI control-type PDUs (as declared by the MaxOutstandingUnexpectedPDUs
key from the initiator) that can be sent by the target before the buffer
resources are allocated at the initiator side.  In this case the
iSERHelloRequired key MUST be negotiated to Yes so that the initiator can
allocate the connection resources before sending the iSER Hello Message.
See section 5.1.3 for more details.

5.1.3  iSER Hello Exchange

new:

The connection resources can be allocated at the initiator side after it
has received the final Login Response PDU from the target.  To prevent the
potential problem caused by the target sending the number of unexpected
iSCSI control-type PDUs as determined by the MaxOustandingUnexpectedPDUs
key allowed in the FullFeaturePhase, the iSER Hello exchanges can be used.
This allows the initiator to allocate the connection resources before
sending the iSER Hello Message.  The iSERHelloRequired key is used by the
initiator to determine if it is dealing with a target that supports the
iSER Hello exchanges.

As the iSERHelloRequired key is not defined in [RFC5046], an
initiator/target must be able to deal with a target/initiator that does not
understand the key or support the iSER Hello exchanges.

For a target, if the iSERHelloRequired key is not negotiated, it MUST still
respond with the iSER HelloReply Message when it recieves the iSER Hello
Message.  If the iSERHelloRequired key is negotiated to No or
NotUnderstood, a target MAY choose to terminate the connection; otherwise
it SHOULD delay sending any unexpected control-type PDUs until one of the
following events has occurred:

1. A PDU is received from the initiator after it sends the final Login
Response PDU.

2. A system configurable timeout period, say one second, has expired.

For an initiator, if the iSERHelloRequired key is negotiated to No or
NotUnderstood, it MAY choose to terminate the connection; otherwise it
SHOULD do one of the following:

1. Allocate the connection resources before sending the final Login Request
PDU.

2. Allocate one or more buffers for receiving unexpected control-type PDUs
from the target before sending the final Login Request PDU.  This reduces
the possibility of the unexpected control-type PDUs causing the RCaP
connection to close before the connection resources have been allocated.

10.1.3.4 iSER Protocol Errors

original:

Conversely, it is a protocol error if the iSER Hello Message is sent by the
iSER Layer at the initiator when iSERHelloRequired is negotiated to "No".

new:

Conversely, if the iSER Hello Message is sent by the iSER Layer at the
initiator when iSERHelloRequired is negotiated to "No", the iSER Layer at
the target MAY treat this as a protocol error or respond with an iSER
HelloReply Message.

Mike