tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

[GSoC] L2TP pseudo device



I've been looking at the "Create a L2TP (RFC 2661) pseudo device" proposed Google Summer of Code idea.
I want to share some of my thoughts with you and hear your opinion.

When implementing L2TP, there are two primary desirable characteristics - 1) performance and 2) flexibility. It's natural to want to divide the implementation into two components - one userland and one in the kernel, where the userland component ensures flexibility and the kernel component ensures performance. A third desirable characteristic is generality - i.e. applicability to other PPP-carrying mechanisms, such as PPPoE.

Here's my first idea for design of an L2TP implementation:
   All network-layer protocols are handled by the kernel.
All control protocols (LCP, other link-layer control protocols, NCP's like IPCP, IPV6CP, etc.) are handled by a userland program. The userland program uses a socket (or a character device) to send and receive control-protocol packets. These control-protocol packets will appear on the kernel/userland socket interface as PPP frames. The kernel component and the userland component will need to interact - the userland component will send commands to the kernel component and the kernel component will send event notifications to the userland component. I believe it's a good idea to use the same socket, that is used for control-protocol packets, for commands/event notifications too. A special "NetBSD L2TP Control Protocol" can be invented for this purpose.

Having the userland application handle all control-protocol packets has the disadvantage of even the simplest requests - LCP Echo-Request's - going from kernel to userland and back, with the overhead this incurs. It would be nice to have at least some parts of some control protocols handled in the kernel. This leads to the second design idea:
   All network-layer protocols are handled by the kernel.
   Some control-protocol packets are handled by the kernel.
   Some control-protocol packets are handled in userland.
The division of responsibilities between the kernel and userland is fixed. The control-protocol packets handled by the kernel are those, for which "imagination" or access to external resources (e.g. RADIUS servers) is not required.

This idea can be extended to the third design idea:
   All network-layer protocols are handled by the kernel.
   Some control-protocol packets are handled by the kernel.
   Some control-protocol packets are handled in userland.
The division of responsibilities between the kernel and userland is dynamic. The userland application can get more responsibilities, or off-load responsibilities to the kernel, whenever it wishes.

In my opinion, the best mix of performance and flexibility is achieved in the second design idea, although I like the other ideas too.
Do you like the second idea the most?
Have you got any suggestions you want to share?

Regards,
   Jordan Gordeev



Home | Main Index | Thread Index | Old Index