tech-net archive

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

Re: [GSoC] L2TP pseudo device

Jordan Gordeev wrote:
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.

ok but you are aware of NetBSD already supporting pppoe, aren't you?

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.

I disagree. This should be another type of socket.
But I can also see it being desirable to have both packet types on the one socket so that ordering is preserved.

You may wish to think about different socket types or protocol types for a given address family of a socket with there being a "wildcard" to let you receive all.

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.

What are your thoughts on the latter point?
How would you design a mechanism to implement that without making it specific to this project?


Home | Main Index | Thread Index | Old Index