[openib-general] round 2 - proposal for socket based connectionmodel

[Kanevsky, Arkady]

Sean,
answers in-line.
Arkady
 

Arkady Kanevsky                       email: arkady at netapp.com

Network Appliance                     phone: 781-768-5395

375 Totten Pond Rd.                  Fax: 781-895-1195

Waltham, MA 02451-2010          central phone: 781-768-5300

 

	-----Original Message-----
	From: Sean Hefty [mailto:sean.hefty at intel.com] 
	Sent: Tuesday, October 25, 2005 1:05 PM
	To: Kanevsky, Arkady; openib-general at openib.org;
swg at infinibandta.org
	Subject: RE: [openib-general] round 2 - proposal for socket
based connectionmodel
	
	

	Dear OpenIB, SWG and DAT members,

	enclosed is teh second version of the proposal.

	There are really 2 proposals that are related.

	The first one is encoding IP 5-tuple into REQ private data

	with small additional info for versioning and IB capabilities.

	The second is just a couple of ideas, not a real proposal,

	on maping of IP ports

	to IB Service IDs.

	 

	Comments on the private data format:

	 

	Combine major/minor version into a single field.  There's no
advantage to have two fields, so keep it simple.
	[AK] agree 

	 

	Remove ZB and SI bits.  These are unrelated to socket
addressing.
	[AK] That is true these are unrelated to socket addressing. But
since several ULPs over IB need this info

	it can be added to the generic CM extensions for IB.

	I will rename the proposal to deal with it.

	I prefer a single private data formating proposal rather then
several layered on top of each other.

	If IBTA think this is generic enough and want to redefine some
reserved fields for it - good.

	This is captured in discussion slides. 

	 

	If the destination port number is encoded in a service ID, then
it can be removed from the private data.
	[AK] This is dependent on how port mapping to Service ID is
done. But if SDP will incorporate this into hello-wold

	protocol this may still be needed. With 64-bytes Consumer
private data requirement relaxed saving 2 bytes

	will not make much difference. 

	 

	The transport protocol number could also be encoded in the
service ID and removed from the private data.  Actually, the version, IP
version, and source port could all be encoded in the service ID,
limiting the private data to just 32 bytes of IP addresses.
	[AK] Encoding IP version into Service ID sounds strange. Service
ID is a pprt equivalent. Sure it is much larger than IP ports but why
does CM extensions should encode more than port into it?

	Even with this Consumer private data is still only 60 bytes (not
old 64-bytes requirement).

	 

	- Sean

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20051025/cc6e9000/attachment.html>