jamal writes:
>
>
> On 7 Feb 2000, Henner Eisen wrote:
>
> [Very nice diagram and description deleted]
>
> > My summary:
> >
> > PF_PPPOE: o.k.
> > PF_PPPOx: not o.k. (only o.k. if multiplexing above an existing carrier
> > protocol is needed. Maybe the latter case could be
> > handled by a generic PF_PPPOX for every such
> > protocol).
> >
>
> My thinking is that the protocol family/domain is really just for
> management reasons i.e what you describe as 'carrier' i see to be really
> the encap/decap part. For example it might come in through one encap
> interface, gets decaped and encaped again to another one (the LAC example
> fits well in this scenario).
> Another scenario: The packet comes in, it goes through the decap then up
> the stack to the approriate socket interface to the user space server for
> example.
> We should leave the control of what happens to the implementation
> of the specific PPPOX;
> For this reason i am supporting the PF_PPPOX as a family and the
> type to be one PPPOXs eg SOCK_PPPOE and we dont need to implement the
> traditional SOCK_STREAM etc. I am saying this without looking at the code
> so i could be off tangent.
Going off a bit on a tangent myself, perhaps we should give some
thought to playing around with the socket "type". From the "socket"
man page:
int socket(int domain, int type, int protocol);
...
The socket has the indicated type, which specifies the
semantics of communication. Currently defined types are:
So if you want to do PPP/UDP:
socket(AF_INET,SOCK_PPP,IPPROTO_UDP);
As the "type" suggests, you get PPP semantics.
This wouldn't solve the problem for PPPoE, where we need a unique
addressing scheme, but it might be a nice way of dealing with things
for those transport schemes where we can re-use the existing
infrastructure. (Under such a scheme it may be feasible/easy to do
PPP/TCP <shudder>.)
Michal Ostrowski
mostrows@xxxxxxxxxxxxxxxxx
|