Subject: Re: FE-CE data path

From: "Chawla, Shuchi" <[email-masked]>
Date: Wed, 16 Mar 2005 17:38:40 -0500

I believe I am also having a problem getting my messages through...here is
what I had sent, which didn't make it.

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

On Wed, 16 Mar 2005 16:27:52 -0500, Joel M. Halpern
<[email-masked]> wrote:

>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

[deleted]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 16 Mar 2005 17:48:42 -0500

That is mostly correct.

I would clarify that LFBs only decide what they are defined to decide.  An 
LFBs whose job is "forward data packet to CE" will generally not ~decide~ 
whether to do so, but rather will just do so.  Some combination of 
classifier and brancher LFBs will have "decided" by sending the packet to 
that specific LFB for processing.

As for wire speed...
a) I guess it depends upon the wire
b) even software implementations can keep up with slow wires
c) it is expected that ForCES functionality may in some cases be 
implemented in ASICs or FPGAs, which can keep up with higher rates.
c') I have seen FPGAs which can be driven by flexible connectiivity tables 
and still keep up with good wire speeds (1 gigbit + while performing many 
functions on the packets.)
d) Of course, it also depends upon how much you want to do to the 
packet.  A medium transcoder might have trouble, no matter how simple the 
ForCES framework, if told to run at 10 gigabits.

Yours,
Joel