Subject: Re: model draft comments

From: Alex Audu <[email-masked]>
Date: Thu, 9 Jan 2003 17:21:26 -0500

Hi Alan,

  The information conveyed by the "graph" is pretty important for it
  determines the beahvior
  of the FE in relation to the overall NE. I am assuming the "graph" in
  this sense represents
  the relative placements (or location in the data path) of the resources
  in the FE. Making such
  placements configurable (by CE or otherwise) will allow bahvioral
  modifcation or programmability
  of the NE. This is a good thing.  The extent of that programmabiility
  however depends on advances
  in chip technology of which FEs are made. But logically, this shouldn't
  be too difficult to do.

  It will probably be useful to come up with a set of graphs of those
  resources, and then provide
  a documented mapping between each graph and the corresponding FE
  behavior. rfc 3290 is a
  useful starting point towards this goal.

  To answer your questions:
  1. How do we represent the graph?
    We can possibly assign unique IDs to the resources or components.
  Once that is done,
    stringing then up in a sort of linked list to reflect the graph
  becomes easy.

  2. Where is that graph representation stored at boot time?
     In the case where resource graphs are preset (most restrictive),
  graphs could be stored in
     non-volatile memory of some sort. However, assuming programmability,
  the FEs will
     probably boot up with unconfigured graphs. It is up to CE to
  configure the graphs based on
     intended beahviors for the FEs. In this case, the graph will be
  stored in RAM,..which could
     then be saved off into a more persistent storage if need be.

  3. How is that information communicated to the elements which need it?
     This will be domain of the inter FE and CE protocol (e.g. FACT).

  Cheers,
  Alex.

In a message dated 1/8/2003 1:36:59 PM Eastern Standard Time, Alan DeKok <[email-masked]> writes:

>"Joel M. Halpern" wrote:
>>
>> We have a basic choice about where on the spectrum of CE / FE
>> controllability we wish to be.
>
>  My opinion is that we can avoid much of this discussion by agreeing on
>elements which are common across the spectrum, or models.
>
>  e.g. Addressing a particular component of the graph is independent of
>how the graph is represented, and who represents it.  The CE could
>simply be told "here's a collection of handles to components", and can
>often manage those components without knowing their relationships.
>
>> We could declare that the component graph is strictly under the control of
>> the FE, and the CE has no say in it.  If we say that, we will still need a
>> way for the CE to understand the graph,
>
>  I agree it would be useful for the CE to understand the graph, but I'm
>not sure it's required.  I would like to have diagrams and examples of
>the various scenarios to put the discussion on a concrete setting.
>Until then, the discussion is too vague to enable us to move forwards.
>
>> but we we will be restricted in the
>> services a CE can enable by the graph that actually exists on the FE.
>> We could declare that the CE must be able to change the component graph in
>> any way it wants to.  This would allow any service in principle.  In
>> practice, this would be impossible, as no FE will allow every possible
>> configuration of any possible number of graph elements.
>
>  And the connections between the graph elements are often static, and
>defined by physical traces on a board.
>
>> Thus, it seems (and has seemed) to me that we need to allow the CE to
>> discover and manipulate the graph.  There are limitations on that graph
>> manipulation (and on the element manipulations) which can readily be
>> communicated (in capabilities for example) so that the CE will generally
>> know what it can and cannot do.  There will be limitations on the graph and
>> element manipulations which will not be captured in the capabilities, and
>> will result in the CE receiving errors when it attempts some service
>> establishments.
>
>  I agree.  We now have some interesting questions.
>
>1. How do we represent the graph?
>2. Where is that graph representation stored at boot time?
>3. How is that information communicated to the elements which need it?
>
>  e.g. Systems with PCI busses can do PCI queries, and have a
>well-defined way of discovering any graph topology at boot time.
>Application-layer changes aren't required.
>
>  Do we want systems supporting ForCES to have a similar discovery
>protocol?  How do we address the graph components?  How do we
>communicate component capabilities?
>
>
>  Graph topology is a difficult area to work with.  I'd like to see
>those issues seperated from the component configuration and control,
>which is where I see ForCES being applied.
>
>  Alan DeKok.
>

---

From: Alan DeKok <[email-masked]>
Date: Fri, 10 Jan 2003 10:22:08 -0500

Alex Audu wrote:
>   of the FE in relation to the overall NE.

  Sure, but the draft says it doesn't support reconfiguration or
reconnection of the graph topology.  So if it's static, then knowing the
topology is much less important than if it could change.

>   I am assuming the "graph" in
>   this sense represents
>   of the NE. This is a good thing.

  It's also extremely difficult, which is why it's currently outside of
the scope of ForCES.

>     stringing then up in a sort of linked list to reflect the graph

  I disagree *completely*.  I deal with graph topology and manipulation
every day, and it's just not that easy.  You can have 1-N, N-1, or N-M
relationships between graph elements.  You can have loops.  You can have
cross-connections.

  Linked lists are insufficient.  Naive solutions are inadequate.

  Alan DeKok.