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.
Eventually an application that uses or pretends to use a port number must deal with the fact that another application may want to use that same number. For applications that are transport neutral, this is a problem. For applications that aren't transport neutral, they can use the native addressing for their specific transport.
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? - Sean _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
