headers
Jamal Hadi Salim | 2 May 2004 20:20

Re: Revised LFB input/output text

On Thu, 2004-04-29 at 10:24, Joel M. Halpern wrote:
> Let me try to separate issues a little.
>
> One aspect is how does an LFB class definition describe the decision
> process (and parameters) used by an instance of that class to choose which
> output to send a packet to.   The current approach envisioned (and probably
> not well described) in the model is taht the processing logic of an LFB
> Class is described informally.  We are not expecting to define a
> pseudo-language for LFB processing logic.  Rather we expect to use english
> descriptions.  This does imply that the writers of CEs will need to build
> into the CE understanding of the relevant behavior of any LFB class it
> needs to work with.  We are not providing any noticeable assistance for the
> CE understanding teh semantics of an LFB class.

Yes, but to have sensible english or any other natural language, you
need to remove ambiguities or be all encompassing. I used the pseudo-C
to make such a point. I also happen to know that many people follow
model documents in their implementations almost as if they were design
documents ready to be whipped into code.

> The textual description for an LFB class might say that the LFB validates
> the IP header, and anything that fails the check is sent to the error
> output singleton.  Anything that passes the check has its meta-data
> examined and branches by examining a dispatch table indexed by the
> "service-class" meta-data element and giving the output index in the
> normal-output port group.

The example i gave shows the result of the processing making the call on
the path taken. I indicated that consulting "arriving" metadata is part
of the processing phase. You seem to be indicating the metadata,
(Continue reading)

Permalink | Reply | 22 comments |
headers
Alan DeKok | 3 May 2004 20:35
Favicon

Re: Revised LFB input/output text

Jamal Hadi Salim wrote:
>
> The example i gave shows the result of the processing making the call on
> the path taken. I indicated that consulting "arriving" metadata is part
> of the processing phase. You seem to be indicating the metadata,
> probably encoded in a previous LFB instance, is used to make
> post-processing path decision. I think we are saying the same thing from
> a mile view, the granularity may be different. To me its like you have
> two LFBs in one.

   Almost.  The issue is one which has been debated within the ForCES
model group.  If we have permit only the "redirector" LFB to redirect an
input to one or more of N outputs, then many, many, other LFB's will
almost always be followed by a redirector.  Further, the XML
descriptions of the LFB's become more complex, as the redirector now has
properties (multiple outputs) which no other LFB shares.

   By placing some redirection ability within each LFB, the schema
becomes more consistent, and many models of implementations become more
obvious to the implementors.  So in this case, an "IP validation LFB"
can have two outputs: good packets, and bad packets.

   The benefit of having two outputs here is that the "metadata" which
chooses between the two outputs is internal to the LFB.  If we were to
require a redirector to make this decision, that metadata MUST be
external to the LFB, which means that the ForCES model needs to describe
it.  By keeping it in the LFB, it becomes "implementation defined".  So
long as the external behavior is consistent across implementations, it
doesn't matter how that metadata is represented.
(Continue reading)

Permalink | Reply | 21 comments |
headers
Jamal Hadi Salim | 4 May 2004 04:39

Re: Revised LFB input/output text

On Mon, 2004-05-03 at 14:35, Alan DeKok wrote:
> > To me its like you have
> > two LFBs in one.
>
>    Almost.  The issue is one which has been debated within the ForCES
> model group.  If we have permit only the "redirector" LFB to redirect an
> input to one or more of N outputs, then many, many, other LFB's will
> almost always be followed by a redirector.

It is true there will be one of n outputs that an LFB instance will end
up going to. Why you need a redirector for each case, i dont fully see.
Ok, maybe the root issue is this "redirector" thing. I see the task of a
redirector to be infact a stealer of packets. It takes a packet and
redirects it to some hole - be it a port/channel/software device etc.
Essentially, the topology of LFBs terminates once it hits a redirector
at least in the local scope of its execution path.
If you were to look at it the way i just described it, then a redirector
is not needed for each LFB. It does seem like the model draft also
defines a redirector as something that interconnets LFB instances. A
better name for something like this is a "brancher". No pun intended.

>  Further, the XML
> descriptions of the LFB's become more complex, as the redirector now has
> properties (multiple outputs) which no other LFB shares.

