Subject: Re: [issue32] Packet Redirect

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 27 Jun 2005 22:55:08 -0400

The differences are minor.
Firstly, I wanted to clarify the general principle of top level TLVs.
I am not sure we need the LFB class.  It may be useful (for differention 
source from sink, and allowing subclassing of the redirect LFBs.
And I would not expect the remaining content to be an Operation 
TLV.  Rather, I would expect it to be the packet.

But mostly, we are in agreement.

Yours,
Joel

At 09:56 PM 6/27/2005, Weiming Wang wrote:
>Joel,
>
> >      The Packet Redirect message contains one or more (typically one)
> > packet-redirect TLVs.
>
>If I understand your above thought correctly, I think your proposal  is to 
>define a  packet-redirect TLV rathan than a LFBselectTLV at the top level 
>for the message. In this way it will leave LFB selection information as 
>kinds of meta-info and inside the TLV, something like:
>
> > >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >         |        Type = 
> Packet-Redirect        |               Length          |
> > >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >         |                          LFB Class ID                         |
> > >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >         |                        LFB Instance ID                        |
> > >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >         |                        Operation TLV                          |
> > >         .                                                               .
> > >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>Now, the question is I do find this format is not very different with that 
>I proposed. Do I miss something?
>
>Thanks,
>Weiming
>
>
> > I would approach this differently.  The current text describes the
> > LFBselect LFB.  It correctly defines the LFBselect LFB.  That definition
> > should not be thrown away.
> >
> > The message structure documentation can say
> >     A PL protocol messages consists of a protocol header followed by 
> one or
> > more TLVs.  All TLVs
> >     consist of  two byte type and a two byte length, followed by contents
> > dependent upon the type
> >     of the TLV.  The TLVs which are valid in a message depend upon the
> > message type.
> >     Most message types allow one or more LFBselect TLVs and no other top
> > level TLVs.  The
> >     following are the message types this applies to:
> >        Association setup request and response.
> >        Config message request and response
> >        Query message request and response
> >        Event Notify message.
> >     The Association teardown message contains a single instance of the
> > teardown-cause TLV.
> >     The heartbeat message contains a single instance of the heatrbeat
> > TLV.  (Unless we decide
> >      to just use an event for heartbeats.  I don't remember where that
> > discussion stands.)
> >      The Packet Redirect message contains one or more (typically one)
> > packet-redirect TLVs.
> > This is then followed by a section for each of these top level TLVs.
> >
> > Yours,
> > Joel M. Halpern
> >
> > At 10:01 AM 6/27/2005, Weiming Wang wrote:
> > >Joel :)
> > >
> > >How about we just obsolete the path from the data structure and add some
> > >meta-information, and form the format as below (I currently can only think
> > >of the meta-information as the packet type. We may add some more later).
> > >
> > >Could you give more comments on this, then we may solve this issue soon?
> > >
> > >Thank you very much.
> > >
> > >Weiming
> > >
> > >---------------------
> > >Message Body:
> > >       Consists of one or more TLVs, with every TLV having the following
> > >       data format:
> > >
> > >         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >         |        Type = LFBselect       |               Length          |
> > >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >         |                          LFB Class ID                         |
> > >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >         |                        LFB Instance ID                        |
> > >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >         |                        Operation TLV                          |
> > >         .                                                               .
> > >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >         ~                           ...                                 ~
> > >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >         |                        Operation TLV                          |
> > >         .                                                               .
> > >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > >    LFB class ID:
> > >       There are only two possible LFB classes here, the 'RedirectSink'
> > >       LFB or the 'RedirectSource' LFB.  If the message is from FE to CE,
> > >       the LFB class should be 'RedirectSink'.  If the message is from CE
> > >       to FE, the LFB class should be 'RedirectSource'.
> > >    Instance ID:
> > >       Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB.
> > >    Operation TLV:
> > >       This is a TLV describing one packet of data to be directed via the
> > >       specified LFB above.  The order of the TLV appeared is also the
> > >       order the data packet arrives the redirector LFB, that is, the
> > >       Redirected Data  in the first TLV should arrive the earliest.
> > >
> > >The TLV format is as follows:
> > >
> > >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >         |    Type = PAYLOAD             |               Length          |
> > >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >         ~         Packet Type           |         Packet Length         ~
> > >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >         ~                        Redirected Packet                      ~
> > >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > >     Type:
> > >       The type for the TLV is set to 'PAYLOAD'.
> > >
> > >     Length:
> > >       the length of the TLV(in 4bytes).
> > >
> > >     Packet Type:
> > >       Defines what type the redirected packet belongs to(such as 'IPv4
> > > Packet',
> > >      'IPv6 Packet').
> > >
> > >     Packet Length:
> > >       the length of the followed redirected packet (in byte)
> > >
> > >     Redirected Packet:
> > >       one redirected packet.
> > >-----------------------------
> > >
> > >
> > >----- Original Message -----
> > >From: "Joel M. Halpern" 
> <<mailto:[email-masked]>[email-masked]>
> > >
> > > > I would expect that a Redirect Message has a different outermost 
> TLV.  The
> > > > grammar is intended to help us, not serve as a 
> straightjacket.  Different
> > > > message types can have different outer TLVs.  It is desirable to 
> use the
> > > > same structure when it applies.  But the redirect message is simply a
> > > > different case.  It's contents are not a DATARAW much less a DATA
> > > TLV.  Its
> > > > content structure is not defined by an LFB element definition or Model
> > > > DataDefs structure definition.
> > > >
> > > > If we need to fix the "grammar" section to make it clear that not 
> all PL
> > > > messages necessarily use the same outermost TLV, we should do 
> so.   My own
> > > > approach would be to separate the grammar into a definition of the
> > > contents
> > > > of that TLV, and a separate definition of which TLVs / content are 
> carried
> > > > in the outermost level of which messages.
> > > >
> > > > Yours,
> > > > Joel
> > > >
> > > > PS: Weiming, I am sorry you got caught up in this confusion.  I don't
> > > think
> > > > you created the tendency I am railing against above.  I am just 
> using your
> > > > message as a starting point to hammer home a point.
> > > >
> > > > At 04:45 AM 6/26/2005, Wang,Weiming wrote:
> > > > >Maybe it's me who missed something :)
> > > > >My thought was we might need to obey our message grammar well that we
> > > have
> > > > >to use a strict Path-data for operation TLV.  To obey the rule, 
> treating
> > > > >it as an event will ease the message format greatly.
> > > > >
> > > > >Actually I'm very happy to see that you agree a path can be 
> omitted for
> > > > >some specific messages like redirect messge.
> > > > >
> > > > >OK, let's solve it then, to let redirect message only contain Data
> > > > >field?  I can update this redirect message part text then.
> > > > >
> > > > >Jamal, could you give a response on this?
> > > > >
> > > > >One  less vital question is, shall we allow for mulitpul redirect 
> packets
> > > > >encapsulated in one TLV or just one TLV only for one packet? To 
> use the
> > > > >former, we have to define a sequence for the redirected packets 
> then in
> > > > >the TLV.
> > > > >
> > > > >On  the meta-information related, I think LFB IDs has already been
> > > > >included. I don't think we need an extra port ID to indicate where 
> to put
> > > > >the redirected data to or to get redirected data from. A redirect 
> source
> > > > >LFB  or sink LFB will  have a port ID, which belongs to FE LFB 
> topology
> > > > >concept, and FE LFB topolgy configuration is in charge of 
> this.  Not sure
> > > > >if it complies with your thought?
> > > > >
> > > > >Thanks,
> > > > >Weiming
> > > > >
> > > > >----- Original Message -----
> > > > >From: "Joel M. Halpern"
> > > > >Subject: Re: [issue32] Packet Redirect
> > > > >
> > > > >
> > > > > > I am missign something in your suggestion.
> > > > > >
> > > > > > Why would we want to treat redirects as events?
> > > > > > We should treat them as redirects.
> > > > > >
> > > > > > I am very confused about "How a path should be defined in a Packet
> > > > > Redirect
> > > > > > Message", since as far as I can tell, a redirect does not need a
> > > path.  It
> > > > > > needs a collection of meta-information, which we need to
> > > define.  At the
> > > > > > moment, that has to include at least the LFB ID that the 
> redirect is
> > > > > from /
> > > > > > to.  I suppose by declaring a multiplicity of such LFBs, that 
> can be
> > > > > all of
> > > > > > the information.  (I usually think in terms of at least a logical
> > > port ID
> > > > > > the packet came from / is intended for.)
> > > > > >
> > > > > > Yours,
> > > > > > Joel
> > > > > >
> > > > > > At 10:50 PM 6/25/2005, Weiming Wang wrote:
> > > > > > >Jamal, Joel, and Hormzd,
> > > > > > >
> > > > > > >I suppose we could close this issue by reaching the following 
> points:
> > > > > > >
> > > > > > >1. The redirect LFBs called RedirectSource  LFB and RedirectSink
> > > LFB are
> > > > > > >moved to the model, but the protocol retains the Redirect 
> Message. The
> > > > > > >reason to keep the specific message is we need to specifically
> > > recognize
> > > > > > >redirected data between CE-FE transportation to avoid DoS attacks.
> > > > > > >
> > > > > > >2. The redirected data in the LFBs can be treated as a kind of 
> SPECIAL
> > > > > > >events in that:
> > > > > > >      a. The event is triggered every time a new redirected packet
> > > > > arrives
> > > > > > > at the LFBs.
> > > > > > >      b. The event is transported by the Redirect  Message only,
> > > while
> > > > > the
> > > > > > > Redirect Message will the same message format as a general event
> > > > > > > notification message (except the message type in the header).
> > > > > > >
> > > > > > >By doing in this way, we can also solve the issue53 (How a path
> > > should be
> > > > > > >defined  in Packet Redirect Message) then.
> > > > > > >
> > > > > > >Unfortunately,  I think of another question that is related to 
> the
> > > Packet
> > > > > > >Redirect Message as well as to Event Notification Message. The
> > > question
> > > > > > >is, the Event Notification Message allows event generated by CE
> > > and sent
> > > > > > >to FE. In the case, in the message format, the LFB IDs refer to
> > > the LFBs
> > > > > > >that will receive the event notification, but the question is,
> > > what the
> > > > > > >Path in the message refers to then ??  The same also happens 
> to Packet
> > > > > > >Redirect Message from CE to FE.
> > > > > > >
> > > > > > >Thanks,
> > > > > > >Weiming
> > > > > > >
> > > > > > >----- Original Message -----
> > > > > > >From: "Avri Doria"
> > > <<mailto:[email-masked]>[email-masked]>
> > > > > > >To: 
> <<mailto:[email-masked]>[email-masked]>
> > > > > > >Sent: Monday, May 23, 2005 2:35 AM
> > > > > > >Subject: [issue32] Packet Redirect
> > > > > > >
> > > > > > >
> > > > > > >New submission from Avri Doria 
> <<mailto:[email-masked]>[email-masked]>:
> > > > > > >
> > > > > > >6.8
> > > > > > >
> > > > > > >  Editorial Note:  There are also discussions on how LFBs in 
> FE model
> > > > > > >                     that are related to packet redirect 
> operations
> > > > > > >                     should be defined.  Although it is out of 
> the
> > > scope
> > > > > > >                     of forces protocol, how to define the 
> LFBs affect
> > > > > > >                     the Packet Redirect Message described
> > > here.  Because
> > > > > > >                     currently it is still in progress in FE 
> model
> > > on how
> > > > > > >                     to define such LFBs, we try to post some
> > > thoughts on
> > > > > > >                     this here for discussion.  They will be 
> removed
> > > > > > >                     later along with the progress of the FE 
> model
> > > work.
> > > > > > >         Thought 1:  To define LFBs called 'RedirectSink' and
> > > > > > >                     'RedirectTap' for packet redirect.
> > > > > > >                     An LFB in FE called 'RedirectSink' is
> > > responsible to
> > > > > > >                     collect data packets that need to be
> > > redirected to
> > > > > > >                     CE.  From the perspective of the FE LFB 
> topology,
> > > > > > >                     the 'RedirectSink' LFB is an LFB with only
> > > one input
> > > > > > >                     port and without any output port, and the
> > > input port
> > > > > > >                     can then be connected to any other LFB in FE
> > > model
> > > > > > >                     by means of a datapath in the forwarding 
> plane.
> > > > > > >                     From the perspective of the ForCES protocol
> > > layer,
> > > > > > >                     the 'RedirectSink' LFB will generate the 
> Packet
> > > > > > >                     Redirect Messages when it receives data
> > > packets from
> > > > > > >                     forwarding plane.
> > > > > > >
> > > > > > >                     An LFB in FE called 'RedirectTap' is
> > > responsible to
> > > > > > >                     receive data packets that are redirected 
> from CE.
> > > > > > >                     From the perspective of the FE LFB 
> topology, the
> > > > > > >                     'RedirectTap' LFB is an LFB with only one 
> output
> > > > > > >                     port and without any input port, and the
> > > output port
> > > > > > >                     can then be connected to any other LFB in FE
> > > model
> > > > > > >                     by means of a datapath in the forwarding 
> plane.
> > > > > > >                     From the perspective of ForCES protocol
> > > layer, the
> > > > > > >                     'RedirectTap' LFB can receive the Packet 
> Redirect
> > > > > > >                     Messages from CE, and un-encapsulate the data
> > > > > > >                     packets from the message and put them to
> > > datapaths
> > > > > > >                     in the forwarding plane.  Actually the
> > > 'RecirectTap'
> > > > > > >                     LFB acts more like a transcoder that
> > > transfers the
> > > > > > >                     ForCES protocol messages to normal data
> > > packets in
> > > > > > >                     IP forwarding plane.  As a result, if we 
> need to
> > > > > > >                     have redirected packets connected to some 
> LFB
> > > (say a
> > > > > > >                     Scheduler) in FE model, we only need to
> > > connect the
> > > > > > >                     'RedirectTap LFB to the Scheduler LFB
> > > directly via a
> > > > > > >                     datapath as follows:
> > > > > > >
> > > > > > >
> > > > > > >                              +-----------------+ 
> +-----------+
> > > > > > >                              | RedirectTap LFB 
> |------>|           |
> > > > > > >                              +-----------------+       | 
>       |
> > > > > > >                                                        | 
> Scheduler |
> > > > > > >                                  From other 
> LFB   ---->|    LFB    |
> > > > > > >                                                        | 
>       |
> > > > > > > 
> +-----------+
> > > > > > >
> > > > > > >                                Figure 27
> > > > > > >
> > > > > > >                     By use of several 'RedirectSink' LFBs and 
> several
> > > > > > >                     'RedirectTap' LFBs that connect to several
> > > different
> > > > > > >                     datapaths in FE forwarding plane, 
> multiple packet
> > > > > > >                     redirect paths between CE and FE can be
> > > constructed.
> > > > > > >
> > > > > > >         Thought 2:  There might be another way a packet could be
> > > > > > >                     redirected: directly by a forwarding path,
> > > e.g., by
> > > > > > >                     FPGA/ASIC/NP microcode.  In such a case 
> we do not
> > > > > > >                     need to put in a lot of smartness.  Probably
> > > a link
> > > > > > >                     layer or even network level header is
> > > enough.  The
> > > > > > >                     receiver demuxes it only based on some
> > > protocol type
> > > > > > >                     in the link layer or network transport
> > > layer.  The
> > > > > > >                     pros for this appraoch is it may provide a
> > > fast and
> > > > > > >                     cost-effective path for packet 
> redirect.  The
> > > cons
> > > > > > >                     for this is it may more or less confuses 
> the Fp
> > > > > > >                     reference point definition in ForCES 
> framework.
> > > > > > >
> > > > > > >----------
> > > > > > >category: Editorial
> > > > > > >draft: draft-ietf-forces-protocol
> > > > > > >messages: 49
> > > > > > >nosy: avri
> > > > > > >priority: Must fix
> > > > > > >status: No discussion
> > > > > > >title: Packet Redirect
> > > > > > >
> > > > > > >___________________________________________________
> > > > > > >Forces issue tracker
> > > <<mailto:[email-masked]>[email-masked]>
> > > > > > ><http://www.mip4.org/issues/tracker/forces/issue32>
> > > > > > >___________________________________________________
> > > > > >

