<html>
<body>
<font size=3>At 10:22 AM 11/15/2005, Sean Hefty wrote:<br>
<blockquote type=cite class=cite cite="">Kanevsky, Arkady wrote:<br>
<blockquote type=cite class=cite cite="">Which entity is responsible to
"use" the proposed protocol is an<br>
interesting one.<br>
I was assuming that this will be CM. After all the proposed protocol
is<br>
CM extension<br>
protocol.<br>
But it can be another entity module between CM and ULP.</blockquote><br>
The use of a reserved bit in the CM message indicates that the CM itself
needs to set this data. This requires communication between the CM
and IPoIB - in essence making IPoIB part of the CM. Removal of the
reserved bit is what permits another entity between the CM and the ULP to
perform this task.<br><br>
<blockquote type=cite class=cite cite="">While it is possible to do
wildcarding on the whole SID, I had not seen<br>
it is used selectively on individual bits of a SID or a
port.</blockquote><br>
This is what is done/needed to support SDP. A simple mask is
applied to the SID before comparing against a local
listen.<br><br>
<blockquote type=cite class=cite cite="">While SDP does the conversion to
IB SID from Ethernet port, this<br>
proposal<br>
shift the responsibility for port and IP address conversion from ULP<br>
down.</blockquote><br>
Ideally, SDP should use this same mechanism, but requires changes to
SDP.</font></blockquote><br>
Given SDP is an existing standard and implemented on a variety of
platforms, it would be best to not modify SDP in order to insure
interoperability. Hence, the new annex should only apply to ULP
that do not already communicate the IP address, etc. as part of the CM
exchange on IB and as part of the SDP port mapper on iWARP (the port
mapper enables completely transparent SDP usage underneath an application
with no source code changes required).<br><br>
<br>
<blockquote type=cite class=cite cite="">
<blockquote type=cite class=cite cite=""><font size=3>Protocol version.
This mean that in the future if protocol version will be<br>
bumped up we will have to change the SID on which Consumer listens on
and<br>
requests sent to. Not sure how to do that without changing ULP. Does not
look<br>
like a good idea.</blockquote><br>
As a note, I'm not saying that I prefer a more complex SID, just that
there is trade-off to be made that could provide for more ULP private
data.<br><br>
If the version changes, then the addressing has changed. The ULP
may need to change anyway in order to know how to interpret the
address. If they don't care about the protocol version or don't
need to know how to interpret the address, they can still wildcard the
version.<br><br>
<blockquote type=cite class=cite cite="">IP version. This can be
incorporated into SID. But if HCA has multiple IP addresses<br>
assigned to it the listening point need to specify its IP
address(es).<br>
The current verbs and/or API will have to be changed to support it.<br>
But if socket is passed to listen on it does have all the needed
info.<br>
Looks fine.</blockquote><br>
I didn't follow this.</font></blockquote><br>
The SDP port mapper protocol for iWARP already solves the multiple IP
address issue. The same concept / principles could be leveraged for
IB. I don't think the verbs need to be changed to support it as it
is just payload within CM messages for IB.<br><br>
<br>
<blockquote type=cite class=cite cite="">
<blockquote type=cite class=cite cite=""><font size=3>DAPL APIs (uDAPL
and kDAPL) does not expose local IP address for listen<br>
point.<br>
An additional API can be added to support passing local socket to
listen<br>
on<br>
instead of Connection Qualifier. Since it is addition no backwards<br>
compatibility issues.<br>
The current ULPs/Apps will still use "the default API address"
and the<br>
protocol assigned SID as connection qualifier.</blockquote><br>
The issue with DAPL is that it assumes that addressing has been resolved
to a specific device before communication between the client and server
have even occurred. I.e. the server must be clairvoyant and know
which device a connection request will be received on. Likewise, a
client must assume which local device is needed to connect to a given
remote address.</blockquote><br>
The nice thing about the SDP port mapper is that it allows the server and
client to dynamically determine the resolution prior to connection
establishment as well as gauge how many resources, preferred CA / port,
etc. to extend to the client.<br><br>
Mike</font></body>
</html>