[openib-general] IPoIB Loading and Starting
Hal Rosenstock
halr at voltaire.com
Wed Sep 29 03:11:31 PDT 2004
On Tue, 2004-09-28 at 11:38, Roland Dreier wrote:
> Hal> At IBA 1.2, C15-0.1.22 is obsolete and has been replaced by
> Hal> C15-0.2.1. C15-0.2.1: When a requester node sends a trusted
> Hal> request to SA, the requested data shall be returned. When a
> Hal> requester node sends a non-trusted request for data to SA
> Hal> that would provide information about a subject node, the SA
> Hal> shall return only data providing information about subject
> Hal> nodes for which the requester shares a P_Key, with exceptions
> Hal> noted below in C15-0.1.23.
>
> Hmm, this seems like the only difference from C15-0.1.22 is that it
> talks about trusted requests. C15-0.1.23 (below) still says that
> MCMemberRecords don't provide information about any subject nodes, so
> I guess the SM should not worry about P_Keys when returning the table
> of multicast groups.
You are correct about the IBA 1.1/1.2 compliance difference (and the
trusted request part is not relevant to this discussion).
C15-0.1.22 does, however, talk about PKey sharing which is relevant to
this (and consistent with 15.4.1 below).
The intent is that the SA only return information relative to the
partitions that the port was part of. The below is from IBA 1.1 (and 1.2
as well):
15.4.1 Restrictions on Access
There are two types of access restrictions involved in SA:
Authenticating the requester of information, and restricting the data
that the requester is allowed to receive. These are discussed below. The
SA access restrictions described here are based on partition membership,
and are intended to implement this rule: If access to data is allowed by
partition membership, that access is granted; but if it is disallowed,
the requester should remain unaware of the existence of that information
and of the network elements containing that information. Additionally,
in no event is authentication information made available to untrusted
requests. That a node s PortInfo:M_Key and PortInfo:M_KeyProtectBits may
prohibit access to some data by SMPs without a valid M_Key has no
bearing on SA access restrictions.
> Roland> C15-0.1.23: [...] MCMemberRecords shall always be provided
> Roland> with the PortGID, Join- State and ProxyJoin components set
> Roland> to 0, except for the case of a trusted request, in which
> Roland> case the actual component contents shall be provided.
You omitted the following:
C15-0.1.23: Subnet Administration shall follow the following additional
rules concerning data access:
Perhaps it is the language which is confusing and somewhat
contradictory:
C15-0-1.22 (IBA 1.1) and C15-0.2.1 (IBA 1.2) state "Subnet Administrator
shall return only data providing information about subject nodes for
which the requester shares a P_Key, with exceptions noted below in
C15-0.1.23:."
whereas:
C15-0.1.23 states "Subnet Administration shall follow the following
additional rules concerning data access" and one of those rules concerns
MCMemberRecord.
My interpretation is that the Pkey sharing is the first level rule
before the following is applied from C15-0.1.23:
"MCMemberRecords shall always be provided with the PortGID, Join- State
and ProxyJoin components set to 0, except for the case of a trusted
request, in which case the actual component contents shall be provided."
which is what you are citing to say you get all the multicast records.
-- Hal
More information about the general
mailing list