---

From: Weiming Wang <[email-masked]>
Date: Tue, 28 Jun 2005 11:04:35 +0800

> TLV.  Rather, I would expect it to be the packet.
Omitting operation TLV will lead to the fact that we only allow one packet data in one top TLV. That's the question that I raised days before. From the efficiency point of view, to allow more than one packet in one top TLV may be benifitful a little.

Thanks,
Weiming

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 27 Jun 2005 23:20:28 -0400

Given that packets requiring redirection are likely to be scattered, and 
given that multiple redirect TLVs (each with a packet) can be included in a 
message if that is useful, I don't see much value it the extra wrapper to 
allow multiple packets inside the TLV.

Yours,
Joel

At 11:04 PM 6/27/2005, Weiming Wang wrote:

>Omitting operation TLV will lead to the fact that we only allow one packet 
>data in one top TLV. That's the question that I raised days before. From 
>the efficiency point of view, to allow more than one packet in one top TLV 
>may be benifitful a little.
>
>Thanks,
>Weiming
> >
> > > > >         |                          LFB Class 
> ID                         |
> > > > >         |                        LFB Instance 
> ID                        |
> > > > >         |                        Operation 
> TLV                          |
> > > > >         . 
>        .
> LFBselect       |               Length          |
> > > > >         |                          LFB Class 
> ID                         |
> > > > >         |                        LFB Instance 
> ID                        |
> > > > >         |                        Operation 
> TLV                          |
> > > > >         . 
>        .
> > > > >         ~                           ... 
>        ~
> > > > >         |                        Operation 
> TLV                          |
> > > > >         . 
>        .
> PAYLOAD             |               Length          |
> > > > >         ~                        Redirected 
> Packet                      ~

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 28 Jun 2005 08:57:11 -0400

