[Xorp-hackers] RAW/TCP/UDP Socket Implementation

Pavlin Radoslavov pavlin@icir.org
Mon, 15 Aug 2005 18:25:09 -0700


> I am currently going through the implementation of raw/tcp/udp sockets for
> control path communication. My understanding is that sockets use the
> actual interfaces (these interfaces are used for forwarding plane too) for
> sending control information (BGP, RIP, ..). On a router, when we run both

I am a bit confused by what you mean that "these interfaces are used
for forwarding plane too". The forwarding plane is inside the kernel
(or in user-level Click), and XORP itself is not on the forwarding
path.
Currently, the FEA RAW/TCP/UDP socket story is:

 * The FEA UDP socket interface is used by RIP/RIPng for sending and
    receiving control packets.
 * BGP itself uses its own TCP sockets, but in the future it will
   use the FEA TCP socket interface.
 * OSPF will use the RAW FEA socket interface for sending and
   receiving control packets.

> XORP & forwarding (say Click), then there must be a way to differentiate
> regular data packets and control packets. Could some one tell where is
> this done (in Click or XORP) ? i believe it to be Click. If its done on
> forwarding plane, then it means that the forwarder should actually
> distinguish data & control packets.

Are you trying to use Click+XORP, and inside your Click
configuration you want to exclude from processing the control
packets from/to the XORP control plane? I guess it is possible to
create Click configuration that filters the control packets. The
Click mailing list would be a better place to get an answer how to
do that.

> Now, suppose, if we decide to use another interface (not one, where data
> transfer occurs) for control packets, then it might incur some additional
> management. I think this is the model for having forwarding plane reside

Here again I am confused about the mixture of data and control packets.

> on different machine than XORP (as described in XORP FEA document). I
> think this was not supported as of April'05. Is this being incorporated
> now, or would it be in the near future ?

The model for running remove FEA is as follows. Lets say that
machine A is running the FEA, and machine B is running the rtrmgr
and all other modules (RIB, RIP, etc). The XORP finder (running on
B) knows that the FEA is running on A, so all XRLs destined to the
FEA will be sent to A's IP address. E.g., if the RIB sends
"add_route" XRL to the FEA, the XRL will be dispatch properly to A,
and the forwarding plane on A will be modified appropriately.
If, say, RIP sends a control packet (using the FEA UDP socket
interface), the "send" XRL with the control payload will be sent to
A. Similarly, RIP UDP (control) messages will be dispatched from A
to B's RIP process.
The forwarding of the data itself happens only in the forwarding
plane on A, and B is not involved in that.

Pavlin