Michael> The SM only knows what it configures in each port. The
Michael> SA is responsible for service management and it works
Michael> with the SM to map a given service to a P_Key.
As far as I know there is no service (in the IB service record sense)
associated to IPoIB, is there?
Additional services can be defined beyond the base IB service record. For IP, the following would solve the problem:
- Have the SA define an IP service (this can be done for other protocols as well). This can be done using the Service ID annex specification (much of this annex is focused on an endnode but for this purpose, the SA can be viewed as a logical endnode). The SA registers the service providing a single point of management for the subnet.
- Each endnode issues request targeting the IP service identifier for each P_Key that is configured in the port. The SA response determines whether the IP service is supported on this interface.
- For each P_Key, the endnode probes for the "all nodes" multicast address and joins / creates accordingly.
Given P_Key can come and go, the endnode can set up an event notification when the IP service is updated. This allows dynamic configuration without having an administrator interact with each node.
The above approach is both scalable and relatively simple to implement and manage.
Michael> IPoverIB is required to inquire what groups are available
Michael> and optionally set up event notification to be informed
Michael> when groups are added for its particular service. This
Michael> eliminates the need for local P_Key management.
I don't see this requirement anywhere in the current IETF drafts,
although I could be missing it. In any case this seems rather ugly,
since the only way to get a list of IPoIB multicast groups seems to be
to query for _all_ multicast groups, filter for those that match the
IPoIB GID format, and then attempt to join to find out which can be
used on each local port.
Michael> In general, the IPoverIB driver should treat each new
Michael> all-nodes multicast group with a unique P_Key as a
Michael> virtual hot-plug event (this was our intent both within
Michael> the IETF and in the IBTA).
Hmm.. this view does not seem to match the wording of the current IPoIB drafts. For example:
It is an implementation choice on how the P_Key and the scope
bits related to the IPoIB subnet are determined by the
implementation. These could be configuration parameters
initialized by some means by the administrator.
The methods employed by an implementation to determine the
P_Key and scope bits are not specified by IPoIB.
It was not specified due to the lack of standards for higher-level service management which partitioning is classified. Given there is an OpenSM effort in flight and the Service ID spec is already in existence, it isn't that tough to acquire an IP service ID (or any other protocol that one wants to support) and implement a solution along the lines that I describe above. This would lead to a more dynamic environment while reducing the impact to the administrator.
Mike
_______________________________________________ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
