On Thu, 23 Jun 2005, Fab Tillier wrote:
From: Roland Dreier [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 23, 2005 10:32 AM
James> Perhaps a bit of motivation of how the GID->IP service can
James> be used is in order.
James> kDAPL uses this feature to provide the passive side of a
James> connection with the IP address of the remote peer. kDAPL
James> consumers can use this information as a weak authentication
James> mechanism.
This seems so weak as to be not useful, and rather expensive to boot.
To implement this, a system receiving a connection request would have
to perform an SA query to map the remote LID back to a GuidInfo
record, and then for each GID attached to the remote LID, somehow
retrieve the set of IP addresses configured for that GID (assuming
that is somehow even possible).
This reverse lookup was something that I worked to accommodate in my
proposed changes to expand DAPL ATS to support multiple IP
addresses. The revised DAPL ATS proposal establishes the notion of
a primary IP address that would be used for such validation.
However, I still think the reverse lookup (GID->IP) is weak as there
is no way to tell which IP the source really used.
IMO it would be much better to put the source and destination
addresses into the CM private data, but this supposedly creates a
wire protocol which the DAT collaborative wants to avoid at all
costs.
If we place the IP address into the CM private data it will create
interoperability problems. Upper layer protocols like NFS-RDMA, would
only be able to communicate with implementations that also placed the
address in the CM private data.
How would an NFS-RDMA client written directly to the IB verbs layer
communicate with an NFS-RDMA server written to kDAPL?
The NFS-RDMA client in this configuration would need to place the IP
address in the CM private data. In effect, we've added a new (albeit
small) component to the NFS-RDMA protocol.
Rather than add this mechanism into every ULP, I think it would be
better to provide it as a core service of the network.
james
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