The XML thing is new - is having a output port group useful to the XML
definition or makes it easier to describe?

>    By placing some redirection ability within each LFB, the schema
> becomes more consistent, and many models of implementations become more
(Continue reading)

Permalink | Reply | 9 comments |
headers
Joel M. Halpern | 4 May 2004 13:47

Re: Revised LFB input/output text

In my view, both of those are internal operations of the LFB.  If an LFB is
going to select an output based on its input meta-data (or select an output
and attach an associated meta-data, or attach meta-data and send the
p[acket to the associated output, or any order you like) that is internal
processing of the LFB and needs to be described clearly in the LFB
description.

If, and only if, the situation is modelled as two LFBs, (one which
generates the meta-data and passes the packet with the meta-data to a
second LFB which uses the meta-data to select the output) then you have
different processing.

That is why Alan (I think), and I, view that second as more complex.

Yours,
Joel M. Halpern

At 10:39 PM 5/3/2004 -0400, Jamal Hadi Salim wrote:
>In my view i see the folowing as the internal path:
>- packet comes into LFB instance
>- process packet by probably consulting metadata if need to.
>- select output based on processing result.
>
>you seem to say (and i have heard Joe say this as well i think):
>- packet comes into LFB instance
>- process packet
>- consult metadata to select output.
Permalink | Reply | 0 comments |
headers
Alan DeKok | 4 May 2004 21:35
Favicon

Re: Revised LFB input/output text

Jamal Hadi Salim wrote:

> It is true there will be one of n outputs that an LFB instance will end
> up going to. Why you need a redirector for each case, i dont fully see.

   It depends on the conceptual model you use.  If you split the LFB's
by function, then an LFB which decides "IP packet good/bad" can

   a) mark the packet good/bad, and let a later LFB redirect the bad packets
   b) do the redirection itself.

> Ok, maybe the root issue is this "redirector" thing. I see the task of a
> redirector to be infact a stealer of packets. It takes a packet and
> redirects it to some hole - be it a port/channel/software device etc.

   Exactly.

> Essentially, the topology of LFBs terminates once it hits a redirector
> at least in the local scope of its execution path.

   I'm not sure why.  The topology of an IP network includes bridges and
switches.  A redirector is just another name for a bridge/switch, but in
the context of LFB's.

> The XML thing is new - is having a output port group useful to the XML
> definition or makes it easier to describe?

   Someone else would have to answer that.

> In my view i see the folowing as the internal path:
(Continue reading)

Permalink | Reply | 7 comments |
headers
Robert Haas | 5 May 2004 15:39
Picon
Favicon

Re: Revised LFB input/output text

Alan,
I assume the notion of "duplicator" is included in the model. Correct me 
if I am wrong: can there be more than one simultaneous outputs as a 
result of an LFB processing ? Take for example a non-intrusive 
packet-capturing application that wants to redirect copies of packets 
for analysis at the CE, while leaving the stream of packets untouched.

Regards,
-Robert

Alan DeKok wrote:

> Jamal Hadi Salim wrote:
>
>>
>> The example i gave shows the result of the processing making the call on
>> the path taken. I indicated that consulting "arriving" metadata is part
>> of the processing phase. You seem to be indicating the metadata,
>> probably encoded in a previous LFB instance, is used to make
>> post-processing path decision. I think we are saying the same thing from
>> a mile view, the granularity may be different. To me its like you have
>> two LFBs in one.
>
>
>   Almost.  The issue is one which has been debated within the ForCES
> model group.  If we have permit only the "redirector" LFB to redirect an
> input to one or more of N outputs, then many, many, other LFB's will
> almost always be followed by a redirector.  Further, the XML
> descriptions of the LFB's become more complex, as the redirector now has
> properties (multiple outputs) which no other LFB shares.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Joel M. Halpern | 5 May 2004 16:32

Re: Revised LFB input/output text

Although we have not defined such an LFB class yet, it is certainly 
permissible (and necessary for certain cases) to do so.
Any one packet can only go one place, but an LFB can create as many packets 
as it needs to in order to do its job.

Yours,
Joel

