Subject: Re: [issue32] Packet Redirect

From: Weiming Wang <[email-masked]>
Date: Thu, 16 Jun 2005 22:18:55 +0800

Jamal,

For this issue, there seems only a left question that if we can avoid encapsulating redirected packets with PL header. As far as I can catch, I see that Hormuzd, Joel, and I are more tend to using such encapsulation, and you and maybe Robert more tend not to use. Could you show more on this, especially the scheme you tried to use in your implementation. I hope we could close this also asap.

thanks,
Weiming

----- Original Message ----- 
From: "Avri Doria" <[email-masked]>
Subject: [issue32] Packet Redirect

        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 <[email-masked]>
<http://www.mip4.org/issues/tracker/forces/issue32>
___________________________________________________

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 16 Jun 2005 11:04:23 -0400

On Thu, 2005-16-06 at 22:18 +0800, Weiming Wang wrote:
> Jamal,
> 
> For this issue, there seems only a left question that 
> if we can avoid encapsulating redirected packets with 
> PL header. As far as I can catch, I see that Hormuzd, 
> Joel, and I are more tend to using such encapsulation, 
> and you and maybe Robert more tend not to use. Could 
> you show more on this, especially the scheme you tried 
> to use in your implementation. 

The note is more on how pervasive do we want Forces to be i.e not
whether we disagree on gaving a forces redirect header. 
In a minimal for interoperability, so that Roberts CE and Weimings FE
can talk nicely to each other, we MUST have the redirect header attached
by the sender so the receiver can properly intepret. Header in this case
would be the Forces redirect header. I dont think there is any
disagreement on that specific issue. At least there was never any on my
part; the other person talking about this was Furquan - who is
unfortunately away.

On the note #32, to clarify, lets me point out the possibilities of
achieving this packet redirect between CE/FE in the real world:
 
Possibility 1) If we can have the FE data path capable of attaching
Forces header/meta data and redirecting to CE - then this would be the
most effective and efficient way of doing things. Clearly you can
achieve this via a s/ware based FE or writing some NP microcode
to achieve this.

Possibility 2) You cant redirect in the FE data path. In such a case the
second option is you are at least able to redirect to some CPU s/ware in
the FE which then wraps the Forces redirect header around such a packet
and sends it to the CE. This scheme is less effective than #1 above
mostly because most FEs out there have relatively slow CPUs that you
need to use for a lot of other things. It still, however, meets the
requirements for interoperability. Now if you cant do #1 and you cant do
#3 you are dead. You cant use such hardware for a forces FE and still
guarantee interop; but you MAY be able to still do it if you can do #3
below.

Possibility 3) Your FE hardware is capable of doing redirects 
but not just able to add forces metadata to it. It may be able to add a
VLAN tag or something simple like that. This is very very common; a lot
of commodity ASICs and boxes can do this. In such a case if you are
configuring the FE and the CE you will need to create a mapping between
the Forces redirect header and whatever metadata that this legacy ASIC
can do. Of course both the FE and the CE would be expected to understand
such metadata translation. This is easy to do if you are creating both
the CE and the FE. 
As a note: this doesnt exclude that your FE is capable of #2 above. Your
FE could be capable of #2 but you opt not to do it for efficiency
reasons (because you save CPU cycles by not sending to the CPU;->)
I claim that most people (this claim is verified by Furquan I believe)
will end up using #3.

My concern as noted in the issue#32 is not to ignore #3 and enforce that
either #1 or #2 be used regardless. Because this will make Forces less
pervasive (trust me when i say that some people take what is written as
scripture and you fail the RFP laugh test if you dont have it
_righteously_ implemented in their definition); however, In the case of
JoeBlows FE and Weimings CE (assuming JoeBlow didnt work closely with
Weiming in building the NE) then either #1, or #2 MUST be implemented on
both sides.

To close this issue, I was hoping to see some discussion or mention of
#3 in the draft so implementors understand it is a possibility (with the
repurcasions duly noted).

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 16 Jun 2005 14:34:51 -0400

I believe that the mandatory to implement standardized TML and PL must 
include suitable encapsulation of redirect packets and congestion control 
on their transfer.
The Source and Sink LFBs seem the right tool for the job.

Now, someone can define an additional TML which provides what looks like 
the right headers on the upper interface, but does not actually ad them to 
the packet on the wire.  And an FE could implement such a TML in a fashion 
that did not ever try to create the headers.
But if that FE wants to interoperate with standard CEs, it also needs to 
implement the mandatory-to-implement TML.  Even if that requires that it 
use the slow path.  (That is also what one ought to expect from any FE that 
claims to implement the RFCs.)

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 16 Jun 2005 14:59:06 -0400

> claims to implement the RFCs.)

Is there any thing we can say about such a TML in the protocol draft or
would that lead to confusion?

cheers,
jamal

---

From: Weiming Wang <[email-masked]>
Date: Sun, 26 Jun 2005 10:50:27 +0800

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" <[email-masked]>
To: <[email-masked]>
Sent: Monday, May 23, 2005 2:35 AM
Subject: [issue32] Packet Redirect

New submission from Avri Doria <[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.

----------
category: Editorial

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 25 Jun 2005 23:42:18 -0400

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 26 Jun 2005 09:49:21 -0400

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
>
>From: "Joel M. Halpern"
>Subject: Re: [issue32] Packet Redirect
>
>
> > >      a. The event is triggered every time a new redirected packet 
> arrives
> > > at the LFBs.

---

From: Weiming Wang <[email-masked]>
Date: Mon, 27 Jun 2005 22:01:10 +0800

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" <[email-masked]>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 27 Jun 2005 11:30:33 -0400

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:
>From: "Joel M. Halpern" <<mailto:[email-masked]>[email-masked]>
>
> > > > >      b. The event is transported by the Redirect  Message only, 
> while
> > > the
> > > > >From: "Avri Doria" 
> <<mailto:[email-masked]>[email-masked]>
> > > > >To: <<mailto:[email-masked]>[email-masked]>
> > > > >New submission from Avri Doria <<mailto:[email-masked]>[email-masked]>:
> > > > >
> > > > >6.8
> > > > >
> > > > >Forces issue tracker 
> <<mailto:[email-masked]>[email-masked]>

---

From: Weiming Wang <[email-masked]>
Date: Tue, 28 Jun 2005 09:56:56 +0800

Joel,

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          |

Now, the question is I do find this format is not very different with that I proposed. Do I miss something?

Thanks,
Weiming