Subject: Re: FE model open issues

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 5 Nov 2003 16:00:42 -0800

Hi Joel

My comments below...

Thanks
Hormuzd
-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, November 05, 2003 1:52 PM
To: [email-masked]
Subject: Re: [FORCES] FE model open issues

A few further comments.

If by "all possible LFBs and all possible connections" you mean the kind
of
thing in the diffserv MIB (list of supported types and supported
connections) then we are in agreement.  However, the phrase "the graph
of
all possible LFBs and all possible connections" conures up anb image of
a
series on graphs, one for every possible topology.  I doubt you meant
that,
but I wanted to check.  (To phrase this another way, the capabilities
are a
set of constraints on the possible LFB graphs.  The capabilities are not
themselves a graph.)

[HK] Yes, I think this is where there is a subtle difference. I see the
Capabilities as being a graph of LFBs based on the possible constraints,
which are currently already instantiated on the FE.
I thought that is what was exchanged during the post-association phase.
I had in mind some capability exchange during pre-association which
might
be along the lines of what your suggesting or even more high level than
that.
(For e.g., an FE might say that it can do IPv4 fwd & DiffServ QoS)
During post-association, I assume that an FE will already have LFB
instantiated
and their instance IDs will be reported as part of the capability graph.
Now the CE can configure whatever LFB instances it wants, to perform the
particular services without having to change the capability graph(s).

By "creating" an LFB I mean causing the FE to instantiate an LFB that it
supports.  This could be a table entry for a subrouting (for a pure
software LFB).  This could be enabling and connecting up another block
of
FPGA for traditional FPGAs.  It might be loading an FPGA block with one
of
a (predefined on the FE) set of definitions so as to enable a kind of
LFB,
if one has the types of FPGAs that have been in the news lately.  I do
not
envision the CE providing the code for the LFB, and I do not believe
anyone
has asked for ForCES to support teh creation of new kinds of LFBs on an
FE
(as distinct from new instances of already supported kinds).  One could
imaging a protocol extension to support that, but I do not consider that
to
be within scope.

[HK] So we are on the same page here. FE instantiates LFBs, FE assigns
the instance IDs to LFBs, so LFB IDs are unique on a per FE basis.
FE reports the LFB instance IDs to CE, the CE does not instantiate LFBs.
Now the CE can may be enable, disable LFBs, but what does that really
mean at runtime or post-association ? Isnt this something which will
happen
during pre-association or when the FE is down and not in service ?

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 5 Nov 2003 20:00:34 -0800

> FE reports the LFB instance IDs to CE, the CE does not instantiate LFBs.

The request for a policy comes from the CE. That request results in
instantiation out of a LFB class at the FE.
The CE could request for a specific LFB instance id to be instatianted
on an FE. I would think if no specific instance ID is requested then
the FE would allocate say the next available index.

> during pre-association or when the FE is down and not in service ?

I think you may be thinking too hard on fixed feature LFBs i.e
FEs which can only connect LFBs in a certain topology and can never
have new LFBs "created".
If you think more general, then factor in ability to express that an LFB
instance that can connect to any other LFB instance; some of these graphs
may not make sense. Intelligence of what topology doesnt make sense
resides on the CE. i.e if you create a nonsensical service its
your fault.

cheers,
jamal