[openib-general] IB Address Translation service

[Yaron Haviv]

> -----Original Message-----
> From: openib-general-bounces at openib.org [mailto:openib-general-
> bounces at openib.org] On Behalf Of Hal Rosenstock
> Sent: Saturday, March 05, 2005 6:18 PM
> To: David M. Brean
> Cc: openib-general at openib.org
> Subject: Re: [openib-general] IB Address Translation service
> 
> On Sat, 2005-03-05 at 10:22, David M. Brean wrote:
> > There is an I-D for DHCP on IB.  IPoIB defines a "broadcast" address
and
> > DHCP (and ARP) on IB use it.  Could make RARP work using this
mechanism,
> > but as someone else pointed out, the IB hardware address contains a
> > QPN.  The I-D for IPoIB says something like:
> >
> >     The link-layer address for IPoIB includes the QPN which might
not be
> >     constant across reboots or even across network interface resets.
> >     Cached QPN entries, such as in static ARP entries or in RARP
servers
> >     will only work if the implementation(s) using these options
ensure
> >     that the QPN associated with an interface is invariant across
> >     reboots/network resets.
> 
> That may be the requirement but I think there are some issues with
> keeping the QPN invariant. Quoting Dror Goldenberg
>
(http://openib.org/pipermail/openib-general/2004-November/006765.html):
> "Assigning specific QPN for ipoib requires allocation of QPN space
which
> is beyond IB spec verbs. Current verbs do not allow it. I don't have
any
> objection for that, except that you have to hold a set of preallocated
> QPs with specific numbers and hand them over to privileged consumer
when
> requested to.  I wouldn't commit that it will work on any HCA
> architecture."
> 
> -- Hal
> 

Just to add to Hal and Dave, it is not only that the QPN may not be
constant, you can actually have few valid QPNs, one or more per
partition, since each partition reflects the notion of an IP
VLAN/Network the RARP should return different IP per partition, and the
RARP caller should use different QPN in each case.

I believe all the emails in this thread clarify why RARP is not a valid
approach

Yaron