[openib-general] RDMA connection and address translation API

[Caitlin Bestler]

On 8/24/05, Fab Tillier <ftillier at silverstorm.com> wrote:
> > From: Roland Dreier [mailto:rolandd at cisco.com]
> > Sent: Wednesday, August 24, 2005 10:16 AM
> >
> >     Fab> Knowledge of actual IP addresses would be up to the consumer.
> >     Fab> However, the IB CM can facilitate checks by allowing the user
> >     Fab> to specify an offset and length in the private data to match
> >     Fab> to for incoming requests.
> >
> > This seems too complex and at the same time too limited to me.  For
> > one thing -- although I think ATS should die -- this doesn't support
> > ATS reverse lookups.
> 
> I think if all ULPs provide their source and destination IP in the private data,
> you can eliminate the reverse lookup altogether.  A simple forward lookup is all
> that's needed to validate that the source GID in the REQ matches the reported
> source IP in the private data.  The forward lookup could be done via ATS or via
> ARP, but the CM doesn't need to care which method is used.
> 

That is not an option.

The applications are expecting source/destination network addresses
that come from a network layer, not from the peer application. IP has
no problem meeting this requirement. This is an IB problem that needs
to be solved within the scope of IB without changing any ULPs.

> > For another, it doesn't handle something like
> > the SDP Hello header, where the IP version is at a certain offset, and
> > then the IP address is interpreted according to the IP address.
> 
> Why can't the IPV field be ignored?  If a listen wants only IPV4 addresses, it
> would specify a 16-byte compare buffer with the first 12 bytes zero, the next 4
> filled with the IPV4 address, and would set the offset to that of the hello
> message's destination address (32).
> 
> > What makes it really ugly is that it's perfectly reasonable for one
> > consumer to listen to a service at 192.168.11.12 and another consumer
> > to listen to the same service at 192.168.98.99.  How do we handle this
> > in the IB case??
> 
> As long as the service IP address (the local address on the listening side) is
> always advertised in the same place in the private data, this isn't a problem.
> The compare lengths and offsets would be identical for both services, but the
> compare buffer contents would differ.  Did I miss what you were getting at?
> 

The concensus when this issue was debated in the DAT Collaborative was
that there was no transport neutral way to specify a set of addresses to listen
on other than "all addresses supported by this device".

As noted in another posting, it is easy to support "all for device" and "this
address only" with transport neutral interfaces. Anything else is problematic.