[dat-discussions] RE: [openib-general] Re: iWARP emulationprotocol

[Kanevsky, Arkady]

with both SRC and DST IP addresses and TCP ports all these models will
be supported.

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: Caitlin Bestler [mailto:caitlinb at broadcom.com] 
> Sent: Thursday, October 20, 2005 12:26 PM
> To: Sean Hefty; Kanevsky, Arkady
> Cc: swg at infinibandta.org; openib-general at openib.org; Lentini, 
> James; Davis, Arlin R
> Subject: RE: [dat-discussions] RE: [openib-general] Re: iWARP 
> emulationprotocol
> 
> 
>  
> 
> > -----Original Message-----
> > From: openib-general-bounces at openib.org
> > [mailto:openib-general-bounces at openib.org] On Behalf Of Sean Hefty
> > Sent: Thursday, October 20, 2005 8:51 AM
> > To: Kanevsky, Arkady
> > Cc: swg at infinibandta.org; openib-general at openib.org; Lentini, 
> > James; Davis, Arlin R
> > Subject: Re: [dat-discussions] RE: [openib-general] Re: iWARP 
> > emulationprotocol
> > 
> > Kanevsky, Arkady wrote:
> > > I will update the proposal for IBTA based on this feedback and all
> > > other feedback posted.
> > > I will still separate private data usage proposal and 
> port mapping 
> > > one.
> > 
> > Again, I think that these should be in the same proposal.
> > The CM REQ carries the IB transport layer address.  The goal 
> > here is to map another transport layer address to the IB one. 
> >  The source port is included in the private data.  By not 
> > including the destination port, there's an assumption that 
> > it's provided somewhere else in the CM REQ.  We should either 
> > make this explicit, or put the destination port in the 
> > private data as well.
> > 
> 
> Under the general programming model for an IP-centric daemon, 
> the listener can assume that connection requests will be for 
> the TCP port that the listen was issued upon.
> 
> However, the daemon typically listens on *all* addresses that 
> the system supports. It is not uncommon for the application 
> to note which destination address was actually requested and 
> to vary the service provided based upon that. This is what 
> makes it possible for single machines to host vast numbers of 
> web sites.
> 
> It is less common, but still requiring support, for the 
> daemon to differentiate service based upon the source 
> address. It is more common to simply refuse service based 
> upon the source 
> address, which can be handled by the CM or firewall itself 
> rather than by the application, but there are exceptions. 
> Some web-sites have intranet versus internet verions. Some 
> file servers control access lists based upon source address. 
> It is actually quite effective when combined with network 
> authentication of source addresses.
>