> allow multiple packets inside the TLV.

Let me share what we do - i havent really read the thread in full to
make full sense of what Joel/Weiming are saying[1]. So i dont know who i
am agreeing with ;-> 

Heres an example of a redirect that we have implemented thus far shipped
as a Forces message.

common header (type = REDIRECT)
|
|
+---- LFB selector (Redirect LFB, instance X)
      |
      |
      +----- TLV, Type = REDIRECT_device (for lack of better name) 
              |
              |
              +--- ifindex of sink or source port
              |
              |
              +--- Packet data in network order

Several observations:

1) In theory, we should be able to repeat the TLV multiple times to send
several packets in one PL message. We dont do that at the moment; when
we get to optimizing we will probably do so.

2) There is only one termination point for either source/sink - they are
not being differentiated as two different things. So when the message
goes from FE->CE, the ifindex is that of the FEs port in which in the
packet was received/sourced. On the CE->FE direction, the ifindex is
that of the FEs port in which the the packet is to be transmitted. We
found that we absolutely needed to at least have this little ifindex
header.

3) There is only one REDIRECT LFB and several instances (one for IKE,
one for OSPF etc).

Some performance numbers:
Here are some numbers when we use different redirect schemes from the
FE->CE:

Scheme 1: As described above, MUST implement for forces. Roundtrip
latency adds 1.1 ms (note we cross to/fro user space 4 times)

