<html><body>
<p>The SDP port mapper protocol is required, because the well known SDP port is "not" the targeted port.<br>
<br>
In the case of the RDMA Service, the targetted port may very well be a well known port (e.g. one of the two iSCSI ports), but the only point of the RDMA Service is to let the listening end know "I want the iSCSI well known port, that is RDMA aware".<br>
<br>
It seems to me that for ULPs that are RDMA aware, there is no need for a port mapper. However, over IB there is a need to know that 1) its the RDMA aware service being requested; and 2) to leverage the IP stack, the IP address info.<br>
<br>
More comments bounded by <rr> below.<br>
<br>
Thanks,<br>
<br>
Renato J Recio<br>
Chief Architect, eServer I/O<br>
IBM Distinguished Engineer<br>
Member IBM Academy of Technology<br>
Tel 512-838-3685, T/L 678-3685<br>
<br>
<img src="cid:10__=09BBFA28DF12444D8f9e8a93df938@us.ibm.com" width="16" height="16" alt="Inactive hide details for Michael Krause <krause@cup.hp.com>">Michael Krause <krause@cup.hp.com><br>
<br>
<br>
<table V5DOTBL=true width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="1%"><img src="cid:20__=09BBFA28DF12444D8f9e8a93df938@us.ibm.com" border="0" height="1" width="72" alt=""><br>
</td><td style="background-image:url(cid:30__=09BBFA28DF12444D8f9e8a93df938@us.ibm.com); background-repeat: no-repeat; " width="1%"><img src="cid:20__=09BBFA28DF12444D8f9e8a93df938@us.ibm.com" border="0" height="1" width="225" alt=""><br>
<ul>
<ul>
<ul>
<ul><b><font size="2">Michael Krause <krause@cup.hp.com></font></b>
<p><font size="2">11/16/2005 04:15 PM</font></ul>
</ul>
</ul>
</ul>
</td><td width="100%"><img src="cid:20__=09BBFA28DF12444D8f9e8a93df938@us.ibm.com" border="0" height="1" width="1" alt=""><br>
<font size="1" face="Arial"> </font><br>
<font size="2"> To: </font><font size="2">"Kanevsky, Arkady" <Arkady.Kanevsky@netapp.com></font><br>
<font size="2"> cc: </font><font size="2">swg@infinibandta.org, openib-general@openib.org</font><br>
<font size="2"> Subject: </font><font size="2">Re: [swg] Re: [openib-general] RE: [dat-discussions] socket based connectionmodel for IB proposal - round 3</font></td></tr>
</table>
<br>
<br>
<font size="4" face="Times New Roman">At 10:22 AM 11/15/2005, Sean Hefty wrote:</font>
<ul>
<ul><font size="4" face="Times New Roman">Kanevsky, Arkady wrote:</font>
<ul>
<ul><font size="4" face="Times New Roman">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.</font></ul>
</ul>
<font size="4" face="Times New Roman"><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.</font><br>
<ul>
<ul><font size="4" face="Times New Roman">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.</font></ul>
</ul>
<font size="4" face="Times New Roman"><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>
</font>
<ul>
<ul><font size="4" face="Times New Roman">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.</font></ul>
</ul>
<font size="4" face="Times New Roman"><br>
Ideally, SDP should use this same mechanism, but requires changes to SDP.</font></ul>
</ul>
<font size="4" face="Times New Roman"><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>
</font><br>
<b><font size="4" face="Times New Roman"><rr> No.</font></b><font size="4" face="Times New Roman"> Mike, the intent is not to use this protocol for a ULP that is not RDMA aware and runs over IPoIB. Similarly, the intent is not to use this protocol fo a ULP that is not RDMA aware, but depends on SDP to help </font><b><font size="4" face="Times New Roman">a little </font></b><font size="4" face="Times New Roman">by leveraging RDMA as much as possible without exposing RDMA primitives (RDMA Write/Read) to the ULP.</font><br>
<br>
<font size="4" face="Times New Roman">Instead, the intent is to use this protocol for a ULP that is RDMA aware.</font><br>
<br>
<font size="4" face="Times New Roman">Think of it as...</font><br>
<font size="4" face="Times New Roman">IPoIB uses IP stack for port management (reaching well known ports, port mapping for dynamic ports, ...).</font><br>
<font size="4" face="Times New Roman">SDP uses the IB SDP Service for managing ULP ports that are not RDMA aware, but we want to help a little.</font><br>
<font size="4" face="Times New Roman">We need a similar IB RDMA Service for managing ULP ports that RDMA aware. </font><br>
<br>
<font size="4" face="Times New Roman">I brought this up in the RDMAC many moons ago. It seems to me that for iWARP the solution is a little more straight forward, because the stack stays IP through out. That is, if the active side (in IB terms :{) wants to connect to a well known port on the passive side, the RDMA negotiation can occur in band (e.g. as it does for iSER). However, given we don't have the IP stack through out, we need an RDMA service that allows an active side RDMA aware ULPs to ask the passive side ULP "are you RDMA aware?". That Service is what is being proposed. </font><b><font size="4" face="Times New Roman"><rr></font></b><br>
<font size="4" face="Times New Roman"><br>
</font>
<ul>
<ul>
<ul>
<ul><font size="4" face="Times New Roman">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.</font></ul>
</ul>
<font size="4" face="Times New Roman"><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>
</font>
<ul>
<ul><font size="4" face="Times New Roman">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.</font></ul>
</ul>
<font size="4" face="Times New Roman"><br>
I didn't follow this.</font></ul>
</ul>
<font size="4" face="Times New Roman"><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.</font><br>
<br>
<b><font size="4" face="Times New Roman"><rr> But they can't.</font></b><font size="4" face="Times New Roman"> Because for IB, we will still need a Service ID (see CM spec chapter) </font><b><font size="4" face="Times New Roman">and </font></b><font size="4" face="Times New Roman">the SDP Service ID is not applicable (e.g. we will not be running SDP between iSCSI and iSER). </font><b><font size="4" face="Times New Roman"><rr></font></b><font size="4" face="Times New Roman"><br>
<br>
</font>
<ul>
<ul>
<ul>
<ul><font size="4" face="Times New Roman">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.</font></ul>
</ul>
<font size="4" face="Times New Roman"><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.</font></ul>
</ul>
<font size="4" face="Times New Roman"><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>
</font><b><font size="4" face="Times New Roman"><rr> Read my comments above. <rr></font></b><br>
<font size="4" face="Times New Roman"><br>
Mike</font>
</body></html>