<html>
<body>
<font size=3>At 06:38 AM 9/30/2005, Caitlin Bestler wrote:<br>
<blockquote type=cite class=cite cite=""> <br><br>
> -----Original Message-----<br>
> From: openib-general-bounces@openib.org <br>
>
[<a href="mailto:openib-general-bounces@openib.org" eudora="autourl">
mailto:openib-general-bounces@openib.org</a>] On Behalf Of Roland
Dreier<br>
> Sent: Thursday, September 29, 2005 6:50 PM<br>
> To: Sean Hefty<br>
> Cc: Openib<br>
> Subject: Re: [openib-general] [RFC] IB address translation using
ARP<br>
> <br>
> Sean> Can you explain how RDMA works in
this case? This is simply<br>
> Sean> performing IP routing, and not IB
routing, correct? Are you<br>
> Sean> referring to a protocol running on
top of IP or IB directly?<br>
> Sean> Is the router establishing a second
reliable connection on<br>
> Sean> the backend? Does it simply
translate headers as packets<br>
> Sean> pass through in this case?<br>
> <br>
> I think the usage model is the following: you have some magic <br>
> device that has an IB port on one side and "something
else" <br>
> on the other side. Think of something like a gateway that
<br>
> talks SDP on the IB side and TCP/IP on the other side.<br>
> <br>
> You configure your IPoIB routing so that this magic device is <br>
> the next hop for talking to hosts on the IP network on the other
side.<br>
> <br>
> Now someone tries to make an SDP connection to an IP address <br>
> on the other side of the magic device. Routing tables + ARP
<br>
> give it the GID of the IB port of this magic device. It <br>
> connects to the magic device and run SDP to talk to the magic <br>
> device, and the magic device magically splices this into a <br>
> TCP connection to the real destination.<br>
> <br>
> Or the same idea for an NFS/RDMA <-> NFS/UDP gateway,
etc.<br>
> <br><br>
Those examples are all basically application level gateways.<br>
As such they would have no transport or connection setup<br>
implications. The application level gateway simply offers<br>
a service on network X that it fulfills on network Y. But<br>
as far as network X is concerned the gateway IS the
server.</font></blockquote><br>
It must be viewed as such. The cross over point between the two
domains represents independent management domains, trust domains,
reliable delivery domains, etc. <br><br>
<blockquote type=cite class=cite cite=""><font size=3>I do not believe it
is possible to construct a transport<br>
layer gateway that bridges RDMA between IB and iWARP while<br>
appearing to be a normal RDMA endpoint on both networks.<br>
Higher level gateways will be possible for many<br>
applications, but I don't see how that relates to<br>
connection establishment. That would require having<br>
an end-to-end reliable connection, complete with flow<br>
control semantics, that bridged the two networks by<br>
some method other than encapsulation or tunneling.</blockquote><br>
We took steps to insure that both IB and iWARP could transmit packets in
the main data path very efficiently between the two interconnects but it
was never envisioned that a connection was truly end-to-end transparent
across the gateway component. I think most of the architects would
not support such an effort to define such a beast. There are many
issues in attempting such an offering. Just examine all of the
problems with the existing iSCSI to FC solutions; they ignore a number of
customer issues and hence have been relegated in many customer minds as
TTM, play toys not ready for prime time. This is one of the many
reasons why iSCSI has not taken off as the hype portrayed.<br><br>
It would be best to define a CM architecture that enabled communication
between like endpoints and avoid the gateway dilemma. Let the gateway
provider work out such issues as there are many requirements already on
each side of these interconnects.<br><br>
Mike<br>
</font></body>
</html>