[openib-general] Re: [swg] Re: private data...

[Fab Tillier]

> From: Sean Hefty [mailto:mshefty at ichips.intel.com]
> Sent: Thursday, October 20, 2005 12:11 PM
> 
> Fab Tillier wrote:
> > That's not to say you couldn't have one range of service IDs for TCP
> > applications, and another range for DAPL applications, and yet another
> > range per protocol or application that wishes to use IP addressing
> > during connection establishment.  However, this doesn't extend the
> > CM protocol, but just creates an ad-hoc group of protocols that happen
> > to define the first 32-bytes of their private data similarly.
> 
> If applications map their "port" numbers to different service IDs, then
> there's no need to define the private data at all.  The CM can perform
> its job without changes and route based purely on service IDs.  The only
> reason to use a reserve bit or change the version is if the CM needs to
> look into the private data.
> 
> The definition of private data is an issue for an upper level connection
> manager.  My hope is that this can be defined such that the upper level
> connection manager can support multiple transports, so I don't have to
> build an upper level upper level connection manager.

My understanding was that we want the IBTA to add a section in the IB spec to
define this higher-level connection management protocol, specifically the use of
the first 32-bytes of the private data in the REQ to contain the source and
destination IP addresses associated with the source and destination GIDs in the
primary and alternate paths.

If that's not the case, then why is the IBTA SW working group involved here?
Why do they care?

If my understanding is correct, the bit would have meaning to this higher-level
connection management protocol, and not to the lower level IB connection
management protocol.  Defining a range of service IDs for protocols that use
this feature creates a bound group that then requires a rev of the spec anytime
someone else wants in on the fun.  I think defining the higher level protocol
without restricting the scope of service IDs would be beneficial.

> > Having a bit in the CM REQ indicate whether the first 32-bytes of
> > private data contain the source and destination IP addresses allows
> > any app using any service ID to use IP addresses as source and
> > destination identifiers regardless of what protocol they actually
> > use once the connection is established.
> 
> What does the CM do with this bit?

The IB CM does nothing.  A higher-level, IP addressing aware CM protocol defined
by the IBTA would.  If a connection request comes in on a particular SID handled
by the higher level CM and doesn't have the bit set, then the request should be
rejected as malformed.  If the bit is set, the higher level CM could check that
the source and destination IP addresses provided match the GIDs specified in the
primary and alternate paths.

- Fab