Re: PPPOE Was (Re: >=pre5 OOPS on boot failure to open /dev/console

From: jamal (hadi@cyberus.ca)
Date: Mon Apr 17 2000 - 21:48:22 EST


> Henner Eisen <eis@baty.hanse.de> writes:

>The PPPOX code certainly seems to be a good framework for PPPoE and
>similar, where some new and somewhat complex ppp-specific encapsulation
>methods for ppp frames are needed. But for tunneling ppp over existing
>protocols, where the additional ppp-related encapsulation is simple,
>maybe another approach might be more appropriate.

If i understand you correctly you are just tunneling data, it just happens
to be ppp, right?
What about call/connection setup, negotiation etc? If this is irrelevant
then i agree with you that it doesnt matter what you use.

>I've started to implement ppp over the AF_X25 socket layer. Here,
>ppp frames are carried directly inside the X.25 payload, without
>any additional encapsulation headers. The RFCs for ppp over other
>protocols are frequently similar (no additional ppp frame encapsulations
>or just some pad bytes). For such protocols, the encapsulation of the
>ppp frames is trivial and the PPPOX framework (which makes the task
>of implementing complex ppp encapsulations schemes more easy), does
>not give any advantage. Instead, the hard problems faced when interfacing
>such a protocol to ppp are the interactions with the protocol internals.

What about connection setup/teardown/general control? We already have pppd
which suffices for the ppp negotiations. Most of this protocols have their
own negotiations before they start ppp setup.

>Existing network protocol stacks differ in various areas (e.g. which
>parts of the protocol processing need process context, how can
>ppp_channel flow control be interfaced to the carrier protocol's flow
>control mechanism).

Flow control/setup is the slow path of the whole transaction. Naturaly it
makes a lot of sense to move this part out of the kernel because it tends
to be rich, adds tons of code to the kernel and might be subject to
frequent changes. The interfacing to the "carrier protocol's" flow control
mechanism is done outside (in user space). The connect() and
disconnect() pppd hooks for example tie to the "carrier
protocol's" connection setup and teardown.

cheers,
jamal

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:12 EST