Subject: Re: FE-CE data path

From: "Chawla, Shuchi" <[email-masked]>
Date: Wed, 16 Mar 2005 13:17:37 -0800

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: "Joel M. Halpern" <[email-masked]>
Date: Wed, 16 Mar 2005 16:27:52 -0500

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