What I'm going to do for the name server extension for

Bill Martin bmartin at gadzoox.com
Sun Dec 19 19:07:50 PST 1999


* From the T10 Reflector (t10 at t10.org), posted by:
* Bill Martin <bmartin at gadzoox.com>
*
I agree with Jeff on what was agreed to.

Bill Martin					Phone:  (916) 772-3658
Sr. Principal Engineer		email:    bmartin at gadzoox.com
Fibre Channel Standards
Gadzoox Networks Inc.


	-----Original Message-----
	From:	Jeff Stai [SMTP:j_stai at qlc.com]
	Sent:	Wednesday, December 15, 1999 6:27 PM
	To:	'Bob Snively'; fc at network.com; t10 at t10.org
	Subject:	RE: What I'm going to do for the name server
extension for

	FCP-2
	Date: Wed, 15 Dec 1999 13:47:01 -0800
	MIME-Version: 1.0
	X-Mailer: Internet Mail Service (5.5.2448.0)
	Content-Type: text/plain;
		charset="iso-8859-1"
	Sender: owner-fc at network.com
	Precedence: bulk
	Reply-To: Jeff Stai <j_stai at qlc.com>

	*
	* From the fc reflector, 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