Scheme 2: I described earlier, tagged as the TML redirect by Joel:
(redirect happens in the forwarding path; this could be in the kernel or
in hardware): adds less than 10us to round trip latency.

cheers,
jamal 

[1]I am very tied up elsewhere but hope to resurface and catchup on the
list hopefully by end of day or tommorow (I will attend the next concal
thursday btw - sorry havent responded).

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 29 Jun 2005 11:21:39 +0800

Jamal,

Thanks for the response.

I think the key difference is how the Redirect Source and Sink LFB, whose ports should be defined. Let me try to summarize the ideas first:
1. yours, only one Redirect LFB which have mulitple inputs as the sink ports to redirect data from FE->CE, and multiple outputs as the source ports to redirect data from CE->FE. With this scheme, then port number should appear in the PL redirect message format.

2. mine, several redirect LFBs, with every LFB only has one input(sink LFB) or one output(source LFB). With this scheme, there is no need to assign a port number at the PL redirect message layer. The LFB instance ID actually acts as the function of port number in scheme 1.

Joel and I actually have had a short discussion on this. Joel's thought was very identical to yours, but I just argued that the redirect LFB instance ID can act well to implement the task as where the redirect data should get and put in the LFB topology. And I'm also a little worry that 'a port number' is parameter that will highly links to how FE model defines. To directly use a FE model parameter without using a PATH-DATA rule in the PL layer may result in too high binding of the protocol and the FE model, i.e., model definition may have to make the protocol change.  

