Subject: Re: FE model open issues

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 5 Nov 2003 14:54:42 -0500

If I have read this right, there are LFBs that will work this
way.  However, I am not sure.  Let me rephrase.

1) At any time (ncluding startup) an FE has an LFB topology that is
actually instantiated.  For some FEs this will be initially empty, for
others it will be initially populated and always the same.  This is not
capability information, this the actual LFB topology.

2) Some FEs (particularly software / NPU based FEs, but also some hardware
ones) have deployable components.  That is, data paths may be adjusted to
cause different elements to receive different packets.  (Some folks will
think of this as the configured equivalent of meta-data based steering.)
2') For FEs with deployable components, there should be capability
infromation indicating what LFBs the FE supports, and something about how
they can be interconnected.

What you describe is a static LFB topology with service based steering
among the paths (either by metadata or by classification.  This will
commonly happen (After all, not all packets receive the same service.)

But there are other things that happen.  During operation, the service
owner decides to start offering a new service.  If the FE supports
conbfigurable LFBs, this may involve creating / instantiating / enabling
new LFBs, and connecting such LFBs to existing LFBs.  The owner may also
decide to stop offering a service, and may cancel use of certain
LFBs.  Both of these might involve only changing classifiers (in static
FEs) or instructing the FE to create a whole new LFB, or ...

Yours,
Joel M. Halpern

At 11:45 AM 11/5/2003 -0800, you wrote:
>Hi Joel
>
>Let me try to explain what I am thinking here and let me know if you
>agree.
>
>An FE initially reports its LFB topology to the CE. This is the
>capability
>graph which includes all the possible LFBs and paths connecting the LFBs
>
>that an FE can handle (acc to its implementation). Now this topology
>might
>express multiple services that a FE implements. For example,
>
>Say this is the FE Capability graph (LFB topology) which is reported
>during capability discovery.
>
>     |--|
>     |  |-->|B|-->|C|-->|D|--|
>--->|A |                    |--->|H|-->
>     |  |-->|E|-->|F|-->|G|--|
>     |--|
>
>Now, paths A->B->C->D->H might perform Service 1 and paths A->E->F->G->H
>might perform Service 2. Now at runtime you need the ability to direct
>packets
>or flows through either of these different paths in the FE. You can do
>this
>by using the encoded state approach in which you will define a metadata
>like
>the "NextLFBID" which will specify what is the next block or LFB.
>For example, when you configure LFB A in the figure above, you will
>specify
>in its configuration information what should be the NextLFBID (B or E).
>
>If you use this approach, then you do not need to reconfigure the LFB
>topology
>at runtime, you just use a type of generic metadata "NextLFBID" to
>dynamically
>change the paths. The only time that you will need to change any LFB
>topology
>at runtime will be if you are dynamically downloading code on the FE for
>an
>LFB which is currently out of the scope of ForCES and also there are no
>commercially shipping products which support this.
>
>Does that make sense ? Hope this helps,
>
>Thanks
>Hormuzd
>P.s. BTW, this is also the current thinking in the NPF as regards
>topology.
>
>-----Original Message-----
>From: Forwarding and Control Element Separation
>[mailto:[email-masked]] On Behalf Of Joel M. Halpern
>Sent: Wednesday, November 05, 2003 9:28 AM
>To: [email-masked]
>Subject: Re: [FORCES] FE model open issues
>
>
>There will certainly be FEs whose internal LFB topoloogy is static or
>nearly static.  There will be FEs whose only "adjustability" is in the
>metadata.  There will also be FEs where LFBs can be selected to be used
>in
>different data paths, and services created in a more dynamic fashion.
>The
>most capable FEs will have an extremely flexible topology where most any
>LFB can occur anywhere.
>
>One could argue that for the first release we should support only static
>topology.  Based on experience, I feel that is too limiting.  Hence, I
>would like to see the protocol include  mechanisms for "creating" LFBs
>and
>connecting them to other LFBs in the FE.   This is not primarily to
>support
>the blank sheet model (although that will happen to be supportable) but
>to
>support the large range of FEs with some adjustability in the LFB
>topology.
>
>The consequence of course is that the CE must be prepared to have its
>attempt to adjust the topology fail, since most FEs will have limits on
>their adjustability.  This is largely inevitable.  If a CE is trying to
>install a service, the FE might not be able to deliver it  (the
>capabilities information is about helping the CE have information to
>judge
>whether and how to configure the service on a given FE.)  Related to
>this,
>as we say in the documents, some of the mapping requires human
>intelligence
>and will not work without a person in the loop.
>
>Joel
>
>At 09:12 AM 11/5/2003 -0800, you wrote:
> >Subject: Re: FE model open issues
> >To: [email-masked]
> >
> >In the model draft it states:
> >"LFB topology reconfiguration is considered an important aspect of the
> >FE model." It seems like one of the questions that has not been
>resolved
> >by the working group is how much dynamic reconfigurability is required.
> >A number of possibilities have been proposed in various drafts, ranging
> >from the ability to completely reconfigure an FE - changing the service
> >by adding/deleting LFBs to supporting only a limited amount of
> >reconfigurability.
> >
> >The ability for the CE to treat the FE as a blank sheet of paper and
> >download LFBs and their associated topology seems unnecessary. If the
> >goal is for ForCES to define a protocol to allow CEs and FEs from
> >different vendors to interoperate, this seems to be out of scope for
>the
> >ForCES WG. I assume that FEs would have capabilities built in that the
> >CEs could query, and customize the LFB behavior at runtime (the degree
> >is dependent on the capability of the FE), but not to add new
> >functionality by downloading LFB code.
> >
> >I'd also argue that dynamically reconfiguring LFB topology does not
> >require the ability to add or delete paths, assuming the approach of
> >using a combination of encoded state and a topological graph approach
>is
> >used to model the LFB topology. Functionality such as redirecting
> >traffic flows dynamically can be handled by changing the encoded state,
> >the topology graph itself is static.
> >
> >Regards,
> >Ellen Deleganes

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 5 Nov 2003 16:51:58 -0500

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.)

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.

