On Tue, 8 Feb 2000, Mitchell Blank Jr wrote:
> > For a tty you could make a line discipline which would shunt the packets
> > down the l2tp socket. Alternatively you could have a kernel thread doing
> > reads and writes on the device and your l2tp socket. That might actually
> > turn out cleaner.
>
> We definately want whatever the next PPP rewrite looks like to include some
> mechanism for this (which is probably best described as PPP bridging).
> I don't think we need a kernel thread to do it, either- you just need
> to wire ppp_input() on one channel to ops->start_xmit() on the other,
> perhaps with a small skb queue in the middle.
>
>
> If implemented intellegently this could also be used as a basis for
> implementing multi-chassis MPPP (i.e. supporting bonding multiple
> incoming calls into one bundle even if the calls landed on different
> machines) To do this, you need a way to get the PPP frames that
> landed on the slave box(es) back to the master box (which is actually
> handling the routing for the channel). One easy way to do this
> would be to just have the slaves bridge the PPP packets over
> some other transport (L2TP for instance) and have the master put
> that transport in the bundle with the others. Note that the "master"
> actually can be bundling nothing but channels from slaves - it could
> be a box that only handles routing for PPP bundles bridged over from a
> set of slave boxes... Cisco's large-scale dialin solution is
> architected that way.
And this could all be setup via ioctls onto the generic PPPOX setup; look
at my suggestions to Mark Spencer on the LAC/LNS.
cheers
jamal
|