Regarding the redirect directly at TML layer, could you give more details, like on which layer it is injected, the TCP, IP, or VPN? Except doing it directly at IP, I find others may all have to have the help from user space, rather than from the forwarding plane only, which makes it quite the same as redirect at PL layer. 

Thanks,
Weiming

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 28 Jun 2005 23:47:36 -0400

I am concerned that this approach will mandate a very large number of 
Redirect LFBs for those FEs that support logical interfaces (802.1 VLANs, 
Frame Relay or ATM VCs, etc.)  For other uses, we have allowed that 
meta-data may be used to index into LFBs which have tables of 
behaviors.  (We have not mandated that, either.)

It would seem by analogy that we should allow similar tables for Redirect 
LFBs.  Which means we need to carry the "meta" information somehow between 
the CE and the FE.

Yours,
Joel

At 11:21 PM 6/28/2005, Wang,Weiming wrote:
>Jamal,
>
>Thanks for the response.
>
>I think the key difference is how the Redirect Source and Sink LFB, whose 
>ports should be defined. Let me try to summarize the ideas first:
>1. yours, only one Redirect LFB which have mulitple inputs as the sink 
>ports to redirect data from FE->CE, and multiple outputs as the source 
>ports to redirect data from CE->FE. With this scheme, then port number 
>should appear in the PL redirect message format.
>
>2. mine, several redirect LFBs, with every LFB only has one input(sink 
>LFB) or one output(source LFB). With this scheme, there is no need to 
>assign a port number at the PL redirect message layer. The LFB instance ID 
>actually acts as the function of port number in scheme 1.
>
>Joel and I actually have had a short discussion on this. Joel's thought 
>was very identical to yours, but I just argued that the redirect LFB 
>instance ID can act well to implement the task as where the redirect data 
>should get and put in the LFB topology. And I'm also a little worry that 
>'a port number' is parameter that will highly links to how FE model 
>defines. To directly use a FE model parameter without using a PATH-DATA 
>rule in the PL layer may result in too high binding of the protocol and 
>the FE model, i.e., model definition may have to make the protocol change.
>
>Regarding the redirect directly at TML layer, could you give more details, 
>like on which layer it is injected, the TCP, IP, or VPN? Except doing it 
>directly at IP, I find others may all have to have the help from user 
>space, rather than from the forwarding plane only, which makes it quite 
>the same as redirect at PL layer.
>
>Thanks,
>Weiming
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 29 Jun 2005 00:23:46 -0400