Yours,
Joel

At 12:25 PM 11/5/2003 -0800, you wrote:
>Thanks for the clarification. My comments below...
>
>Sent: Wednesday, November 05, 2003 11:55 AM
>[HK] I believe that during the capability discovery phase of the ForCES
>protocol (post-association), the FE will report the LFB graph of all
>possible LFBs and all possible connections. This will basically
>represent
>any constraints on the connections between LFBs.
>
>[HK] Agree, same as my point above.
>
>[HK] I guess my question is what do you mean by creating or
>instantiating
>LFBs ? If you mean downloading code onto FEs for new LFBs then this is
>out of the current scope of ForCES is my understanding. If you mean
>activating certain paths between LFBs that we not used during the
>previous
>operational state, then you could do that at runtime using the NextLFBID
>metadata. This in turn is conceptually changing the Operational LFB
>topology,
>so I agree in that sense it is a topology change.
>However, it is not changing the Topology (constraint) graph which was
>reported during capability discovery.
>
>Yours,
>Joel M. Halpern

---

From: "Yang, Lily L" <[email-masked]>
Date: Mon, 10 Nov 2003 14:35:52 -0800

I think secure code downloading may be desirable in many circumstances
beyond ForCES, but I would consider that a very different problem and
should be addressed outside of ForCES. I know CAPWAP (Control and
Provisioning of Wireless APsP) BOF also wanted to support this as part
of the control/provisioning protocol for APs but IESG is asking to
remove this from that particular group. I think it is a generic problem
by itself and should be addressed separately.

ForCES should be able to co-exist with such mechanism but should not get
into the business of standardizing a general mechanism for secure code
loading.

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Khosravi, Hormuzd M
Sent: Monday, November 10, 2003 1:52 PM
To: [email-masked]
Subject: Re: FE model open issues

Hi Avri

My reason for saying this is based on the feedback we received from the
IESG on the Requirements draft that explicitly asked us to clarify this.
If you see section 6.5, point#8 we added an explicit sentence to clarify
this before the Requirements was approved by the IESG. The Applicability
Statement authors had also asked me for the same clarification a long
time back. You have raised a valid question, however on this topic I do
believe that we will have to consider a lot of factors that have not
been considered so far, security just being one. And although the
charter may not preclude this, it does not include it either and I think
we will need a charter change if we are going to get into active
networking.

My 2 cents
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Avri Doria
Sent: Monday, November 10, 2003 8:16 AM
To: [email-masked]
Subject: Re: [FORCES] FE model open issues

On onsdag, nov 5, 2003, at 14:25 US/Central, Khosravi, Hormuzd M wrote:

> If you mean downloading code onto FEs for new LFBs then this is
> out of the current scope of ForCES is my understanding.

I have seen this statement several times, but other then the assertion,
don't understand why it is out of scope.  There is nothing in the
charter that prohibits as far as I can tell.  I also don't see the
architecture are precluding it.

It seems to me an important capability to include even if current HW
designs cannot, currently, take advantage of a full dynamic capability.

It concerns me that at ever step of the decision process we seem t
limit the capability and the dynamicity of the architecture and of the
models.

a.