<html>
<body>
<font size=3>At 09:23 AM 9/27/2004, Roland Dreier wrote:<br>
<blockquote type=cite class=cite cite=""> Michael>
The SM only knows what it configures in each port. The<br>
Michael> SA is responsible for service management
and it works<br>
Michael> with the SM to map a given service to a
P_Key.<br><br>
As far as I know there is no service (in the IB service record
sense)<br>
associated to IPoIB, is there?</blockquote><br>
Additional services can be defined beyond the base IB service
record. For IP, the following would solve the problem:<br><br>
- 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.<br><br>
- 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.<br><br>
- For each P_Key, the endnode probes for the "all nodes"
multicast address and joins / creates accordingly. <br><br>
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. <br><br>
The above approach is both scalable and relatively simple to implement
and manage.<br><br>
<br>
<blockquote type=cite class=cite cite=""> Michael>
IPoverIB is required to inquire what groups are available<br>
Michael> and optionally set up event notification
to be informed<br>
Michael> when groups are added for its particular
service. This<br>
Michael> eliminates the need for local P_Key
management.<br><br>
I don't see this requirement anywhere in the current IETF drafts,<br>
although I could be missing it. In any case this seems rather
ugly,<br>
since the only way to get a list of IPoIB multicast groups seems to
be<br>
to query for _all_ multicast groups, filter for those that match
the<br>
IPoIB GID format, and then attempt to join to find out which can be<br>
used on each local port.<br><br>
Michael> In general, the IPoverIB driver should
treat each new<br>
Michael> all-nodes multicast group with a unique
P_Key as a<br>
Michael> virtual hot-plug event (this was our
intent both within<br>
Michael> the IETF and in the IBTA).<br><br>
Hmm.. this view does not seem to match the wording of the current IPoIB
drafts. For example:<br><br>
It is an implementation choice
on how the P_Key and the scope<br>
bits related to the IPoIB
subnet are determined by the<br>
implementation. These could be
configuration parameters<br>
initialized by some means by
the administrator.<br><br>
The methods employed by an
implementation to determine the<br>
P_Key and scope bits are not
specified by IPoIB.</blockquote><br>
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.<br><br>
Mike</font></body>
</html>