Having a general, isolated, representation for the packet meta-data wiht 
the redirected packet seems like a good idea.
Trying to come up with a good structure for that is one thing that has 
stumped me.  Good ideas would be welcome.
(I don't currently see how to use something like Path-Data, but that may 
just be me being obtuse.)

Yours,
Joel

At 12:01 AM 6/29/2005, Wang,Weiming wrote:
>Is it possible we represent the meta-data in the protocol messages in a 
>more isolating way from the data itself, just like a Path-Data mode?
>
>Thanks,
>Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 29 Jun 2005 07:32:30 -0400

On Wed, 2005-29-06 at 11:21 +0800, Wang,Weiming wrote:
> 1. yours, only one Redirect LFB which have mulitple inputs as the sink ports to redirect data from 
> FE->CE, and multiple outputs as the source ports to redirect data from CE->FE. With this scheme, then 
> port number should appear in the PL redirect message format.
> 
> 2. mine, several redirect LFBs, with every LFB only has one input(sink LFB) or one output(source LFB). 
> With this scheme, there is no need to assign a port number at the PL redirect message layer. The LFB 
> instance ID actually acts as the function of port number in scheme 1.
> 
> Joel and I actually have had a short discussion on this. Joel's thought was very identical to yours, 
> but I just argued that the redirect LFB instance ID can act well to implement the task as where the 
> redirect data should get and put in the LFB topology. And I'm also a little worry that 'a port number' 
> is parameter that will highly links to how FE model defines. To directly use a FE model parameter 
> without using a PATH-DATA rule in the PL layer may result in too high binding of the protocol and 

