Re: Networking design proposal

[Olivier Péningault]

le lun 28-10-2002 à 21:38, Niels Möller a écrit :
> > These translators will implement protocols such as : ip4+icmp4,
> > ip6+icmp6, and maybe other things will be aviable.
> 
> I'm a little confused here. When you say "implement ip4", what does
> that mean? media-specific stuff (arp, ip-over-ethernet, etc) is done
> by the layer 2 translator, if I understand you correctly ("It
> will give an interface for the layer 3 protocols, it will hide _all_ the
> data link stuff to upper layers."). And transport protocols are not
> done here either.
You didn't understand correctly. Layer 2 translator performs ethernet +
arp, not ip !
ip + icmp (+igmp) will be in the layer 3 translator.
In fact, the network address send by layer 3 translators to register are
for arp. arp knows both ethernet AND ip addresses.
To have arp and ethernet in a single translators allows (with the help
of the registring method) to hide _all_ layer 2 ops (arp performs layer
2/3 ops, it must be hidden) This allows more flexibility. Some layer 2
protocols (such as ppp) don't really care about layer 2 addresses. This
design makes it easier to implement the layer 2/3 programming interface.

Here is a draw of my idea (for ethernet/ip) :

__________________   _____________________  ___________________
| L3 translator  |   |  L3 translator    |  | L3 translator   |
| 192.168.1.1/32 |   | 192.168.2.1/32    |  | 2001::1/128 ;)  |
------------------   ---------------------  -------------------
 | Mach              || Mach     | Mach       | Mach
 | port              || port     | port       | port
 | 1                 || 2 5      | 3          | 4
______________________________  _______________________________
| L2 trans on /dev/eth0      |  | L2 trans on /dev/eth1       |
|Registred L3 trans :        |  |Registred L3 trans:          |
| + 1 192.168.1.1/32 0x800   |  | + 3 192.168.2.1/32 0x800    |
| + 2 192.168.2.0/24 0x800   |  | + 4 2001::1/128    0x86DD   |
| + 0.0.0.0/0        0x800   |  |                             |
------------------------------  -------------------------------
               |                               |
-------------------------------------------------------------------

 K  E  R  N  E  L    W /    D  E  V  I  C  E    D  R  I  V  E  R  S

--------------------------------------------------------------------

You can see that arp's got all needed information to find remote layer 2
addresses (layer's 3 routing table will say to who we send the packet,
and this network address is sent with the packet, so that arp can do the
work).
You can see also that routing will be done here : registring means
selecting which packets we want to receive; there is also a default
route to eth1. And IPv6 looks happy ! :)

I understand people could think it doesn't respect ISO usual views about
layers, but I am sure it does. As I said in a previous mail, arp is a
very important protocol, we must use it in the better way, and I think
it is used in a (?) good way.

> As for icmp, I wonder what a general, transport-independent, icmp
> service should do. To me, it seems that the only useful thing it could
> do is filtering. If I'm implementing udp, and talk to your layer-3
> interface, I'm going to give you some udp packets, and then in order
> to get any errors, I will also tell you "If you receive any icmp
> packets to this ip-address, of type ICMP_TIME_EXCEEDED, and the body
> of the icmp message contains this data (my udp header, including
> addresses and port numbers), then give it to me".
> 
> Such an icmp service makes sense if one has several independent
> processes doing transport that talk to the same interface. But I'm not
> sure that makes sense; I think it's better to have at most one
> transport proces per ip number, to get easy management of portnumbers.
This would require a lot of memory !

> And if one has a single transport process (per ip), then it seems
> easier to just give raw icmp mesages, with the ip number in question
> as destination, to the transport process and have any icmp-related
> code in a shared library.
> 
> But I may change my mind. In particular, it would be cute to have tcp
> and udp transport as independent processes, and then the layer beneath
> must be able to pass on icmp messages to the right process.
>
> Are there any icmp messages that you can process without knowledge of
> transport level state?
No, but think about ISO-CLNP. It is a stand alone layer 3 protocol, data
transmission (a la ip) and control (a la icmp) are implemented in this
protocol. If icmp is implemented with layer 4 protocols, you won't be
able to implement protocols built like CLNP.
I want to have ip and icmp to run together, because they provide the two
services of the layer 3 : data transmission, and control. If you receive
an icmp packet, you'll have enough information (ip header + 8 bytes of
the layer 4 packet) to know to who you will notify this error.

> I'm not sure I understand this. A transport program should know what
> ports it has allocated, and if you just tell it what ip numbers are
> available, it should also be able to handle wildcard addresses etc.
You tell him what numbers are aviable, but you (L3 translator) don't
know it is a port number. Please see below.

<<
> That sounds odd. Port number space is a part of layer 4, not layer 3.
>>
I know it. but, I thought about the way it had to be implemented.
- in the layer 4. If you run (at least) 2 layer 4 translators, I've
found race conditions that will disturb the service.
- in a translator. Ok, but every translator will have to know this
translator, it will cause a lot of rpc calls, and everytime a new layer
3 interface is set up or shutdown, this translator has to know it. it
would be possible, but heavy.
- in the layer 3 translator. This doesn't respect ISO layers, BUT :
 * L3 translators will only know L-4 tyranslators want to get a number,
L3 translator will not know it is a network port. Only a number !!!
 * no race condition is possible (it is usefull, AFAIK)
 * less rpc calls.

> > Connectionless protocols (such as udp) will open a mach port to
> > underlying layer translators the first time they will send data to them,
> > and the port can be open as long as both translators run.
> > 
> > Connectionfull protocols (like tcp) will open a new port everytime a new
> > session begins, and will close this port when the seesion ends.
> 
> Note that udp needs port allocation and management, just like tcp.
I spoke about Mach ports, not network ports.

This is a way of avoiding too much mach port allocation/release. For
tcp, we need a mach port (and a network port) for each session.
But as udp doesn't know the connection context, we just need one mach
port for all communication between each L3 and L-4-udp translator (but a
network port for each session, of course).

> > Routing between interfaces
> > ---------------------------
> For flexibility, one would probably want to put the rules into a
> separate process. (But then, I don't really know the tricks for doing
> efficient routing).
> 
> > Since hurd-net doesn't exist any more, our views converge. Differences
> > are that my layer 2 translator correspond to Niels' layer 2 translator,
> > and layer 2 part 1 stuff. Niels want to implement icmp in the layer 4
> > translators.
This is beautifull, here is what I think :

  +---------------------+
  | random posix socket |
  |    applications     |
  +---------------------+
--------------------------- The standard socket API
  +--------------+
  | glibc glue   | (with some help of L-4 and L3 translators. as you said
  +--------------+  socket.defs will be split here, in -lsocket)
--------------------------- Layer 4+ interface
  +----------------------+ 
  | transport protocols  |
  +----------------------+
--------------------------- Layer 3/4 interface
  +----------------------------------+
  | layer 3 data transmission +      |
  | control + <<numbers>> allocation |
  +----------------------------------+
--------------------------- Layer 2/3 interface
  +--------------------+
  | layer 2 stuff      |
  +--------------------+
--------------------------- Kernel/user land
  +--------------+
  | network card |
  +--------------+
--------------------------- Physical interface

There is less levels !

Please think about it. But take your time to answer, I won't be there in
the next days. :)

Regards,

olivier