[ofa-general] [RFC] host stack IB-to-IB router support

[Michael Krause]

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
> > > general at lists.openfabrics.org
> > > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> > >
> > > To unsubscribe, please visit
> > http://openib.org/mailman/listinfo/openib-
> > > general
> > _______________________________________________
> > general mailing list
> > general at lists.openfabrics.org
> > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> >
> > To unsubscribe, please visit 
> http://openib.org/mailman/listinfo/openib-general
>
>_______________________________________________
>general mailing list
>general at lists.openfabrics.org
>http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>
>To unsubscribe, please visit 
>http://openib.org/mailman/listinfo/openib-general