Subject: Re: FE-CE data path

From: "Chawla, Shuchi" <[email-masked]>
Date: Wed, 16 Mar 2005 14:24:19 -0800

Thanks for the information, Joel.  Just to confirm that I have
understood what you have said:

- An LFB instance would need to exist on the FE to do the required
protocol processing (in the example below, the SAAL LFB).  The CE would
be made aware of this FE capability via a capability query.
- An LFB on the FE would need to process "data" packets associated with
control processing and make a determination as to whether they should be
sent to the CE (via some protocol), or to an LFB (in the example below,
SAAL LFB) on the FE itself for further processing.

Is that correct?

Given the above, it seems that there is some amount of processing
occurring on these packets in the FE, due to which, I'm wondering if we
can really do wire-speed processing/tunneling of these packets at the
FE?  Am I missing something?

Thanks,
Shuchi

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, March 16, 2005 1:28 PM
To: Chawla, Shuchi; [email-masked]
Subject: Re: FE-CE data path

This kind of distirbution can be done.
In fact, if the FE has capabilities to help the CE, the CE can make use
of 
those at it sees fit.

There are two aspects to this, both related to LFB topology.

Firstly, there is the matter of how the FE will decide to send data
packets 
to the CE.  I expect that this will be represented by an instance of an
LFB 
class representing the data channel itnerface.  Thus, the LFB topology
and 
classifiers therein can be arranged to select traffic according to
whatever 
conditions are interesting (including errors, etc) and direct that
traffic 
to the LFB instance which will send it to the CE.  Similarly, this LFB 
instance can also be used as a packet source for data packets from the 
CE.  The topology configuration will determine what the FE does with
such 
packets.

Secondly, one can have LFB classes (and instances of those classes) to 
represent capabilities provided by the processor on the FE.  (In some 
implementations, all LFBs are provided by softwware on the FE.)  So if
we 
want to represent an SAAL processor on the FE, we will need an LFB class

definition for the capability.  Then, a CE working with an FE which 
supports that LFB class can choose to make use of it.

Yours,
Joel M. Halpern

