[Xorp-users] Implementing on-demand ad hoc routing protocols using XORP...

[Pavlin Radoslavov]

> I want to use some of the XORP processes (FEA and probably RIB as well)
> for implementing ad hoc routing protocols such as DSR (Dynamic Source
> Routing). My reason to use the FEA is to make my implementation portable.
> So, I want to explain my approach and ask for your feedback about its
> feasibility.
> 
> My plan is to implement the ad hoc routing protocols using C/C++ and then
> make use of the FEA classes 1)To forward Table management, 2) To send and
> receive raw packets and, 3) To send and receive TCP/UDP packets. So far is
> it OK?, I mean, is it possible to make use of the FEA classes, from any
> other C/C++ program, without making use of any other process that is part
> of the XORP architecture?

I presume you just want to link your code with (some of) the FEA
code rather than running your protocol within the XORP framework?
Yes, it should be possible (and yes, you won't need the rest of the
XORP processes), but you should be aware of the following:

* All operations for manipulating the network interfaces are
  transaction-based, so you need to make sure that you call
  start_transaction/commit_transaction back-end code inside the FEA.

* The operations for manipulating the forwarding table are also
  transaction-based, so here again you need to call the appropriate
  start_transaction/commit_transaction back-end code inside the
  FEA.

* The FEA classes haven't been designed to be used in complete
  isolation. E.g., the classes for sending/receiving raw packets
  need to have access to the network interface information managed
  by the interface-related classes.
  Hence, you have to be careful if you choose to pick-up only some
  of the FEA classes.

* The FEA code needs to be linked with a number of libraries (see
  the xorp_fea_LDADD files inside fea/Makefile.am) so you may need
  to do lots of trimming if you don't want to depend on those
  libraries as well.

* If the FEA internals are modified in the future, quite likely you
  won't be able to link with the newer versions without
  modifying/refactoring your implementation.

In other words, depends on the particular solution you choose, you
may have to go through lots of hassle to isolate only the pieces you
need.
FYI, eventually in the future we will have a single top-level FEA
class (with an uniform API) that collects all the smaller pieces,
but for the time being this is a low priority task.

Rather than trying to do such low-level linking/reusing of the FEA
code, I'd recommend to implement your protocol with the XORP
framework in mind. E.g., have a top-layer communication API that
eventually will use XRLs to interact with the FEA and RIB.
Then, you could always reuse your core implementation in some other
way.

> My second question is that for on-demand ad-hoc routing protocols such as
> DSR, when a data packet is going to be sent by the source node (presumably
> in a multi-hop fashion) it might be the case that there is no path to the
> destination node, in such a case, the Route Discovery component of the
> routing protocol has to be initiated, and after hopefully obtaining a path
> towards the destination (or the next-hop at least), the data packet can be
> sent. However, my concern is that when the data packet is going to be sent
> and the forwarding engine does not find a next-hop for the destination in
> the forwarding table it won't send the packet. What I need is to be able
> to initiate the route discovery before the data packet reaches the
> forwarding engine (just in the case there is no known route), and once the
> route has been discovered the packet can proceed to the forwarding engine.
> Is that possible? Is there something in the FEA that would allow me to do
> that while the implementation is still portable? If not, any suggestion?

Are the data packets forwarded in userland or only by the kernel?
If the former, then your protocol should queue them until the path
is discovered.
If the data packets are forwarded only by the kernel, the
traditional UNIX forwarding path doesn't provide the mechanism to
queue the packets until the path is resolved. Though, it may be
worth doing some search if there are any kernel extentions/modules
that provide that functionality.
Otherwise, you may try to implement this feature in Click and then
use the Click forwarding path (either in user or kernel mode) to
queue/forward the packets and interact with your protocol.

Hope that helps,
Pavlin