There are two things/numbers that are important:
1) the interface/port the packet goes in/out
2) the type of packet that is being filtered on receive.

In our case #1 was in the ifindex i showed. #2 is in the instance of the
class.
Indeed both these parameters can be coded in the path; but if we do that
it is better to keep a single LFB instance (Infact i would argue for a
single LFB instance for simplicity). In such a case, the selection is of
the form:
FEx/LFB=redirect/instance=1/operation=config/path={port,filterid} .
BTW, we havent really discussed how the CE subscribes to receive
packets.

> Regarding the redirect directly at TML layer, could you give more details, like on which layer it 
> is injected, the TCP, IP, or VPN? Except doing it directly at IP, I find others may all have to 
> have the help from user space, rather than from the forwarding plane only, which makes it quite 

Assume a stateless transport for this to work well; IP, ethernet etc.
If you could map those two numbers {src/dst port, packet type} into
something in a header, you could redirect to the PL layer.
Lets say you could redirect at the FE in hardware (most of the ethernet
switches my company sells are capable and i would suspect other vendors
do):
- add a filter rule in the FE hardware which says "if you see IKE
packets on port 10 i want you to redirect to port 23 with VLAN tag Y"

- CE is connected to port 23. On receipt of such a packet, the CE kernel
or even user space is able to deduce (by looking at MAC + VLAN headers
and peeking into the data) that the packet came through FE3, port 10 and
is an IKE packet. 
- You can then reinject it with proper forces header to the forces
process. We actually take more shortcuts, i am just simplifying.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 29 Jun 2005 07:39:06 -0400

> just be me being obtuse.)

There are 2 attributes that i described earlier:
- the ifindex and filterid.

If we can say we have a table comprising of these attributes then we can
certainly have a path to the pair of attributes.
It is more than likely these two are aliases to attributes in two other
LFBs (a port LFB and a classifier/filter LFB).

cheers,
jamal