At 07:22 AM 3/21/2007, Hal Rosenstock wrote:
The SM is subnet local but it is unclear about the SA.
The SA was intended to be subnet local. What is above the SM / SA were
left to implementation discretion but these two were intended to be
strictly subnet local.
Currently, if one knows the GID of the SA, it can be contacted remotely.
One can communicate with anything that has a GID. While it is true that
does not make it the right choice.
To support routing, there are a number of things that SA supports that I
think will
need to be exchanged across SAs so in this sense it may not be that far
off in that it separates this aspect which can evolve to wherever it
ends up in the architecture.
The only thing one needs to comprehend are the <GID, P_Key, Q_Key> of the
destination. Ideally, one would create the equivalent of a DNS service
agent that would operate in each subnet and provide a local look up for any
endnode requesting a remote's information. The subnet local router would
provide information into the SM / SA to enable endnode's to comprehend
which router port to target their LRH structure. The router would strip
the LRH and add a new one to the next hop - whether another router or the
destination port. This gets you going without a lot of complexity.
Now, if you want to add in QoS attributes to the path discovery, then there
are two areas to explore:
- Subnet local QoS to the subnet local router port.
- Router protocol provided QoS information between routers.
The first just uses the existing infrastructure. The second would be new
and part of the router protocol to populate the SM/SA. If one associated
a given GID prefix with one or more QoS attributes, then the source can
make intelligent decisions without requiring any remote SA involvement.
It is a temporary measure to get by with the lack of specificity in the
routing space. As you can see, there is an immediate need within
OpenFabrics to resolve these issues or at least take an experimental stab
at them so more IB router protoyping can be done.
Caution is recommended. If the IBTA can get its act together on the
basics in a reasonable amount of time then the legacy problem can be
avoided entirely. If not, well, customers have to make choice points, test
matrix get larger, etc. Waiting until Sonoma isn't going to kill anyone
and may provide better insight into what should be specified in the interim
between now and the IBTA getting its act together.
Mike
-- Hal
> > I agree with you that this is not a good place to be, but with current
> > hardware I think we are stuck with it..
>
> I do not think so (with my ib hw asic vendor hat on).
>
> >
> > Regards,
> > Jason
> > _______________________________________________
> > general mailing list
> > [email protected]
> > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> >
> > To unsubscribe, please visit
> http://openib.org/mailman/listinfo/openib-
> > general
> _______________________________________________
> general mailing list
> [email protected]
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>
> To unsubscribe, please visit
http://openib.org/mailman/listinfo/openib-general
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit
http://openib.org/mailman/listinfo/openib-general
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
