Hal, Within the SWG there were discussions on this topic a while back. Folks came up with various suggestions. However, at the time, we did not choose to mandate a particular way for the CM to track possible changes to the CM path. So officially, the spec is silent here.
As you may be hinting, when the CM is using a path that is the same as the data path, it might be okay to also use the alt path info. But that assumes of course that the new data path is also suitable for mgt traffic (which might not be true, e.g. it may not be reversible path). The most general procedure is probably to initiate new SA queries whenever a new CM path is needed. Since the Remote CA GUID is recorded, that can be used to locate the NodeRecord. The RID of the NodeRecord will contain a LID, which can be fed to a PathRecord query (with Reversible flag on). -ted >OpenIB is in the midst of implementing the CM and the following question >about the CM has come up on openib-general mailing list and no one has >yet supplied an answer so I thought I'd go to the source. I am cross >posting although members of openib-general won't necessarily be able to >respond directly to any response. > >It appears that there is the possibility of a CM path and one or more >data paths (primary/alternate) per connection. The CM path may or may >not be the same as the data path(s). > >Assume that a connection with both a primary and secondary path is >setup, using the same primary path for CM communication. Some time later >the primary path fails, so APM causes the connection to migrate to >the secondary path. A "path migrated" async event is issued in the end >node which results in the desire to set up a new secondary path so that >the connection remains resilent. Where does the LAP get sent ? >Similarly for any other future CM messages (like DREQ, etc.). It seems >to need to get sent along the new path. > >How is the CM path expected to be maintained in the two cases (when it >is the same and when is different from a data path) in the presence of a >path failure ? Maybe those are the same case in terms of the >architecture. Ted H. Kim Sun Microsystems, Inc. [EMAIL PROTECTED] 222 North Sepulveda Blvd., 10th Floor (310) 341-1116 El Segundo, CA 90245 (310) 341-1120 FAX _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
