[openib-general] IB Address Translation service

[Kanevsky, Arkady]

Some historical perspective - ATS was defined prior to IPoIB.

The requirements.
DAT has two needs:
1. forward translation: given an IP address returns back IB GID/LID.
2. reverse translation: given IB GID/LID returns back an IP address of
the requestor.

ULPs: NFS, DAFS.

SDP encoded IP addresses into its headers.
But DAT is API and cannot define a protocol for it.

Abstract address translation is a good idea.
For IB we can use ATS or IPoIB.
For iWARP it will be no-op.
We must ensure that the DAPL that we submit to Linux can be layered on
top of all RDMA transports.

Since IPoIB had not had plugfest/connectathon or some other interop that
demonstrate ARP and RARP
I suggest we have both ATS and IPoIB support.
ATS has been fully successfully tested at DAPL Plugfest.

In DAPL we had not assessed the HA requirements implications on address
translations
which is currently under discussion.

Arkady Kanevsky                       email: arkady at netapp.com
Network Appliance                     phone: 781-768-5395
375 Totten Pond Rd.                  Fax: 781-895-1195
Waltham, MA 02451-2010          central phone: 781-768-5300
 


> -----Original Message-----
> From: Tom Duffy [mailto:tduffy at sun.com] 
> Sent: Tuesday, March 01, 2005 6:02 PM
> To: Yaron Haviv
> Cc: openib-general at openib.org
> Subject: RE: [openib-general] IB Address Translation service
> 
> 
> [ putting back on list ]
> 
> On Wed, 2005-03-02 at 00:29 +0200, Yaron Haviv wrote:
> > Did you try RARP with IPoIB ?
> 
> I have not.
> 
> > I thought that there is some issue that it doesn't work
> 
> Currently, the rarpd only works with ethernet, but I don't 
> see why this couldn't be fixed.
> 
> > Also I hope you can comment on the other ib_at capabilities 
> which are 
> > more important than ATS
> 
> I don't mind the idea of abstracting out address translation. 
>  I think maybe this is a premature optimization and we should 
> see how each ULP uses/does it first, then abstract out common 
> code.  Otherwise, I feel neither strongly for or against your 
> proposal.
> 
> -tduffy
>