Re: Networking design proposal

[Michal 'hramrach' Suchanek]

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
hramrach@centrum.cz