Folks,
This is not posted to l-k because i didnt see the need for it. If there
is a good reason someone please forward it there.
The people in the CC list are in "the know". If people think this should
be taken off line and just privately discussed, then please yell.
Hopefully, the result here is that we have a solution quickly decided so
we can submit into 2.3
I apologize for the lengthy post; i thought it would be beneficial for
those not "in the know" ;->
When you respond please continue CCing the Cc list ubecause some of them
are not on the netdev list (other than probably Andi).
-----------------------------START HERE -----------------
The issue as i see it:
Too many "PPP over X" type protocols (PPPOE, L2TP, PPP over ATM, PPP
over SONET etc) and there will be a lot more coming probably.
All these type of protocols have a very similar protocol structure.
You discover something and use that discovery information to
start sending/receiving data using PPP framing.
The discovery tends to be the rich part of the protocol (as well as
the slower path).
The problem IMO:
Too many solutions; same end goal --> kernel cluttering.
Example for ppp over ethernet (for 2.3):
--------------------------------------------
Jamal:
PPPd talks to a tty device (akin to a modem).
Discovery in user space, data switching in kernel
Code size in there kernel (At the moment about 20k)
Contribution from the tty code: about 75% of this
Advantage:
-No changes required for any PPP/d (user/kernel)
- small addition to ther kernel
- Flexible enough to be used for _any_ PPP over X
With Minimal code addition ( <10K in the kernel).
-works in both 2.2 and 2.3
Disadvantage:
-uses tty -- an asoteric interface
-Does not use the channel interface
(Claim: Trivial change to make)
Michal:
-has both the discovery and data switcing encap/decap into the kernel
-PPPd talks to a brand new socket family (created for PPPOE).
Code size in the kernel (At the moment about 60k)
This includes also the server part.
Contribution from the socket addition: about 30% of this
Advantages:
does not use the tty interface. Uses the channel interface;
Disadvantage:
-Bloats the kernel.
(claim: Michal could remove the discovery phase out of the kernel
reducing it by about 20K).
-The socket use could become a maintainance nightmare
(claim: it looks very clean at the moment).
-Hard coded for PPPOE
-Creating a whole socket family for just PPPOE is a bad idea
(claim: Could make it for PPPOX with type PPPOE, L2TP etc).
-----------------------------------------------------------
The flow of connection setup/teardown
possibilities for connection setup:
-----------------------------------
pppoxd refers to your favorite PPP over X daemon
ONE:
1. pppoxd negotiates a connection and identifies parameters
eg in PPPPOE the sid and remote MAC address for the connection.
2. pppoxd opens a connection to the pppox interface.
to grab a fd which will be used by pppd.
eg if the interface used was a socket then for pppoe,
this determines the definition of sockaddr_pppoe.
3. pppoxd hands-off the fd to pppd.
4. PPPd grabs a new unit from the kernel (eg ppp1)
5. pppd performs a channel binding on the pppox interface by calling
an ATTACH ioctl.
TWO:
1. PPPd uses its "connect" interface to invoke a connection setup from
the pppoxd.
2. pppoxd negotiates a connection and identifies parameters
3. pppoxd opens a connection to the pppox interface.
to grab a fd which will be used by pppd.
4. pppoxd hands-off the fd to pppd.
5. PPPd grabs a new unit from the kernel (eg ppp1)
6. pppd performs a channel binding on the pppox interface by calling
an ATTACH ioctl.
The advantage of method 2 is that it maintains the goodies that pppd
provides already (such as dial on demand etc)
I prefer this method.
Disconnection
-------------
Could be issued from the user or could come from remote via a PADT
>From Remote:
1. Kernel receives all PADTs
2. It detaches the channel whose SID is indicated by the PADT.
3. PPP tells pppd of the detachment.
4. pppd invokes the particular protocol's "disconnect" execution.
>From user:
1. from pppoxd send a PADT to remote
2. From pppoxd send to kernel an ioctl to detach
3. pppd should inform you that there has been a detachment.
WHAT Needs to be decided
------------------------
We are all curently in violent agreement that discovery should be in
user space (includes Michal).
The main decision to make is what interface should PPPd be
talking to? For 2.2, the only viable solution is the tty one.
There is no question that for 2.3 onwards the channel
interface is the way to go.
So what should be the device that pppd talks to? Is it a new socket
family, tty device, a new char device etc.?
End Goal:
---------
-speed (a given with the channel stuff). However, we need some
quick way of way to shunt the data to the correct transporter
within the kernel (eg to UDP sockets for L2TP).
-flexibility (IMO) make it easy in the future to just add encap/decap
extensions. i.e i should be able to add todays_flavor_of_pppox
by simple regiatration APIs, write a user space discovery, bind it to
pppd and voila, it works (magic!).
Note that we currently have a limitation in pppd in that it is very
friendly to ttys. A small change will be required in the pppd daemon.
No changes in the kernel PPP.
I propose addition of a new syntax to the pppd options:
"channelname <channelname>" eg "channelname l2tp"
The pppd code should check for this syntax (which is mutually
exclusive with the devicename option). When this option is passed,
any assumptions that pppd is talking to a tty device are nullified.
This syntax could also be used to do other things in the future
(i,e currently the name above eg l2tp is a meaningless artifact).
I suggest that the current pppd "connect"/"disconnect" features be used
for connection setup teardown. Some enhancement might be needed (although
i dont see it myself).
>From the kernel side, My proposal is that whatever interface chosen is,
it should be able to very easily add new "PPP over X"s; so a registration
API is a requirement.
We should merge also the PPP over ATM already implemented using Michals
idea.
I might have missed other things. Michal?
cheers,
jamal
|