At 03:39 PM 5/5/2004 +0200, Robert Haas wrote:
>Alan,
>I assume the notion of "duplicator" is included in the model. Correct me 
>if I am wrong: can there be more than one simultaneous outputs as a result 
>of an LFB processing ? Take for example a non-intrusive packet-capturing 
>application that wants to redirect copies of packets for analysis at the 
>CE, while leaving the stream of packets untouched.
>
>Regards,
>-Robert
>
>Alan DeKok wrote:
>
>>Jamal Hadi Salim wrote:
>>
>>>
>>>The example i gave shows the result of the processing making the call on
>>>the path taken. I indicated that consulting "arriving" metadata is part
>>>of the processing phase. You seem to be indicating the metadata,
>>>probably encoded in a previous LFB instance, is used to make
>>>post-processing path decision. I think we are saying the same thing from
>>>a mile view, the granularity may be different. To me its like you have
(Continue reading)

Permalink | Reply | 9 comments |
headers
Jamal Hadi Salim | 5 May 2004 16:40

Re: Revised LFB input/output text

On Tue, 2004-05-04 at 15:35, Alan DeKok wrote:
> Jamal Hadi Salim wrote:
>
> > It is true there will be one of n outputs that an LFB instance will end
> > up going to. Why you need a redirector for each case, i dont fully see.
>
>    It depends on the conceptual model you use.  If you split the LFB's
> by function, then an LFB which decides "IP packet good/bad" can
>
>    a) mark the packet good/bad, and let a later LFB redirect the bad packets
>    b) do the redirection itself.

I dont have a problem with the multiple branches out of an LFB instance.
Of course you can be as granular as you want and have it with two LFBs
for the above.

> > Ok, maybe the root issue is this "redirector" thing. I see the task of a
> > redirector to be infact a stealer of packets. It takes a packet and
> > redirects it to some hole - be it a port/channel/software device etc.
>
>    Exactly.

So lets settle this, since it is one of two issues i raised. Lets see
where a redirector is typically used in common literature:
- port redirector on Servers/firewalls --> used to imply a packet
destined to a TCP/UDP/SCTP port X gets sent to another port instead. The
redirection is the termination of that transaction on the local scope at
least.
- Port redirection on a lot of ethernet switches --> A packet coming on
physical port X gets redirected to physical port Y based on some match.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Jamal Hadi Salim | 5 May 2004 16:51

Re: Revised LFB input/output text

On Wed, 2004-05-05 at 10:32, Joel M. Halpern wrote:
> Although we have not defined such an LFB class yet, it is certainly
> permissible (and necessary for certain cases) to do so.
> Any one packet can only go one place, but an LFB can create as many packets
> as it needs to in order to do its job.

Actually, the mirror/duplicator LFB is an interesting contrast to the
redirector LFB; using what i know of common literature usage, one steals
packets(redirector) the other (nirror) just takes a copy of the packet
possibly to a different topology and lets it go on its merry way.
So how does the modelled topology look in your case for the two
contrasts?  I think it is a fundamental piece of the model.

cheers,
jamal
Permalink | Reply | 8 comments |
headers
Joel M. Halpern | 5 May 2004 17:07

Re: Revised LFB input/output text

 From a topological point of view, the two are the same.
They are each an LFB instance of an LFB class (two different classes).
They each have one input, with meta-data tagging, and two outputs.
One class is defined to use the meta-data to decide which of the two
outputs to send the packet to.
The other is defined to always send the packet on output 1, and sometimtes
(depending upon the metadata) to make a copy of the packet, modify the
meta-data and send the copy on output two.

I would expect the outputs to have very different names in the two LFB
class definitions.  The first one might have outputs named IPv4 and IPv6,
while the second might have outputs named normal and LEA.

Connecting those outputs up properly is the job of the CE>

Yours,
Joel

At 10:51 AM 5/5/2004 -0400, Jamal Hadi Salim wrote:
>On Wed, 2004-05-05 at 10:32, Joel M. Halpern wrote:
> > Although we have not defined such an LFB class yet, it is certainly
> > permissible (and necessary for certain cases) to do so.
> > Any one packet can only go one place, but an LFB can create as many
> packets
> > as it needs to in order to do its job.
>
>Actually, the mirror/duplicator LFB is an interesting contrast to the
>redirector LFB; using what i know of common literature usage, one steals
>packets(redirector) the other (nirror) just takes a copy of the packet
>possibly to a different topology and lets it go on its merry way.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane