> From: Sean Hefty [mailto:[EMAIL PROTECTED] > 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 _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general