Subject: Re: FE model open issues

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 5 Nov 2003 11:45:03 -0800

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: Weiming Wang <[email-masked]>
Date: Thu, 6 Nov 2003 13:17:35 +0800

Hi Hormuzd,

My understanding of encoded state approach is only a way to represent the datapaths
instead of the topology. That is, the metadata in it is only read by followed LFBs instead 
of by others. If the information like "NextLFBID" is allowed in the metadata, it may imply
there is a switch fabric between the LFBs that reads the info so as to switch to the desired LFB 
(based on per packet speed). I think the "NextLFBID" info can be told to the LFB, but not in metadata 
mode. When we tell the LFB on this, we actually do the topology configuration, which is quite 
identical to what PkfIDs do. 

Regards,
Weiming

----- Original Message ----- 
From: "Khosravi, Hormuzd M" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, November 06, 2003 3:45 AM
Subject: Re: FE model open issues

Hi Joel

    |--|
    |  |-->|B|-->|C|-->|D|--|
--->|A |                    |--->|H|-->
    |  |-->|E|-->|F|-->|G|--|
    |--|

Thanks
Hormuzd

-----Original Message-----

Joel

resolved
the
is