[Top] [All Lists]

Re: RFC: PPP over X

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: RFC: PPP over X
From: Michal Ostrowski <mostrows@xxxxxxxxxxxxxxxxx>
Date: Fri, 4 Feb 2000 11:03:18 -0500 (EST)
Cc: Michal Ostrowski <mostrows@xxxxxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <Pine.GSO.4.20.0002040950590.27774-100000@xxxxxxxxxxxxxxxx>
References: <14490.57346.128709.747580@xxxxxxxxxxxxxxxxx> <Pine.GSO.4.20.0002040950590.27774-100000@xxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
jamal writes:
 > I am afraid these are some of the people who were staing that. They
 > probably want to see if we reach an agreement or not ;-> I am also

I hope that they do comment soon, there's some bigger issue involved
here than a piddly little protocol.  In particular I would like to
hear Andi's comments on the maintenance/semantics issues.

Regardless of the kernel support, I think we know what needs to be
done to pppd (more hooks, wrapping the tty code up as a plugin).  Once 
this is done it's almost trivial to write plugins to support any kind
of kernel support for PPPo*.

 > I think i have a very good feel to where PPPOE is going.
 > It is about services -- currently the only service is really access; and i
 > think that you might end up seeing the discovery part being extended for
 > some things. I would like to extend it myself and i dont think the
 > "proprietary tag" they have there already is good enough.

It's disappointing to see that what is really a pretty neat idea has
been given such a bad rap by Access Manager (a rather "quirky" windows

 > > 
 > > I don't understand what you mean by this, please elaborate (or refer
 > > to a specific code fragment).  
 > > 
 > I was refering to the hashing used. Sorry dont have access to code right
 > now;
 > A TCPI/IP flow could be uniquely hashed by the five tuples: src/dst port,
 > src/dst IP and protocol.
 > > My concern is that you need to know something about the protocol to be 
 > > able to identify the flow, since you need to be able to parse the
 > > packet header and extract those bits that identify the stream.
 > And i think every of the PPPOXs will have something unique; so the hashing
 > is not shareable.

That's a huge chunk of the code.  I was going through my code trying
to identify the PPPoE specific stuff and the somewhat more generic
stuff and unfortunately I'm having a very tough time identifying any
sizeable portion of the code that could be made generic.  Essentially, 
every time I refer to a pppoe_hdr struct, that's code that's PPPoE
specific-- and there's very little code that doesn't do that.

I'd like to refer you to my pppoe_bind function -- this is very
similar to what a pppoe_connect would look like if the discovery is
removed.  The primary point of this code is to create a hash-table
entry, and thus all of this code is pppoe specific.  Hence, if you did 
have AF_PPPOX, pppox_bind would essentially look something like:

        return  sk->sock_ops->bind(...)

In this case I'm worried that the PPPoX code would simply be there to
provide another level of indirection --- and note that the only common 
code you could have is the code from the system-call side of things.

So, here's what I suggest we consider:

1. Rename AF_PPPOE to AF_PPPOX.   

2. Define a protocol number PPPOX_ETH for PPPoE --- require that this be
   used to identifty PPPOE sockets.

3. Define a sockaddr_pppox to be something like:

   struct sockaddr_pppox {
        sa_family_t     sa_family;            /* address family, AF_PPPOX */
        unsigned int    sa_proto;             /* protocol identifier */
        union {
              struct pppoe_addr pppoe;
        } sa_proto_data;                      /* protocol data */

4. Add appropriate checks to the AF_PPPOE code to ensure that it is
   being used with AF_PPPOX semantics (that is check that the user is
   correctly specifying the protocol where applicable).

What this will do is create an AF_PPPOX interface that is flexible --- 
when we want to define other protocols we simply add stuff to the union.

This way we get to keep binary compatibility with code that was
compiled to use PPPOE, and we get to add protocols as appropriate.
Each protocol gets to use whatever addressing scheme it requires.

When it comes time to actually implement these other protocols, that's 
when we start working on seperating out protocol specific code (as is
done with AF_INET).  The point of this is that we won't know exactly
how that is to be done until we have other protocols to work with. 

 > I'll take a look at L2TP sometime this evening or sometime tommorow.
 > You can easily figure the ATM one (or i could look at that too).

I'll take a peek at the ATM code (or perhaps some of the PPPoATM guys
would care to comment).

 > Hmm... I know someone who is doing PPPTP over PPPOE ;->
 > I do tunnel over IPSEC to work via PPPOE myself;->
 > I think you'll see a lot of these VPNish types offered as services;
 > You discover them, you select based on pricing, QoS paramaters etc; doesnt
 > matter what the "ISP today" is. I split my user space code into some sort
 > of libraries -- still in very primitive stages so that i can easily stash
 > GUIs etc in anticipation of this. So in the very near future this will
 > start happening, if the CRTC gets its rulings imposed. You ask for access
 > service, 10 ISPs respond with their AC names and a few other parameters.


That's the perfect example of why it's very hard to do proper
negotiation in kernel-space.  We'd like to be able to present the user
with a funky GUI plugin which they can use to select their ISP.  This
would mean that we'd probably have to break out of the middle of a
"connect" syscall in some way.

Michal Ostrowski

<Prev in Thread] Current Thread [Next in Thread>