Subject: Re: Question on scope

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 2 May 2005 10:40:22 -0400

Joes,

On Mon, 2005-02-05 at 16:07 +0200, Jose Rey wrote:

> Thanks for you answers.  Actually Joel answered. I paste the offline traffic below.
> 
> Summarising the thread below, it seems that you target at making the task of 
> policy-routing much easier and as far as possible automated (challenging!).  

It depends on what you mean by policy routing. If it is what Jpel
describes in his email as "arranging the LFB instance graph 
and classifier tables" then yes. If by routing you mean L3, then thats a small subset
of the larger picture.
Forces also is constrained within the scope of an NE. 

> This controlled entities (FEs) would include things as interesting as transcoders,
>  packet droppers and so on, thus not limited to L4 functionality.

Indeed. 
Essentially, intelligence on the CE decides what LFB building blocks to
use and then instantiates them interconnected via a graph.
The graph edges may be constrained by the limits of what the LFB block
can connect to (as discovered during capability exchange). So if the
blocks constitute of L2 processing, G711 RTP vocoding, IPSEC etc,
shouldnt matter. What matters is you can formally describe these blocks
- i should say formally describe their parametrization - using
the LFB "language" as defined by the model; if you can do that then the
protocol can configure them. Does that make sense?

cheers,
jamal

---

From: Jose Rey <[email-masked]>
Date: Mon, 2 May 2005 16:07:25 +0200

Hi Jamal,

Summarising the thread below, it seems that you target at making the task of policy-routing much easier and as far as possible automated (challenging!).  This controlled entities (FEs) would include things as interesting as transcoders, packet droppers and so on, thus not limited to L4 functionality.

Cheers,

José 

> 
> Hi Jose,
> Apologies that noone had responded to you so far.
> 
> On Fri, 2005-29-04 at 10:13 +0200, Jose Rey wrote:
> 
> > I went through the charter and over some of the drafts and I don't 
> > know yet if I get it right.  I understand that the aim is 
> to separate 
> > control and transport, that much is clear.  Additionally, some QoS 
> > functionality is implemented in the forwarding entities.  
> But, is it 
> > also planned to include more advanced functionalities like 
> transcoding, metering, intelligent packet dropping (e.g., 
> only P frames) in those FEs??
> > Related to that: the
> > charter talks about per-packet processing but does this 
> processing stop at layer 4 ?
> 
> The end goal is to provide generic enough functionality in 
> the protocol and the modeling "language" such that you should 
> be able to model and then configure any forwarding path 
> element in existence in variety of future and existing FEs.
> 
> Although some basic LFBs that are mentioned in the charter 
> will be described - they merely exist to validate that the 
> protocol and the modelling "language".  As an example, at the 
> moment i am using the LFB model to describe IPSEC FEs and 
> configuring them using Forces (it is not listed in the 
> charter but the model and protocol are sufficient for it).
> 
> Hopefully this answers your questions. If theres any 
> objection to my response to you from other people you should 
> hear from them.
> 
> cheers,
> jamal

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]] 
> Sent: Friday, April 29, 2005 3:21 PM
> To: Jose Rey
> Subject: RE: Question on scope
> 
> That is the idea.
> If you have a ForCES FE with classifiers, QoS capabilities, 
> IPSec, etc, then your CE can apply any available capabilities 
> to subscribers traffic by arranging the LFB instance graph 
> and classifier tables.
> 
> Now, there are lots of caveats.  The big one is that 
> determining how a specific kind of FE really can be used to 
> deliver a specific service probably requires a human being to 
> do the analysis, and then inform the CE of what constructs to 
> build.  This is because there is such a range in the way FEs 
> can instantiate LFB classes and LFB instances.  (Some FEs 
> will have LFBs with tables of entries.  Others will have 
> individual LFBs for different cases.  Some FEs will have 
> static LFB instance topology, while others will allow almost 
> any topology to be built.) We have attempted to build in 
> enough information that a CE who can work with several 
> different techniques can at least determine what tools it has 
> available from the FE.
> 
> Jamal is working right now on an IPSec LFB class definition 
> to see whether the LFB definition approach and details we 
> have will work for that case.
> We need to define quite a few LFB classes just to have a 
> minimally useful set.
> 
> Yours,
> Joel M. Halpern
> 
> At 07:54 AM 4/29/2005, you wrote:
> >[I haven't fwd'ed to the list since you also didn't]
> >
> >Joel,
> >
> >Thanks a lot for your answers.  I think this helps.  Let me 
> ask you one 
> >more thing to be sure we don't talk past each other: in other words, 
> >Forces will allow me to define routing paths (L3, IP 
> addresses or other
> >locators) that use specific resources (L4, L5 and above: txcoder, 
> >meter) and in a strict order without having to resort to less 
> >Internet-friendly things like SIP 3rd party call control ?
> >
> >This seems to be a perfect platform for services that require 
> >policy-based routing ?  No? or am I way out here?
> >
> >Thanks again,
> >
> >José
> >
> >
> > > -----Original Message-----
> > > From: Joel M. Halpern [mailto:[email-masked]]
> > > Sent: Friday, April 29, 2005 1:03 PM
> > > To: Jose Rey
> > > Subject: Re: Question on scope
> > >
> > > That is a reasonable question.
> > > My view of the answer has two parts.
> > > Firstly, the ForCES protocol design has to allow for arbitrary 
> > > capabilities being handled by the FE on behalf of the CE. 
>  This can 
> > > include all of the examples you listed, IPSec, and many more.
> > > Secondly, the initial ForCES specification has to come out with a 
> > > library of LFBs that is sufficient to be useful, but not so large 
> > > that we don't get the task done.  Therefore, most of 
> those examples 
> > > will not be addressed explicitly by the first LFB library 
> > > specification.  It is anticipated that additional LFB library 
> > > documents will be written later.
> > >
> > > I hope that helps,
> > > Yours,
> > > Joel M. Halpern
> > >
> > > At 04:13 AM 4/29/2005, you wrote:
> > > >Hi all,
> > > >
> > > >I am a newbie to the list. I apologize in advance if anything 
> > > >inappropriate or repeated is asked.
> > > >
> > > >I went through the charter and over some of the drafts and I
> > > don't know
> > > >yet if I get it right.  I understand that the aim is to separate 
> > > >control and transport, that much is clear.  
> Additionally, some QoS 
> > > >functionality is implemented in the forwarding entities. 
>  But, is 
> > > >it also planned to include more advanced functionalities like
> > > transcoding,
> > > >metering, intelligent packet dropping (e.g., only P frames) in 
> > > >those FEs?? Related to that: the charter talks about per-packet 
> > > >processing but does this processing stop at layer 4 ?
> > > >
> > > >Thanks,
> > > >
> > > >José
> > > >
> > > >