Serial problems with Reserve/Release

scheible at vnet.ibm.com scheible at vnet.ibm.com
Mon Jun 17 13:44:12 PDT 1996


* From the SCSI Reflector, posted by:
* scheible at VNET.IBM.COM
*
Peter Johansson wrote...

> Because of various problems unique to Serial Bus (physical ID's change upon
> bus resets, the bus is external and may be vulnerable to malefactors who
> connect through bridges, etc.), SBP-2 is likely to handle reservations
> persistent and otherwise, through transport protocol-specific means instead
> of RESERVE and RELEASE.
>
> In the case of SBP-2, this probably means a login request that provide for
> independent target verification of an initiator's unique 64-bit ID (as  means
> of screening out impostors).  Password mechanisms will also be provide as an
> escape when prior owner's EUI-64 is, for whatever the reason, unavailable.

   What I am trying to do is fix SCSI-3 to be more serial friendly.
(that is not read serial fiend-ly).  How do we fix SCSI-3?
Since SBP is SCSI-3 compliant, and SCSI-3 mandates the use of
RELEASE(6)/RESERVE(6) with their 3 bit addresses at this time, what
is the SBP stand regarding this?  What I would like to do is to get
a consensus on how to change SCSI-3.  Some people would like to
obsolete RESERVE/RELEASE and mandate PERSISTENT RESERVE IN/OUT.

   I suggested using the making RESERVE(6)/RELEASE(6) optional and
keeping RESERVE(10)/RELEASE(10) mandatory.  Since SSA uses globally
unique IDs that are maintained during hot plug and resets, SSA could
accept this.  It looks like SBP has a problem with this that could be
avoided with the use of transport level procedures.

Any thoughts?

Thanks,
John Scheible
scheible at vnet.ibm.com




More information about the T10 mailing list