Re: iSCSI failover and reconfiguration

[Mike Kazar <kazar@icubed.com>]

The problem with making this part of the login operation is that this type
of redirection needs to happen at other times aside from login.  In
general, what makes this type of data movement most useful is if it can
happen without regard to whether the data  is being accessed.

Most generally, a client might have a set of N commands outstanding when a
data move occurs, and of these N commands, K of them would succeed, and N-K
of them would return some standard error indicating that further requests
would be handled elsewhere.

Perhaps the same redirect and resolve strings could be used, but returned
by a specific text command instead of during the login process, so that the
redirection could happen at any time. 

Thus, a client, after having received this distinguished "Data moved" error
code, would send a text command with "SendRedirectResolve:yes" and the
server would then send back a text response of the forms "Redirect:
domain/<modifier>" or "Resolve:domain/<modifier>".

	Mike
		(kazar@spinnakernet.com)

>
>
>Here's a little proposal I wrote up a while back but never posted:
>
>When the initiator attempts to login to a given Target,
>it gets a response:
>
>Redirect: domain.name/modifier
>
>The initiator would attempt to connect to the new domain name and
>modifier. The initiator would follow at most 7 redirects.
>
>The redirected name is presented to the machine you connect to in
>the Target: field of the login message.
>
>A similar response is Resolve
>
>Resolve: domain.name/modifier
>
>Again, the initator should try to connect to the new machine.
>In this case, the original name should be presented to the target.
>
>This mechanism allows you to build primitive name resolution into iSCSI.
>
>-Costa
>
>
>