Subject: [issue32] Packet Redirect

From: Avri Doria <[email-masked]>
Date: Sun, 22 May 2005 18:35:05 +0000

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.

        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: "Joel M. Halpern" <[email-masked]>
Date: Mon, 23 May 2005 02:15:17 -0400

My own thinking has leaned towards something along the lines of Thought 1.
Primarily, this is so that there is a place to put an TML parameters (and 
represent any TML processing logic) required for handling redirect 
packets.  Making encapsulation or other behaviors "implicit" in some aspect 
of the forwarding path seems a bad idea.

In passing, I note that I think one needs only one Sink and one Tap.  The 
Sink LFB should be able to get enough information from the packet and 
meta-data to do the job of redirecting the packet to the CE.  And any LFB 
can have a link to the one sink LFB.  SImilarly, there ought to be only one 
tap, since redirect packets from the CE have to be processed in one place, 
analyzed, and sent into the LFB topology.  If there is branching / 
conditions (OSPF packets go one place, ICMP goes somewhere else, ...) I 
think that can and should be handled by a classifier, rather than by 
multiple Tap LFBs.

Yours,
Joel

---

From: Weiming Wang <[email-masked]>
Date: Thu, 19 May 2005 23:12:53 +0800

----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: [issue32] Packet Redirect

> of the forwarding path seems a bad idea.

Agreed well.

> think that can and should be handled by a classifier, rather than by 

Joel, I think this is a trade-off between the work of FE-LFB and some more LFB (like a classifier). Note that in our current scheme of redirect message format, we allow an LFB ID. To be with more Taps actually greatly expoint the use of LFB ID here. E.g, we may just need to say "put the OSPF redirect message to  LFB ID1 (Tap1)" and " put  the ICMP redirect message to LFB ID2(Tap2)".  If using only one Tap followed by a classifier, we then need to define the classifer calrefully and the rule for the classifier may not be simple also.  I'm also not sure if all such redirect distribution can be done by classifier purely, doubting if there always exist enough differences to classify. 

Thank you.
Weiming