My idea of networking: I) The bottom part is a device that accepts frames. This can be an ethernet device or *lip device sending frames over serial/parallel line. Note that atomic operation is sending/receving a packet, not bit, nor byte, probably not even an ATM cell. (anyway ATM is probably dying already)
This is the only thing all proposals have in common ;) Users: tcpdump, arp-ish thingies, upper protocols?, bridging? II) The addressing part. Different proposals suggest putting it either into I) or III) or separate it. It is neccessarily contacted for _every_ packet sent (otherwise addressing would not be transparent). It should have specific configuration|process for every interface. It should tell if an address can be reached on this segment. The configuration could be trivial (ppp, pppoe, *lip) or dynamic (arp, ..?) I suspect there are protocols that use ethernet and do not use arp (pppoe?, appletalk?, IPX/SPX?, ..?). This can be implemented either as a pipe|layer between the upper protocol and the underlying device (so that upper never reaches device) or as an "advisor" that points to the right device port when asked. The rpc overhead should not differ, it has to be contacted for every packet. Users: arp tools, upper protocols III) The routing part. In general, this should be responsible for delivering packets to the right consumer. The packet may come from "upper protocol", or from an interface. There may be a problem determinig which packets that came from an interface belong to ip and which belong to other protocols. This can be split into three parts: IIIa) deliver any packets I can parse to anybody above interested in such address:port, and deliver any packet from above to somebody on my interface or return an error. When receiving packet from above either the source address:port should match config of should be filled in internally by IIIa. This part is bound to particular interface and can either handle only one address (needs opening the interface several times in parallel for different addresses, special puposes, bcasts, mcasts?) or handle a list of addresses. IIIa inteface is always needed for bcasts, dhcp, ... IIIb) deliver packet to any known interface or return an error if address not known, receive packets from multiple interfaces, all interfaces. IIIc) route packets between interfaces. Especially IIIc would be nice as a special process with fancy firewalling features and such. IIIb could be probably a library that uses IIIa This layer in tcp/ip should be resposible for packaging data into packets. IMO icmp packets are just different types of ip packets and should be created and interpreted here. Of course, some of them can affect connections of upper protocols and the owner of the connection should be notified of the consequences (ie his/her stream connection was opened). Users: dhcp, tcpdump?, upper protocols IV) operate stream/dgram connections This should provide some interface for the services of III. I do not know if the protocols differ so wildly that different VI layers are needed for different protocols. afaik all protocols supply generally some machine:port addressing, datagrams, and realiable connection on top of datagrams. The work done here would be fragmentation and reconstruction of streams in cooperation with IIIb. Some logic to dgram connections could be created here as well. The IV layer could be split into dgram part and socket part. It would be nice to have a flexible universal interface between III and IV. Users: libc, user programs? Differences: Main differences are how these different layers are packed into processes. Imho it is possible: - pack addressing with routing (II + III) as I do not know two different protocols using the same addressing stuff. But the interfaces should be available for examining state of the addressing part, setting up addressing, and attaching experimantal|parallel implementations of upper protocol. - shift some parts of IV into III (possibly to use some protocol-specific interfaces and optimizations). This does not sound good to me. But it may be neccessary if no general (de)fragmentation interface is possible. The question which interface should be accessible through filesystem is not important. Anything with simple, well designed interface can be made accessible with a translator. ip6 vs ip4: imho ip6 should include ip4 addresses. If it was not standardised in the protocol itself the interface for interchangeable use of different ip addresses can be in IIIb or (in a more general way including any protocol) in IV But the default behavior can be changed by binding/connecting to different addresses. What about AF_IP, AF_IP4, AF_IP6 (or the like)? ATM: This is an interesting part. Aside from using ATM natively one could map IP QoS on ATM QoS once implemented :) But my knowledge of this is limited. I hope this brings some inspiration to others and is not just wasting of mailbox space ;) -- Michal Suchanek [EMAIL PROTECTED] _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
