What I'm going to do for the name server extension for FCP-2
Jeff Stai
j_stai at qlc.com
Wed Dec 15 13:47:01 PST 1999
* From the T10 Reflector (t10 at t10.org), posted by:
* Jeff Stai <j_stai at qlc.com>
*
Bob - The notes I took from the discussion
differ from your proposal:
- New 255-byte "FC-4 Descriptor" Object.
- Register and Query would be based on FC-4 TYPE Object,
which is a 32-bit map.
- Register request contains:
- Port Identifier Object
- FC-4 TYPE Object
- FC-4 Descriptor Object, corresponding to first bit
set in FC-4 TYPE Object
- FC-4 Descriptor Object, corresponding to second bit
set in FC-4 TYPE Object
- etc.
- Query request contains:
- Port Identifier Object
- FC-4 TYPE Object
- Query response contains:
- FC-4 Descriptor Object, corresponding to first bit
set in FC-4 TYPE Object
- FC-4 Descriptor Object, corresponding to second bit
set in FC-4 TYPE Object
- etc.
- The point I heard was that this form allows all FC-4s
to be registered and queried at once. I heard strong support
for this!
- The new FC-4 Descriptor Object is NOT returned by Get All Next.
- The four bit flag field is a separate item and
does not change from what is defined in rev 6.0.
Some folks were going to come back with a way to
register those bits.
Bob - I don't necessarily disagree with your proposal
(except for some minor details easily corrected I bet).
But your proposal contains some elements that I distinctly
recall were objected to during the discussion. And I came
away believing what I said (above) is what was agreed to.
Hopefully those with opinions will now weigh in and
correct one of us... - js
> -----Original Message-----
> From: Bob Snively [mailto:Bob.Snively at EBay.Sun.COM]
> Sent: Wednesday, December 15, 1999 12:39 PM
> To: fc at network.com; t10 at t10.org
> Subject: What I'm going to do for the name server extension for FCP-2
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Bob Snively <Bob.Snively at EBay.Sun.COM>
> *
>
> Is there anything I have missed here?
>
> New rev of T10/99-325r2:
>
> "The result of the December meeting discussion is that Jeff Stai will
> define in FC-GS-3 a type specific name server port object.
> FCP-2 will define
> that name server object as a control header, containing "Target" and
> "Initiator" bits and the SCSI INQUIRY command data for targets. An
> additional proposal may be forthcoming on this question."
>
>
> Jeff,
>
> I would propose that the payload of the type specific object
> request should
> include:
>
> Type (in case there are more than one types for that
> port) (1 byte)
> Port identifier
> (3 bytes)
>
> I would propose that the payload of the type specific object response
> should include, by anology with the symbolic port name:
>
> Type specific object Length (m)
> (1 byte)
> Type specific flags
> (3 bytes)
> Type specific object
> (m bytes)
> Reserved
> (255-m bytes)
>
> The field would be a constant length of 260 bytes.
>
> For FCP-2, the type specific flags would include bits for:
>
> "permanent initiator"
> "temporary initiator"
> "target"
>
> The type specific object would be the LUN 0 INQUIRY data, truncated to
> 255 bytes if required.
>
> Requests for a type not supported would return a CT_RJT (which may not
> be defined yet).
>
> Requests for a supported type where the information was not
> available would
> return a type specific object length of 0 in the 260 byte response.
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10
mailing list