RE: iSCSI: response to second login (with same ISID)

["Lakshmi Ramasubramanian" <nramas@windows.microsoft.com>]

How is a target driver suppose to respond to a login from an initiator,
when
another initiator already has a session going on with the given target?
Is the target 
suppose to reject the second login (say, with an error "device busy" or
something simialar)? 

Thanks!
 -lakshmi 

-----Original Message-----
From: Santosh Rao [mailto:santoshr@cup.hp.com] 
Sent: Monday, May 21, 2001 5:39 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1)
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: response to second login (with same ISID)


"KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:

>  Since
> persistent reservations are SCSI layer things, lets try to find a way 
> to keep their implementation from forcing unnecessary limitations at 
> the iSCSI layer.  The use of init. name+ISID+target name for 
> identifying persistent reservations needs further discussion before we

> allow it to creep into iSCSI protocol rules.  I've very uncomfortable 
> with treating ISID like a fixed address just because SCSI persistent 
> reservations don't have a sufficient SCSI layer mechanism.


A fixed port identifier of some form is a basic O.S. requirement to be
able to persistently bind the LUNs it sees to some form of device files.
This binding is based on either a physical port identifier or name (ex :
pSCSI target id, FC nport_id, FC port WWN) or in the case of logical
service delivery ports like iSCSI to a logical port identifier such as
the ISID.

A fixed address usage is not only for persistent reservation semantics.
The host O.S. SCSI stacks need *something* that allows them to
persistently bind device files to the same LUNs on each reboot. The ISID
is one form of achieving this. 



> Seems like this will force all kinds of layering
> violations into iSCSI.

Not clear why this is so. Consider the ISID as a logical port identifier
that id considered as a SCSI transport layer endpoint.

Regards,
Santosh