On 6/28/05, Roland Dreier <[EMAIL PROTECTED]> wrote: > James> First off, here [are the] requirement we are trying to satisfy: > > James> On the passive side of a connection, a InfiniBand kDAPL > James> provider must determine a source IB address for an > James> InfiniBand connection request. This information can be > James> obtain by a kDAPL consumer either in the > James> DAT_CONNECTION_REQUEST_EVENT's dat_cr_arrival_event_data or > James> dat_cr_query()'s dat_cr_param structure. > > James> By interoperable, we mean that the solution must not > James> introduce a non-standard protocol or force ULPs using kDAPL > James> to perform special operations when using an InfiniBand > James> network. > > Since these two points are mutually contradictory -- the IB > communication management protocol does not carry enough information > for a connection request to be mapped uniquely back to a source > address -- we need to figure out which one to drop. > > I would argue in favor of the solution selected by SDP: when defining > the binding of an abstract protocol to the IB transport, put the > source and destination IP addresses in the IB-specific connection > setup messages. > > - R.
The remote identification is a service being provided *to* the ULP. SDP, or any other application, can provide whatever additional information desired. The "IA Address" is as authenticated as the local network management allows it to be. Private data exchanged by applications is outside the view of the network administrator and therefore can never be authenticated in the same way. For NFSoRDMA, for example, "authenticating" a remote peer based upon an application supplied field in the private data is obviously inappropriate. The GID that InfiniBand does supply *does* fully qualify as an IP Address, and can be the address supplied as the "remote address" even *if* there are additional methods of translating IPv4 addresses to GIDs (or even IPv6, but why you would want to *translate* an IPv6 address to a GID rather than just using the GID *as* an IPv6 address is beyond me). To clarify: DAT *does* fully support the use of GIDs as IA Addresses, however it assumes that link local addresses will not be presented to the Consumer (at least when the host is attached to more than one subnet). It assumes that they will be at least upgraded to site-local. The IA Address can be easily sub-divided into IPv4 addresses that need translation, IPv6 addresses that need translation and IPv6 addresses that are also GIDs and therefore do not need translation. The existence of the alternate solutions was largely driven by the need to deploy early solutions that were *not* integrated with the OS naming system, and therefore could not assume that the OS already knew what to do with a GID. That is no longer a problem. Therefore there is no need to change any of the DAT semantics. They are adequate as they are, and in particular there is no need to eliminate reporting of remote peer addresses -- something that is both easy and useful for IP networks. And a feature that is already in use. _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general