[dat-discussions] RE: [openib-general] Re: [swg] Re: private data...

[Kanevsky, Arkady]

The real issue is how Consumer specifies whether to use current CM
protocol with unformated private data or proposed CM with formated
private data.
So the extra bit tells CM how to interpret private data.
connection request is delivered to Service ID specified in the request.
Local CM does not have to know which TCP port that Service ID
corresponds.
CM does not care about TCP ports. But the ULP above CM does that is why
it will get formated private data. 

It can even be possible for that ULP to handle both formats of REQs.
In one case it will get only private data and can make basic assumptions
base on it, and in another it will get full socket address and can make
the full distinctions of the requestor based on it.

IBTA plans to define new CM which formats the private data.

DAPL may decide to only support new CM format.
Or may decide to support both with some caveats.

But the issue for OpenIB CM will still remain to support both or not?
and if yes (for backwards compatibility) how to expose it?

The issue how IP address is translated to IB is done by IPoIB.

There is a need for a facility that translate TCP port to Service ID.
Mapping should be defined by IBTA. That is what being discussed there.
This is part of the protocol definition not API.

Once this is defined ULP can decide on which Service ID(s) to listen.
Requestor can send conn req to a specific Service ID (IB specific)
or use higher level abstraction - TCP port. 
CM may be capable to translate TCP port to Service ID based on ULP.
For example, iSER over IPoIB will be mapped to one Service ID and
native iSER over IB will be mapped to another. But this is not simple.
On another hand every intermediate level protocol (SDP, IPoIB) can
do conversion. But this is also hard and is extension of existing
protocol.
or at least a facility on top of it.



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: Fab Tillier [mailto:ftillier at silverstorm.com] 
> Sent: Thursday, October 20, 2005 4:45 PM
> To: 'Sean Hefty'
> Cc: Lentini, James; swg at infinibandta.org; 
> dat-discussions at yahoogroups.com; openib-general at openib.org
> Subject: [dat-discussions] RE: [openib-general] Re: [swg] Re: 
> private data...
> 
> 
> > From: Sean Hefty [mailto:mshefty at ichips.intel.com]
> > Sent: Thursday, October 20, 2005 1:30 PM
> > 
> > Using a bit in the REQ means that the higher level connection 
> > management protocol needs to receive and process CM REQs.  How does 
> > the REQ get routed to the higher level CM?  If it's based 
> on service 
> > ID, then why is the bit needed at all?  If I'm routing 
> based on this 
> > bit, then I could just as easily define this protocol to exist on a 
> > single service ID, and still route on service ID.  The 
> upper level CM 
> > can then demultiplex to the correct application based on 
> the addresses 
> > found in the private data.
> > 
> > Using a reserved bit is essentially adding a 65th bit to 
> the service 
> > ID.
> 
> I disagree.  Using a reserved bit indicates that the first 
> 32-bytes of private data have a known format and can be 
> evaluated by an entity shared by multiple clients (the CMA).
> 
> The service ID on the other hand indicates what protocol is 
> implemented over the connection once it is established.
>  
> > In any case, I don't see how defining this private data 
> format without 
> > specifying which service IDs use it is all that useful.
> 
> You can do both, but I think they are separate.  The protocol 
> can be useful outside the scope of DAPL or NFS/RDMA.  WSD 
> could use it, and then use a higher-level CM to do all the IP 
> to IB path management rather than duplicating it.
> 
> - Fab
> 
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> --------------------~--> 
> Fair play? Video games influencing politics. Click and talk 
> back! http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/W6uqlB/TM
> --------------------------------------------------------------
> ------~-> 
> 
>  
> Yahoo! Groups Links
> 
> <*> To visit your group on the web, go to:
>     http://groups.yahoo.com/group/dat-discussions/
> 
> <*> To unsubscribe from this group, send an email to:
>     dat-discussions-unsubscribe at yahoogroups.com
> 
> <*> Your use of Yahoo! Groups is subject to:
>     http://docs.yahoo.com/info/terms/
>  
> 
>