On Mon, Dec 1, 2008 at 18:46, Pavlin Radoslavov <span dir="ltr">&lt;<a href="mailto:pavlin@icsi.berkeley.edu">pavlin@icsi.berkeley.edu</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">Victor Faion &lt;<a href="mailto:vfaion@gmail.com">vfaion@gmail.com</a>&gt; wrote:<br>
<br>
&gt; Hello,<br>
&gt;<br>
&gt; I wanted to use my forwarding engine (which has its own forwarding table)<br>
&gt; together with my own protocol (at the application layer, using sockets) with<br>
&gt; XORP. I wasn&#39;t sure if it&#39;s better to implement a separate process that<br>
&gt; interacts with XORP&#39;s FEA (this would be the forwarding engine) and another<br>
&gt; process that represents the protocol or if I should implement all of this<br>
&gt; using Click and then plug it into XORP (or just use it only with Click). In<br>
&gt; other words, how much of XORP&#39;s code I would need to change to do this and<br>
&gt; would it be easier to do it in Click or to use both?<br>
<br>
</div></div>Without additional info about your protocol it is difficult to give<br>
you advice that will fit best your specific needs.<br>
<br>
If I make the assumption that your control protocol is similar to, say,<br>
OSPF or RIP, my generalized advice would be to implement your<br>
control protocol as a separate process that interacts with the XORP<br>
FEA. If you don&#39;t have any specific requirements, you shouldn&#39;t need<br>
any additional changes to XORP.<br>
<br>
<br>
Re. your question of XORP vs. Click.<br>
>From XORP&#39;s perspective, Click is an IPv4/IPv6 data plane,<br>
though Click itself is much more than that.<br>
Hence, if you implement your protocol in XORP, the &quot;shall I use<br>
XORP+Click&quot; question becomes a question of whether you want to use<br>
Click as the IPv4/IPv6 data plane.<br>
On the other hand, if you have a relatively simple protocol with<br>
some unusual requirements (say, it requires tight integration with<br>
the data plane), and the existing UNIX kernel API is not sufficient,<br>
you might be able to save time getting the initial prototype working<br>
if you use only Click.<br>
<br>
Hope that helps,<br>
Pavlin<br>
<br>
<br>
<br>
&gt; Victor<br>
&gt; _______________________________________________<br>
&gt; Xorp-hackers mailing list<br>
&gt; <a href="mailto:Xorp-hackers@icir.org">Xorp-hackers@icir.org</a><br>
&gt; <a href="http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers" target="_blank">http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers</a><br>
</blockquote></div><br><br><br>Hello,<br>
<br>
Thank you for the response, the control protocol is a link-state routing protocol. It uses LSR but also needs to associate additional information with hosts and this is why I think I might need to make another XORP process for this protocol, and I think its easier to plug in a new protocol into XORP rather than Click.<br>
<br>As for using Click as the data plane, I could make my forwarding table as a Click element, or would it be simpler to do it as a separate XORP process without relying on Click?<br>
<br>
Victor<br>