At 04:17 PM 3/16/2005, Chawla, Shuchi wrote:
>I have a slightly tangential comment/question to all of this which may
>impact the FE-CE data channel discussion -- I'm not sure.  Anyway, here
>is it:
>
>I believe there are instances where some part of the control protocol
>processing may be distributed between the FE and the CE; in effect, a
>part (maybe the lower layers) of the protocol processing may be done on
>the FE, and a part of it on the CE.  As an example, I am familiar with
>an ATM switch I was involved in, that did SAAL processing on the FE and
>Q.2931 processing on the CE, thus distributing the processing of ATM
>signaling between the FEs and the CE.  The FEs had adequate processing
>capability in this case and this also reduced the burden on the CE of
>doing SAAL processing for a large number of FEs/interfaces.
>
>The above are protocols associated with the data channel.  Given that
>the current model is for the packets associated with the data channel
to
>be transported to the CE (either via a tunnel or using a transport
>protocol etc. based on the decision reached), I'm wondering how such a
>distributed control processing model might fit into the overall
>framework.  In the example above, the SAAL messages would need to be
>terminated on the FE, whereas the Q.2931 messages would need to be
>transported to the CE.  This might imply some sort of inspection of the
>data packets themselves, I assume.
>
>Maybe this has been addressed in earlier discussions; if so, could you
>please point me to the relevant information?
>
>Regards,
>Shuchi
>
>-----Original Message-----
>From: Forwarding and Control Element Separation
>[mailto:[email-masked]] On Behalf Of Furquan Ansari
>Sent: Wednesday, March 16, 2005 12:11 PM
>To: [email-masked]
>Subject: Re: FE-CE data path
>
>Hmm...Not sure if there is a problem with the list server of my
outgoing
>email - my mails to this list are not going. This is the 4th time I am
>trying, but this time posting it directly using the web interface!
>Hope it works...
>
>-----------
>
>Looks like that didn't work either - let me try it again....!!!
>
>
>Subject:
>Re: FE-CE data path
>From:
>"Furquan A. Ansari" <[email-masked]>
>Date:
>Wed, 16 Mar 2005 14:08:52 -0500
>To:
>[email-masked]
>
>Ok.... I tried sending this long time back - but looks like something
>happened and hasn't been received by the list.
>So, here goes - again.....
>
>----
>Yes, good point indeed, Joel. I misinterpreted your question regarding
>"what
>interface they arrive on" to mean at the CE (de-mux diff tunnel
>interfaces).
>And, no  Hormuzd, I am not advocating having one tunnel per external FE
>interface - that would be a pretty foolish thing to do. There will be a
>single interface from an FE to a CE.
>
>As a matter of fact, I have the CE/FE combination running as a normal
>router
>- with OSPF etc. and should have looked at my own implementation more
>carefully. One would indeed require/need the arriving interface
>information
>- e.g.  if the packet is destined to a multicast address like OSPF
>packets
>(for unicast, one can derive it from the destination address). Having
>said
>that, the discussion of appending/providing some information to obtain
>this
>result (intf info)  is different from needing a transport layer
>protocol.
>There's nothing preventing one from still using a tunnel with the
>information added - e.g. as Jamal pointed out in the VLAN example.
>
>My motivation for tunnelling is to allow a packet to be forwarded at
>wire-speed (ASICs) without it seeing the light of day at the processor
>of
>the FE.  However, if some additional header/tag requires it to be
pulled
>out
>anyway, the performace advantages may not be that significant.
>
>
>On a side note - I should have brought out this question long time back
>with
>respect to the protocol draft (headers) but ended up simply using my
own
>propietary mechanism to ship the interface arrival information. The
>current
>redirect header (PL header) does not contain any place on the header to
>provide such information at all.
>
>Thanks,
>
>
>Khosravi, Hormuzd M wrote:
>
>Good point, Joel. This is one of the reasons we would need a some/PL
>header for data packets.
>
>I am not sure this would be solved with tunnels, unless you setup a
>tunnel per external FE interface and that could be several hundred
>tunnels if there are as many interfaces on the router.
>You need this information (on which port/interface a packet arrived on
>the FE), for multicast forwarding.
>
>regards
>Hormuzd
>
>-----Original Message-----
>From: Forwarding and Control Element Separation
>[mailto:[email-masked]] On Behalf Of Joel M. Halpern
>
>
>
>5) I am essentially saying that in some sense the TML header is the
>
>
>tunnel
>
>
>protocol header. I really don't see
>the need for the "data" packets to be going through the ForCES PL layer
>
>
>
>
>
>for de-muxing to appropriate application (OSPF, BGP etc.) - Put it
>
>
>another
>
>
>way, I am basically saying that there is no PL or TML header for the
>
>
>data
>
>
>packets - since tunneling will be transparent to the applications.
>
>
>
>The data packets need some sort of header since we must know what
>interface
>they arrived on, what FE sent them to the CE, and why the CE sent
>them.  That information can not reliably be determined purely from the
>underlying packet.
>
>Yours,
>Joel M. Halpern

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 17 Mar 2005 10:03:29 -0500

> FE?  Am I missing something?

Depends on your FE to quantify what you mean by "some amount of
processing" and its effect on wire speed processing. Note as well
Joels point that wirespeed maynot be a necessary need if theres no
traffic to justify it ("I have 1G but i only use 1Mbps")

If your LFB piece on the FE resides in an ASIC, FPGA or a NP, then the
processing happens within the ASIC/FPGA/NP. The VLAN redirection to CE
example i gave earlier happens in an ASIC.
Clearly if your LFB was in some s/ware running in an FE general purposes
CPU then you may run into _relatively_ more performance challenges.
And if you want to make something complex such as put TCP header around
it, you will have to process in such a CPU given the complexity of the
state machine.

Hence my assertion earlier: if i can do the redirection within hardware
and avoid putting any PL/TML wrappers, id be just as happy - but if i
found an FE that didnt understand my VLAN redirection then i would be
forced to redirect to something on the FE that will do extra processing
of putting wrappers around the redirected packet. 

cheers,
jamal