: 781-895-1195
Waltham, MA 02451-2010 central phone: 781-768-5300
> -Original Message-
> From: Tom Tucker [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 25, 2005 5:52 PM
> To: Ted H. Kim
> Cc: [EMAIL PROTECTED]; openib-general
> Subject: Re: [swg] Re: [open
On Tue, 2005-10-25 at 13:16 -0700, Ted H. Kim wrote:
> Tom,
>
> Some comments inline ...
>
>
> Tom Tucker wrote:
> > I think it's relevant, so let's make sure my assumptions are correct:
> >
> > - The ITAPI will be a "ULP" on OpenIB
>
> ITAPI is like uDAPL, so if uDAPL is a "ULP" then the answ
> -Original Message From Ted Kim -
>
>
> I should point out that there was once a proposal of doing a
> RDDP IETF draft which would have sub-divided the MPA private
> data into a "middleware" section and an "app" section. The
> idea was to be sure that the app/ULP and middleware (e.
Tom,
Some comments inline ...
Tom Tucker wrote:
I think it's relevant, so let's make sure my assumptions are correct:
- The ITAPI will be a "ULP" on OpenIB
ITAPI is like uDAPL, so if uDAPL is a "ULP" then the answer is yes.
The point is that for uDAPL you have the actual "app" running over
Ted:
I think it's relevant, so let's make sure my assumptions are correct:
- The ITAPI will be a "ULP" on OpenIB
- The ITAPI will create the IRD/ORD headers in its private data and
submit this as part of its connection establishment.
- The ITAPI consumer at the remote peer will use this data to
Just a comment on this one point ...
Sean Hefty wrote:
I'm thinking that for iWARP, there won't be anything in the Private Data
at all except consumer private data. Is that your expectation?
I believe so. This is only trying to define a TCP/IP connection service
over IB. I'm assuming that
At 12:50 PM 10/21/2005, Fab Tillier wrote:
> From: James Lentini
[
mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 21, 2005 12:38 PM
>
> On Fri, 21 Oct 2005, Sean Hefty wrote:
>
> > > sean> version(8) | reserved(8) | src port (16)
> > version(1) | reserved(1)
| src port (2)
> > > sean> sr
On Fri, 2005-10-21 at 14:02 -0700, Sean Hefty wrote:
> Tom Tucker wrote:
> > I'm thinking that for iWARP, there won't be anything in the Private Data
> > at all except consumer private data. Is that your expectation?
>
> I believe so. This is only trying to define a TCP/IP connection service over
Caitlin> It's basically the same as with TCP and UDP. It's a 16
Caitlin> bit number, and most people do not use the same port
Caitlin> number to mean *different* things over the different IP
Caitlin> transports.
But, just to be clear, the port number spaces are disjoint. It's
poss
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Sean Hefty
> Sent: Friday, October 21, 2005 2:02 PM
> To: Tom Tucker
> Cc: [EMAIL PROTECTED]; openib-general
> Subject: Re: [openib-general] TCP/IP connection service over IB
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Steve Wise
> Sent: Friday, October 21, 2005 1:35 PM
> To: Sean Hefty
> Cc: [EMAIL PROTECTED]; openib-general@openib.org
> Subject: Re: [openib-general] TCP/IP conne
Tom Tucker wrote:
I'm thinking that for iWARP, there won't be anything in the Private Data
at all except consumer private data. Is that your expectation?
I believe so. This is only trying to define a TCP/IP connection service over
IB. I'm assuming that there's no need to define something sim
Sean:
I'm thinking that for iWARP, there won't be anything in the Private Data
at all except consumer private data. Is that your expectation?
On Fri, 2005-10-21 at 12:44 -0700, Sean Hefty wrote:
> James Lentini wrote:
> > Ok. I assume that your 1 byte of version information is broken into 2
> >
Random thought... if the src and dst IP addresses will always be on the
same network, the data could be layed out as:
network addr (x)
src host addr (y)
dst host addr (y)
This could save enough space to provide 64 bytes of user private data.
Although my preference would be to keep it simpler.
> From: James Lentini [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 21, 2005 12:38 PM
>
> On Fri, 21 Oct 2005, Sean Hefty wrote:
>
> > > sean> version(8) | reserved(8) | src port (16)
> > version(1) | reserved(1) | src port (2)
> > > sean> src ip (16)
> > > sean> dst ip (16)
> > > sean> u
James Lentini wrote:
Ok. I assume that your 1 byte of version information is broken into 2
4-bit pieces, one for the protocol version and one for the IP version.
That is correct.
What about making the src and dst ip fields variable length based on
the IP version (4 bytes for IPv4 and 16 bytes
On Fri, 21 Oct 2005, Sean Hefty wrote:
> James Lentini wrote:
> > Standardizing the protocol will ensure interroperability.
>
> Agreed - just didn't know if this was the responsibility of the SWG.
The SWG has agreed to take it on. I think it is appropriate for the
SWG to work on this.
> > s
Sean Hefty wrote:
version(8) | reserved(8) | src port (16)
src ip (16)
dst ip (16)
user private data (56)/* for version 1 */
Random thought... if the src and dst IP addresses will always be on the same
network, the data could be layed out as:
network addr (x)
src host addr (y)
dst ho
James Lentini wrote:
Standardizing the protocol will ensure interroperability.
Agreed - just didn't know if this was the responsibility of the SWG.
sean> version(8) | reserved(8) | src port (16)
version(1) | reserved(1) | src port (2)
sean> src ip (16)
sean> dst ip (16)
sean> user p
sean> At a minimum, we need an assigned service ID to identifies a
sean> TCP/IP connection service. For simplicity of the
sean> implementation, I would use an ID similar to that defined for
sean> SDP:
sean>
sean> 0x00 14 05 xx xx xx xx xx
sean>
sean> I don't know that the SWG or IBTA needs
20 matches
Mail list logo
